DE102020121102B3 - Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem - Google Patents

Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem Download PDF

Info

Publication number
DE102020121102B3
DE102020121102B3 DE102020121102.3A DE102020121102A DE102020121102B3 DE 102020121102 B3 DE102020121102 B3 DE 102020121102B3 DE 102020121102 A DE102020121102 A DE 102020121102A DE 102020121102 B3 DE102020121102 B3 DE 102020121102B3
Authority
DE
Germany
Prior art keywords
message
frame
data
contained
battery
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.)
Active
Application number
DE102020121102.3A
Other languages
English (en)
Inventor
Guenter Hofer
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.)
Infineon Technologies AG
Original Assignee
Infineon Technologies AG
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 Infineon Technologies AG filed Critical Infineon Technologies AG
Priority to DE102020121102.3A priority Critical patent/DE102020121102B3/de
Priority to US17/343,309 priority patent/US11956097B2/en
Priority to CN202110912948.4A priority patent/CN114079591A/zh
Application granted granted Critical
Publication of DE102020121102B3 publication Critical patent/DE102020121102B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40169—Flexible bus arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40032—Details regarding a bus interface enhancer
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H01M10/4257—Smart batteries, e.g. electronic circuits inside the housing of the cells or batteries
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/48—Accumulators combined with arrangements for measuring, testing or indicating the condition of cells, e.g. the level or density of the electrolyte
    • H01M10/486—Accumulators combined with arrangements for measuring, testing or indicating the condition of cells, e.g. the level or density of the electrolyte for measuring temperature
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H01M2010/4271—Battery management systems including electronic circuits, e.g. control of current or voltage to keep battery in healthy state, cell balancing
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M10/00—Secondary cells; Manufacture thereof
    • H01M10/42—Methods or arrangements for servicing or maintenance of secondary cells or secondary half-cells
    • H01M10/425—Structural combination with electronic components, e.g. electronic circuits integrated to the outside of the casing
    • H01M2010/4278—Systems for data transfer from batteries, e.g. transfer of battery parameters to a controller, data transferred between battery controller and main controller
    • H—ELECTRICITY
    • H01—ELECTRIC ELEMENTS
    • H01M—PROCESSES OR MEANS, e.g. BATTERIES, FOR THE DIRECT CONVERSION OF CHEMICAL ENERGY INTO ELECTRICAL ENERGY
    • H01M2220/00—Batteries for particular applications
    • H01M2220/20—Batteries in motive systems, e.g. vehicle, ship, plane
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02E—REDUCTION OF GREENHOUSE GAS [GHG] EMISSIONS, RELATED TO ENERGY GENERATION, TRANSMISSION OR DISTRIBUTION
    • Y02E60/00—Enabling technologies; Technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02E60/10—Energy storage using batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/70—Energy storage systems for electromobility, e.g. batteries
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T10/00—Road transport of goods or passengers
    • Y02T10/60—Other road transportation technologies with climate change mitigation effect
    • Y02T10/7072—Electromobility specific charging systems or methods for batteries, ultracapacitors, supercapacitors or double-layer capacitors
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
    • Y02T90/00—Enabling technologies or technologies with a potential or indirect contribution to GHG emissions mitigation
    • Y02T90/10—Technologies relating to charging of electric vehicles
    • Y02T90/14—Plug-in electric vehicles

Abstract

Es wird ein Verfahren, insbesondere für ein Batteriemanagementsystem beschrieben. Gemäß einem Ausführungsbeispiel umfasst das Verfahren das Bereitstellen einer digitalen Nachricht, die eine Vielzahl von Frames umfasst, wobei die Vielzahl von Frames einen ID-Frame, zumindest einen Daten-Frame und einen Prüfsummen-Frame umfassen. Der Prüfsummen-Frame enthält einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde. Das Verfahren umfasst weiter das Erzeugen einer CAN-Nachricht, wobei die in dem (den) Daten-Frame(s) und dem Prüfsummen-Frame enthaltenen Daten in ein Daten-Feld der CAN-Nachricht eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird. Das Verfahren umfasst weiter das Senden der CAN-Nachricht über eine CAN-Bus-Leitung und das Empfangen der CAN-Nachricht und Rekonstruieren der digitalen Nachricht.

Description

  • TECHNISCHES GEBIET
  • Die vorliegende Beschreibung betrifft das Gebiet der Batteriemanagementsysteme und dazugehörige Verfahren.
  • HINTERGRUND
  • Batteriemanagementsysteme (BMS) haben die Aufgabe, das Laden und Entladen einer aus mehreren Batteriezellen oder -blöcken aufgebauten Batterie (auch Batteriepack genannt) zu überwachen. Ein Batteriemanagementsystem kann mehrere Module umfassen (z.B. ein Modul pro Batteriezelle), die jeweils mit einer Steuereinheit kommunizieren können. Diese Steuereinheit wird häufig als Batteriemanagementeinheit (BMU, Battery Monitoring Unit) bezeichnet. Diese Kommunikation wird ermöglicht mittels eines digitalen Kommunikationsbusses. Beispielsweise sind die BMU und die einzelnen Module in einer Daisy-Chain aneinandergereiht. Die BMU kann als Master-Knoten des Kommunikationsbusses betrachtet werden, wohingegen die einzelnen Module mit den darin enthaltenen Zellüberwachungsschaltungen (CSC, Cell Supervision Circuits) die Slave-Knoten bilden. Jeder Busknoten hat eine Adresse und jeder Knoten gibt empfangene Nachrichten an den nächsten Busknoten weiter, bis die Nachricht bei dem Busknoten angelangt ist, an den die Nachricht adressiert ist. Die Struktur und die Funktionsweise einer Daisy-Chain-Bus-Topologie ist an sich bekannt (siehe z.B. US 2017/0346308A1 ) und wird hier nicht weiter erläutert. Ein Batteriemanagementsystem mit einer Kommunikationsschnittstelle zur Übertragung von Batteriezellinformationen über ein Fahrzeugbusssystem ist in der Publikation EP 3 591 986 A1 beschrieben.
  • Bekannte Kommunikationsbusse, die in Batteriemanagementsystemen eingesetzt werden, verwenden eine frame-basierte serielle Datenübertragung, wobei für die Datenübertragung sogenannte UARTS (Universal Asynchronous Receiver Transmitter) eingesetzt werden können. Ein UART überträgt Daten als serieller digitaler Datenstrom mit einem fixen Daten-Frame (UART-Frame), der üblicherweise aus einem Start-Bit, fünf bis neun Datenbits, einem optionalen Paritäts-Bit zur Erkennung von Übertragungsfehlern und einem Stopp-Bit besteht.
  • Im Automobilbereich kommunizieren verschiedene elektronische Steuereinheiten (ECUs, Electronic Control Units) üblicherweise mittels CAN (Controller Area Network) oder einem anderen Feldbus-System. Ein CAN-Bussystem ist beispielsweise in der Publikation CN105306323A beschrieben. Um ein UART-basiertes Bussystem eines Batteriemanagementsystems mittels CAN mit einer ECU koppeln zu können, wird eine spezielle Schnittstelle benötigt, die als CAN/UART-Übersetzer bezeichnet werden kann. Derartige CAN/UART-Übersetzer sind relativ aufwändig zu realisieren. Es werden mindestens zwei Mikrocontroller benötigt; einer für das Protokoll-Handling des CAN-Protokolls und einer für Sicherheitsanwendungen. Die von den Mikrocontrollern ausgeführte Software muss die Anforderungen gemäß ASIL-D erfüllen (Automotive Safety Integrity Level D gemäß ISO26262). Insbesondere bei verteilten Systemen mit mehreren Daisy-Chains, die mit einer ECU kommunizieren sollen, werden auch mehrere CAN/UART-Übersetzer benötigt, was den technischen und ökonomischen Aufwand weiter erhöht. Des Weiteren unterstützen bekannte CAN/UART-Übersetzer nicht ohne weiteres sogenannte Vector Tools (CANalyzer) zur Analyse der übertragenen Daten.
  • Der Erfinder hat es sich zur Aufgabe gemacht, bei gleichbleibenden Sicherheitsanforderungen (ASIL-D) bestehende Systeme zu verbessern und effizienter zu gestalten.
  • ZUSAMMENFASSUNG
  • Die oben genannte Aufgabe wird durch das Verfahren gemäß Anspruch 1, das Batteriemanagementsystem gemäß Anspruch 13 und das CAN/UART-Übersetzermodul gemäß Anspruch 15 gelöst. Verschiedene Ausführungsbeispiele und Weiterentwicklungen sind Gegenstand der abhängigen Ansprüche.
  • Es wird ein Verfahren, insbesondere für ein Batteriemanagementsystem beschrieben. Gemäß einem Ausführungsbeispiel umfasst das Verfahren das Bereitstellen einer digitalen Nachricht, die eine Vielzahl von Frames umfasst, wobei die Vielzahl von Frames einen ID-Frame, einem Adress-Frame, zumindest einen Daten-Frame und einen Prüfsummen-Frame umfassen. Der Prüfsummen-Frame enthält einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde. Das Verfahren umfasst weiter das Erzeugen einer CAN-Nachricht, wobei die in dem (den) Daten-Frame(s) und dem Prüfsummen-Frame enthaltenen Daten in einem Daten-Feld der CAN-Nachricht eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird. Das Verfahren umfasst weiter das Senden der CAN-Nachricht über eine CAN-Bus-Leitung und das Empfangen der CAN-Nachricht und Rekonstruieren der digitalen Nachricht. Des Weiteren werden ein korrespondierendes Batteriemanagementsystem und ein CAN/UART-Übersetzermodul beschrieben.
  • Figurenliste
  • Nachfolgend werden Ausführungsbeispiele anhand von Abbildungen näher erläutert. Die Darstellungen sind nicht zwangsläufig maßstabsgetreu und die Ausführungsbeispiele sind nicht nur auf die dargestellten Aspekte beschränkt. Vielmehr wird Wert darauf gelegt, die den Ausführungsbeispielen zugrunde liegenden Prinzipien darzustellen. In den Abbildungen zeigt:
    • 1 illustriert schematisch ein Beispiel eines Bussystems mit einer BMU und drei damit verbundenen CSC-Modulen, die mit einem Batteriestapel (battery stack) verbunden sind.
    • 2 illustriert ein Beispiel eines verteilten Systems mit einer BMU und zwei damit verbundenen Ketten von CSC-Modulen, wobei die BMU eine CAN-Schnittstelle aufweist und jede der Ketten von CSC-Modulen ein CAN/UART-Übersetzermodul umfasst.
    • 3 illustriert ein Beispiel einer möglichen Implementierung eines CAN/UART-Übersetzermoduls, wobei für das Protokoll-Handling und für Sicherheitsanwendungen jeweils ein separater Mikrocontroller verwendet wird.
    • 4 illustriert ein Beispiel einer effizienteren Implementierung, bei der aufgrund der speziellen Weise der Datenübertragung kein Protokoll-Handler und kein Sicherheits-Mikrocontroller nötig sind.
    • 5 zeigt schematisch den Aufbau einer CAN-Nachricht.
    • 6 illustriert anhand eines Beispiels den Aufbau einer der UART-Frames, die für die Kommunikation mit den CSC-Modulen verwendet werden.
    • 7 illustriert schematisch die Einbettung von UART-Frames in eine CAN Nachricht mit Ende-zu-Ende-Sicherung (End-to-End Protection) der UART-Frames.
    • 8 illustriert die Nutzung des Basis-ID-Feldes einer CAN-Nachricht zur Codierung der Adresse eines CSC-Moduls.
    • 9 illustriert schematisch die Rekonstruktion von UART-Frames aus einer CAN-Nachricht.
    • 10 ist ein Flussdiagramm zur Illustration eines Ausführungsbeispiels des hier beschriebenen Verfahrens zum Datenaustausch zwischen CSC-Modulen und Batterieüberwachungseinheit (BMU).
  • DETAILLIERTE BESCHREIBUNG
  • 1 illustriert schematisch ein Beispiel eines Batteriemanagementsystems (BMS) mit einer Batterieüberwachungseinheit (BMU) 20 und mehreren damit verbundenen Zellüberwachungsschaltungen (CSCs). Im vorliegenden Beispiel sind drei CSCs 31, 32 und 33 mit der BMU 20 in einer Daisy-Chain verbunden. Je nach Anwendung können auch deutlich mehr als drei CSCs aneinandergereiht werden. Die BMU 20 und die der CSCs 31, 32 und 33 sind Teil separater Module (in 1 auch als Module M0-M3 bezeichnet), die voneinander galvanisch getrennt sind und auf verschiedenen Platinen (PCBs, Printed Circuit Boards) angeordnet sein können. Alternativ können auch mehrere CSCs auf einer PCB angeordnet sein. Die galvanische Trennung kann beispielsweise über eine kapazitive Kopplung realisiert werden.
  • Die zu überwachende Batterie 10 kann mehrere Batterie-Packs (Gruppen von Batteriezellen) mit jeweils einer Vielzahl von Batteriezellen aufweisen. Eine Hochvolt-Lithium-Ionen-Batterie mit einer nominellen Batteriespannung von 400V kann z.B. acht Batterie-Packs mit jeweils dreizehn Zellen aufweisen. Jede CSC 31, 32 und 33 ist mit einer Gruppe von Zellen verbunden und empfängt die jeweiligen Zellenspannungen. Je nach Anwendung können auch die Temperaturen der Zellen erfasst werden. Die erwähnte galvanische Trennung kann notwendig sein, um die verschiedenen Spannungsniveaus der einzelnen in Serie geschalteten Batteriezellen zu entkoppeln. Der Zweck und die grundlegenden Funktionen der BMU 20 und der CSCs 31-33 sind an sich bekannt und werden hier nicht näher erläutert.
  • In Bezug auf die Kommunikation zwischen der BMU 20 und den CSCs 31-33 repräsentiert die BMU 20 den Master-Busknoten, und die CSCs 31-33 repräsentieren die Slave-Busknoten. Die einzelnen Module M0-M3 können serielle Kommunikationsschnittstellen (z.B. UARTs) aufweisen, die wie in 1 dargestellt mittels Datenleitung seriell zu einer Daisy-Chain geschaltet sind. Form und Inhalt der UART-Daten-Frames wird später noch detaillierter erläutert.
  • 2 illustriert ein Beispiel eines verteilten BMS mit einer BMU und zwei oder mehr Daisy-Chains mit einer Vielzahl von CSCs. Im vorliegenden Beispiel sind eine erste Daisy-Chain mit CSCs 31-33 (Module M1-M3) und eine zweite Daisy-Chain mit CSCs 41-43 (Module M1'-M3') mit der BMU 20 verbunden. Die Verbindung zwischen den beiden Daisy-Chains und der BMU 20 ist eine indirekte. Die elektronische Steuereinheit ECU, welche die BMU 20 enthält, weist weiter einen CAN-Transceiver auf, um die BMU mit einem CAN-Buskabel L verbinden zu können. Die Kette von CSCs 31-33 ist über einen ersten CAN/UART-Übersetzer 22 mit dem CAN-Buskabel L verbunden, und die Kette von CSCs 41-43 ist über einen zweiten CAN/UART-Übersetzer 23 mit dem CAN-Buskabel L verbunden. Im Vergleich mit dem System aus 1 enthält das Modul M0 der ersten Daisy-Chain (und gleichermaßen das Modul M0' der zweiten Daisy-Chain) nicht die BMU, sondern die erwähnten CAN/UART-Übersetzer 22 und 23.
  • Mit der in 2 dargestellten Struktur ist es möglich, ein verteiltes BMS mit mehreren Ketten von CSCs mit einer in einer zentralen ECU angeordneten BMU zu koppeln. Die „Intelligenz“ - üblicherweise realisiert durch mehr oder weniger komplexe Software - steckt in der BMU. Nichtsdestotrotz können die CAN/UART-Übersetzer 22 und 23 relativ aufwändig zu implementierende Module sein, da insbesondere im Automobilsektor vergleichsweise hohe Anforderungen an die funktionale Sicherheit gestellt werden. So müssen verschiedene Normen (insbesondere ISO26262) und bei Fahrzeugbatterien ist üblicherweise die Sicherheitsanforderungsstufe (Safety Integrity Level) ASIL-D erforderlich. Auch in 2 dargestellt ist ein Analyse-Tool VT zur Analyse des Datenverkehrs auf dem CAN-Bus. Derartige Analyse-Tools (z.B. die eingangs erwähnten Vector-Tools) sind an sich bekannt und können im Entwicklungsprozess eine wichtige Rolle spielen.
  • 3 illustriert ein Beispiel einer möglichen Implementierung eines CAN/UART-Übersetzers. Ein solches Modul (siehe 2, Module M0, MO'), umfasst gemäß dem dargestellten Beispiel einen CAN-Transceiver 220, einen Mikrocontroller 221, der als Protokoll-Handler arbeitet, einen weiteren Mikrocontroller 222 (safety controller), in dem Sicherheitsanwendungen ausgeführt werden, und einen UART-Transceiver 223 zum Anschluss des ersten CSC-Moduls einer Daisy-Chain (siehe 2, Module M1, M1').
  • Der CAN-Transceiver 220 sowie auch der UART-Transceiver 223 stellt (gemäß dem jeweiligen Standard) im Wesentlichen die Funktionen der Schicht 1 (Physical Layer) des allgemein bekannten OSI-Modells (siehe ISO/IEC 7498-1:1994) zur Verfügung. Der Mikrocontroller 221, d.h. der Protokoll-Handler, stellt im Wesentlichen die Funktionen der Schicht 2 (Data Link Layer) des OSI-Modells zur Verfügung, das heißt, jene Funktionen, die auch als „CAN-Protokoll“ bezeichnet werden und die das CAN-Nachrichtenformat (CAN Message Format) betreffen. Der Mikrocontroller 222 stellt Sicherheitsfunktionen zur Verfügung, die notwendig sind, um die hohen Anforderungen von ASIL-D zu erfüllen. Der UART-Transceiver 223 ist mit dem ersten CSC der Daisy-Chain über eine galvanische Trennung verbunden, die in 3 durch die Kondensatoren symbolisiert sind. Der Mikrocontroller 222 ist im Wesentlichen dazu ausgebildet, die empfangenen CAN-Frames in UART-Frames zu konvertieren, wobei zur Datensicherung ein CRC-Wert über die in den UART-Frames enthaltenen Daten berechnet werden muss, weil diese Frame-Konvertierung zu einer Veränderung der Daten führt.
  • Die Implementierung der Protokoll-Handler-Funktionen (Mikrocontroller 221) und der Sicherheits-Funktionen (Mikrocontroller 222) kann technisch relativ aufwändig sein. Des Weiteren unterstützt die CAN/UART-Übersetzer-Struktur aus 3 keine Funktionen zur Analyse des Datenverkehrs, die im Entwicklungsprozess ein wertvolles Hilfsmittel sein können. Derartige Analysefunktionen werden vom CAN-Protokoll unterstützt und sind unter der Bezeichnung „Vector Tools“ bekannt. In diesem Zusammenhang sind Software-Tools der Firma Vector Informatik GmbH praktisch Industriestandard und auch unter der Bezeichnung CANalyzer und CANoe bekannt. Mit Hilfe der Analyse-Tools VT (vgl. 2) kann wie erwähnt der Datenverkehr auf den CAN-Busleitungen „mitgehört“ werden und einem bestimmten Sender und Empfänger zugeordnet werden.
  • Die im Folgenden beschriebenen Ausführungsbeispiele zielen darauf ab, die Implementierung der CAN/UART-Übersetzung zu vereinfachen und effizienter zu gestalten und (optional) die Verwendung von Vector Tools oder ähnlichen Analyse-Werkzeugen bei Batteriemanagementsystemen zu ermöglichen. 4 illustriert einen CAN/UART-Übersetzer gemäß einem Ausführungsbeispiel. Gemäß dem dargestellten Beispiel umfasst der CAN/UART-Übersetzer nur einen CAN-Transceiver 220, eine relativ einfache Logikschaltung 224 und einen UART-Transceiver 223. Wie im vorherigen Beispiel stellen der CAN-Transceiver 220 und der UART-Transceiver 223 im Wesentlichen die Funktionen der Schicht 1 des OSI-Modells zur Verfügung. Auf die Funktion der Logikschaltung 224 wird später noch genauer eingegangen. Die Logikschaltung 224 hat die Aufgabe, den von dem CAN-Transceiver empfangenen Bitstrom einer CAN-Nachricht in UART-Frames zu konvertieren, wobei die in den UART-Frames enthaltenen Daten - inklusive CRC-Wert - schon vollständig in der CAN-Nachricht enthalten sind. Das heißt, die Logikschaltung 224 kann die in UART-Frames zu packenden Bits praktisch direkt aus einer CAN-Nachricht übernehmen, ohne komplexe Bit-Manipulationen durchführen zu müssen (siehe auch 7).
  • Bevor auf die eigentliche CAN/UART-Konversion eingegangen wird, wird anhand von 5 das an sich bekannte CAN-Nachrichtenformat kurz dargestellt. CAN unterstützt zwei Nachrichtenformate, die sich im Wesentlichen in der Länge des ID-Feldes unterscheiden. In dem in 5 dargestellten Standardformat (Base Frame Format) hat das ID-Feld eine Länge von 11 Bits, wohingegen es im erweiterten Format (Extended Frame Format) 29 Bits lang ist. Die Bits bzw. Bit-Felder SOF (Start of Frame), RTR (Remote Transmission Request), IDE (Identifier Extension), RES (reserviert), DLC (Data Length Code), DATA (Datenfeld), CRC (Cyclic Redundancy Check, Prüfsummenfeld), DEL (Delimiter), ACK (Acknowledge), und EOF (End of Frame) einer CAN-Nachricht sind an sich allgemein bekannt und werden hier nicht weiter erläutert. Das 11 Bit lange ID-Feld im Standardformat wird auch als Basis-ID bezeichnet. Diese Basis-ID ist auch im erweiterten Format vorhanden, wobei die übrigen 18 Bits als Extended-ID bezeichnet werden. Die ID muss eindeutig sein und identifiziert die Nachricht und zeigt deren Priorität an. Wenn zwei Busknoten versuchen, eine Nachricht mit derselben ID zu senden, würde das zu einem Fehler führen.
  • 6 illustriert exemplarisch eine Gruppe von UART-Frames, wie sie für die Kommunikation mit CSC-Modulen verwendet werden können. Gemäß 6 umfasst eine Nachricht U (Gruppe von UART-Frames) sechs Frames F1-F6, wobei jeder Frame ein Start-Bit, acht Datenbits und 1 Stopp-Bit aufweist. Die Besonderheit bei der asynchronen Datenübertragung besteht darin, dass der Sender dem Empfänger kein eigenes Taktsignal auf einer eigenen Steuerleitung überträgt. Stattdessen synchronisiert sich der Empfänger über die Länge des Frames, welche dem zeitlichen Abstand von Start- und Stopp-Bit entsprich, und der eingestellten Bitrate. Der Sync-Frame F1 enthält keine nützlichen Daten und dient nur der Synchronisation. Der ID-Frame F2 enthält eine Kennung (Identifier), die ein bestimmtes CSC-Modul bezeichnet. In dem Beispiel aus 3 gibt es sechs Module M1, M2, M3, M1', M2' und M3', denen beispielsweise die IDs 0001, 0010, 0011, 0100, 0101 und 0110 zugeordnet sein können.
  • Der Adress-Frame F3 dient der Adressierung der einem CSC-Modul zugeordneten Zellen. Wie erwähnt kann ein CSC-Modul eine Vielzahl von einzelnen Batteriezellen überwachen. Die Daten-Frames F4 und F5 enthalten die zu sendenden Daten (16-Bit-Wort) und der CRC-Frame F6 enthält eine CRC-Prüfsumme. Es versteht sich, dass die in 6 dargestellte Nachricht U mit sechs Frames F1-F6 lediglich ein Beispiel ist. Je nach Implementierung kann die Nachricht U auch anders strukturiert sein. Unabhängig von der Implementierung kann jedenfalls jedem CSC-Modul eine eindeutige ID und jeder von einem CSC-Modul überwachten Zelle eine eindeutige Adresse zugeordnet werden.
  • 7 illustriert ein Schema wie eine aus einer Gruppe von UART-Frames bestehende Nachricht U in eine CAN-Nachricht gepackt/eingebettet werden, sodass eine CAN/UART-Übersetzung relativ einfach möglich ist. Je nach Kommunikationsrichtung geschieht das Einbetten der Nachricht U in der BMU (Nachricht von BMU an CSC-Modul) oder in einem CAN/UART-Übersetzer (Nachricht von einem CSC-Modul an BMU). Bei der Einbettung der Nachricht U in eine CAN-Nachricht können alle redundanten Daten wie z.B. Start- und Stopp-Bits (und ggf. Parity-Bits) weggelassen werden. Auch der Sync-Frame F1 muss nicht in die CAN-Nachricht gepackt werden, da der Sync-Frame F1 keine Information beinhaltet.
  • Die in dem ID-Frame F2 enthaltene Kennung wird in einem Sub-Feld der Base-ID der CAN-Nachricht übertragen. Beispielsweise wird die Kennung des CSC-Moduls in die vier Bits mit dem niedrigsten Stellenwert (least significant bits) geschrieben. Der Adress-Frame F3 und die Daten-Frames F4 und F5 sowie der CRC-Frame F6 werden in das Datenfeld DATA der CAN-Nachricht geschrieben, wobei der in dem CRC-Frame F6 enthalten CRC-Wert beispielsweise über die Daten der Frames F1-F5 (oder alternativ F2-F5) berechnet werden kann. Da der CRC-Wert im Sender der Nachricht U generiert und in der CAN-Nachricht bis zum Empfänger mit übertragen wird, findet eine Ende-zu-Ende-Sicherung statt. Spezielle Sicherungsfunktionen sind daher in dem CAN/UART-Übersetzer nicht mehr notwendig.
  • Um die Analyse der Kommunikation mittels standardisierter Analyse-Tools (Vector-Tools, z.B. CANalyzer, CANoe, oder ähnliches) zu ermöglichen, werden die verbleibenden sieben Bits der Basis-ID genutzt, Metadaten zu übertragen. Beispielsweise können die Adresse der Batteriezelle (Inhalt des Adress-Frames F3) sowie weitere Informationen über die gesendeten Daten in der Basis-ID gespeichert werden. So können z.B. auch Informationen über die Art der Daten in den Frames F4 und F5 (z.B. ob es sich um Temperatur- oder Spannungswerte handelt) gespeichert werden. Des Weiteren kann in der Basis-ID die Richtung der Kommunikation (von oder zu der BMU) enthalten sein. Die Richtung der Kommunikation kann z.B. durch das Bit mit dem höchsten Stellenwert (Most Significant Bit, Bit 10) der Basis-ID angezeigt werden. Weitere Informationen können beispielsweise mittels einer Lookup-Tabelle LUT codiert und in das Sub-Feld mit den Bits 4-9 gespeichert werden. Die Bits 0-3 der Basis-ID repräsentieren wie erwähnt die Kennung des betreffenden CSC-Moduls. Gemäß einem Ausführungsbeispiel umfassen die weiteren, mittels der Lookup-Tabelle codierten Informationen die in dem Adress-Frame enthaltene Adresse. In diesem Fall muss der Inhalt des Adress-Frames nicht notwendigerweise in dem CAN-Datenfeld übertragen werden (was redundant wäre).
  • 8 illustriert schematisch ein Beispiel einer Basis-ID einer CAN-Nachricht, die mit den Informationen aus den UART-Frames „gefüllt“ wurde. Links befindet sich das Bit mit dem höchsten Stellenwert (MSB, Bit 10). Dieses zeigt die Richtung der Kommunikation an, wobei im dargestellten Beispiel „0“ anzeigt, dass die Nachricht von einem CSC-Modul (Bus-Slave) zu der BMU (Bis-Master) geschickt wird. Umgekehrt zeigt eine „1“ an, dass die Nachricht von der BMU zu einem CSC-Modul geschickt wird. Die folgenden sechs Bits (Bits 4-9) repräsentieren die Adresse der Batteriezelle und ggf. weitere Informationen (Metadaten) wie z.B. die Art der übertragenen Daten (Temperatur, Spannung, etc.). Die vier Bits mit dem niedrigsten Stellenwert (Bit 0-3) stellen wie erwähnt die Kennung des CSC-Moduls dar. Diese Kennung kann direkt dem ID-Frame F1 (siehe 6) entnommen werden.
  • 9 illustriert schematisch die Rekonstruktion von UART-Frames aus einer CAN-Nachricht. Der Inhalt des Datenfeldes (im vorliegenden Beispiel 32 Bit) kann direkt auf die Frames F3-F6 verteilt werden, die Start- und Stopp-Bits werden ergänzt. Der Inhalt des ID-Frames F2 kann direkt aus dem Basis-ID-Feld der CAN-Nachricht bezogen werden. Der Sync-Frame F1 kann einfach ergänzt werden, da dazu keine Informationen aus der CAN-Nachricht benötigt werden. Wie erwähnt muss die Adresse nicht notwendigerweise in dem CAN-Datenfeld übertragen werden, sondern die Information kann auch (ggf. mittels der Lookup-Tabelle LUT kodiert) in dem ID-Feld enthalten sein. In diesem Fall kann die in dem Adress-Frame F3 enthaltene Adresse auch basierend auf der in dem ID-Feld der CAN-Nachricht enthaltenen Information rekonstruiert werden.
  • Der Empfänger der Frames F1-F6 (Nachricht U) kann den CRC-Wert, der im CRC-Frame übertragen wurde prüfen und somit feststellen, ob die Integrität der Daten gegeben ist. Der CRC-Wert wurde direkt im Sender erzeugt und wurde bei der CAN/UART-Konversion nicht geändert und (im CRC-Frame F6) einfach an den Empfänger weitergereicht. Weitere Funktionen zur Datensicherung sind in dem CAN/UART- Übersetzer nicht nötig.
  • Die hier beschriebenen Ausführungsbeispiele und deren Funktionsweise werden im Folgenden zusammengefasst. 10 ist ein Flussdiagramm zur Illustration eines Beispiels des hier beschriebenen Verfahrens zum Datenaustausch zwischen CSC-Modulen (vgl. 2, CSC-Module M2, M3, etc.) und einer BMU (vgl. 2, BMU 20). Gemäß 10 umfasst das Verfahren das Bereitstellen einer digitalen Nachricht U (vgl. 6), die eine Vielzahl von Frames umfasst, wobei die Vielzahl von Frames einen ID-Frame F2, einen Adress-Frame F3, zumindest einen Daten-Frame F4, F5 und einen Prüfsummen-Frame F6 umfassen, der einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde (siehe 10, Schritt S1). Das Verfahren umfasst weiter das Erzeugen einer CAN-Nachricht F (vgl. 7), wobei die in dem Adress-Frame F3, dem Daten-Frame F4, F5 und dem Prüfsummen-Frame F6 enthaltenen Daten in einem Daten-Feld der CAN-Nachricht eingefügt werden (siehe 10, Schritt S2a) und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird (siehe 10, Schritt S2b). Das Erzeugen der CAN-Nachricht F aus der UART-Nachricht U wurde oben bereits unter Bezugnahme auf 7 und 8 erläutert. Wie erwähnt ermöglicht die Tatsache, dass der CRC-Wert mit der CAN-Nachricht F mit übertragen wird eine Ende-zu-Ende-Sicherung der übertragenen Daten. Schließlich wird die CAN-Nachricht F über die CAN-Bus-Leitung ausgesendet (siehe 10, Schritt S3). Vom Empfänger wird die CAN-Nachricht F empfangen und daraus wird die digitalen Nachricht U (bzw. die darin enthaltenen Daten/Information) rekonstruiert (siehe 10, Schritt S4). Anhand des in der CAN-Nachricht F übertragenen CRC-Wertes kann die Integrität der ursprünglichen Nachricht U geprüft werden.
  • Die in 10 dargestellte Datenübertragung ist in beide Richtungen möglich, d.h. von der BMU 20 zu den CSC-Modulen M1, M2, ..., M1', M2', etc. (Downlink-Richtung) und von den CSC-Modulen zur BMU (Uplink-Richtung). Bei der Uplink-Kommunikation wird die digitale Nachricht U von einem der CSC-Module bereitgestellt, d.h. der Schritt S1 wird von dem jeweiligen CSC-Modul durchgeführt. Das Erzeugen der CAN-Nachricht F (Schritte S2a und S2b) sowie das Senden der CAN-Nachricht F (Schritt S3) wird von dem CAN/UART -Übersetzermodul M0, M0' (vgl. 2) durchgeführt, mit dem das sendende CSC-Modul über die Datenleitung gekoppelt ist. Der Empfang der CAN-Nachricht und die Rekonstruktion der ursprünglichen digitalen Nachricht U erfolgt in der BMU 20.
  • Bei der Downlink-Kommunikation wird die digitale Nachricht U von der BMU 20 bereitgestellt, d.h. der Schritt S1 (inkl. Berechnung des CRC-Wertes) wird von der BMU durchgeführt. Auch das Erzeugen der CAN-Nachricht F (Schritte S2a und S2b) sowie das Senden der CAN-Nachricht F (Schritt S3) werden von der BMU durchgeführt. Die gesendete CAN-Nachricht wird von einem der CAN/UART-Übersetzermodule M0, M0' (vgl. 2) empfangen (Schritt S4). Die CAN/UART-Übersetzermodule M0, M0'können anhand des ID-Feldes der CAN-Nachricht F erkennen, für welches CSC-Modul die Nachricht bestimmt ist, und die Rekonstruktion der ursprünglichen digitalen Nachricht U erfolgt zumindest in jenem CAN/UART-Übersetzermodul, welches mit dem jeweiligen CSC-Modul verbunden ist.
  • Gemäß den hier beschriebenen Beispielen umfasst im Falle der Downlink-Kommunikation das Verfahren das Weiterleiten der rekonstruierten digitalen Nachricht U mittels serieller Datenübertragung über die Datenleitung an ein oder mehrere CSC-Module, die durch die in dem ID-Frame enthaltene Kennung festgelegt sind. Die Kennung kann auch einen Broadcast repräsentieren, d.h. in diesem Fall werden alle CSC-Module adressiert. Die CSC-Module M1, M2, ..., M1', M2', etc. können jeweils mit mehreren Batteriezellen gekoppelt sein. Eine in dem Adress-Frame F3 (siehe 7) enthaltene Adresse bezeichnet eine bestimmte Batteriezelle, auf die sich die in dem zumindest einen Daten-Frame F4, F5 enthaltenen Daten beziehen. Diese Daten können - insbesondere im Falle einer Uplink-Kommunikation - z.B. eine Zellenspannung und/oder eine Zellentemperatur der Batteriezelle repräsentieren. Im Falle einer Downlink-Kommunikation können die in dem (den) Daten-Frame(s) F4, F5 enthaltenen Daten z.B. Steuerkommandos, Konfigurationsdaten und/oder dergleichen repräsentieren.
  • Das erwähnte Erzeugen der CAN-Nachricht F basierend auf der digitalen Nachricht U umfasst gemäß einem bestimmten Ausführungsbeispiel weiter das Codieren der in dem Adress-Frame F3 enthaltenen Adresse und das Einfügen dieser codierten Adresse in das ID-Feld der CAN-Nachricht F. Dieses Codieren kann z.B. mittels einer Lookup-Tabelle erfolgen (vgl. 7, Lookup-Tabelle LUT). Des Weiteren kann ein Bit in dem ID-Feld der CAN-Nachricht F gesetzt werden, welches anzeigt, ob die CAN Nachricht von der Batterieüberwachungseinheit (20) oder zu der Batterieüberwachungseinheit (20) hin übertragen wird oder umgekehrt (vgl. 8). Dieses Bit (Richtungs-Bit) zeigt also an, ob es sich bei einer bestimmten Nachricht um eine Uplink- oder Downlink-Kommunikation handelt.
  • Ein weiteres Ausführungsbeispiel betrifft ein Batteriemanagementsystem (BMS) mit einer Batterieüberwachungseinheit (BMU), welche z.B. in einer ECU eines Fahrzeugs enthalten sein kann, mit einem Übersetzermodul (vgl. 2, CAN/UART-Übersetzer M0), welches mit der BMU über eine CAN-Busleitung verbunden ist, und mit einer Vielzahl von zu einer Daisy-Chain verbundenen CSC-Modulen (siehe 2, z.B. CSC-Module M1-M3), die mit dem Übersetzermodul mittels einer Datenleitung verbunden sind. Das Übersetzermodul und die CSC-Module sind dazu ausgebildet, mittels asynchroner serieller Datenübertragung über die Datenleitung digitale Nachrichten U auszutauschen, wobei die digitalen Nachrichten jeweils eine Vielzahl von Frames umfassen (vgl. 6), die jeweils einen ID-Frame, einen Adress-Frame, einen oder mehrere Daten-Frames sowie einen Prüfsummen-Frame (CRC-Frame) umfassen. Letzterer enthält einen Prüfsummenwert, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde (was die erwähnte Ende-zu-Ende-Sicherung der Daten ermöglicht). Das Übersetzermodul ist dazu ausgebildet (für die Uplink-Kommunikation), basierend auf einer von einem der CRC-Module empfangenen digitalen Nachricht U eine entsprechende CAN-Nachricht F zu erzeugen, wobei die in dem Adress-Frame, dem (den) Daten-Frame(s) und dem Prüfsummen-Frame enthaltenen Daten in das Daten-Feld der CAN-Nachricht F eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in das ID-Feld der CAN-Nachricht eingefügt wird. ID- und Datenfeld der CAN-Nachricht sind wie oben im Detail erläutert standardisiert. Anschließend kann das Übersetzermodul die CAN-Nachricht über eine CAN-Busleitung an die BMU senden. Die BMU ist dazu ausgebildet, die CAN-Nachricht F von dem Übersetzermodul zu empfangen und die in der digitalen Nachricht U, aus der die CAN-Nachricht erzeugt wurde, enthaltenen Informationen zu rekonstruieren.
  • Die CAN/UART-Übersetzung kann z.B. von einer in dem Übersetzermodul M0 enthaltenen Logikschaltung umgesetzt werden. Diese Logikschaltung kann beispielsweise einen endlichen Automaten (auch als finite Zustandsmaschine, FSM, bezeichnet) umfassen. Des Weiteren kann die Logikschaltung festverdrahtete oder einmal programmierbare Logik beinhalten sowie auch einen Prozessor, der dazu ausgebildet ist, Software-Instruktionen auszuführen und dadurch die notwendigen Funktionen bereitzustellen. Es versteht sich, dass dem Fachmann eine Vielzahl praktisch äquivalenter Optionen bekannt sind, die Funktionen der hier beschriebenen Ausführungsbeispiele zu implementieren.

Claims (16)

  1. Verfahren, das folgendes aufweist: Bereitstellen einer digitalen Nachricht (U), die eine Vielzahl von Frames (F2, F3, F4, F5, F6) umfasst, wobei die Vielzahl von Frames einen ID-Frame (F2), einen Adress-Frame (F3), zumindest einen Daten-Frame (F4, F5) und einen Prüfsummen-Frame (F6) umfasst, der einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames (F2, F3, F4, F5) enthaltenen Daten berechnet wurde; Erzeugen einer CAN-Nachricht, wobei die in dem Daten-Frame (F4, F5) und dem Prüfsummen-Frame (F6) enthaltenen Daten in ein Daten-Feld der CAN-Nachricht eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird; Senden der CAN-Nachricht über eine CAN-Bus-Leitung; Empfangen der CAN-Nachricht und Rekonstruieren der digitalen Nachricht (U).
  2. Das Verfahren gemäß Anspruch 1, wobei in dem ID-Frame (F2) eine Kennung enthalten ist, die ein Batteriezellenüberwachungsmodul (M1-M3) eines Batteriemanagementsystems bezeichnet, und wobei in dem Adress-Frame (F3) eine Adresse enthalten ist, die eine mit dem Batteriezellenüberwachungsmodul (M1-M3) gekoppelte Batteriezelle bezeichnet.
  3. Das Verfahren gemäß Anspruch 1, wobei die digitale Nachricht (U) von einem aus mehreren Batteriezellenüberwachungsmodulen (M1-M3) eines Batteriemanagementsystems bereitgestellt wird, wobei das die digitale Nachricht (U) bereitstellende Batteriezellenüberwachungsmodul eine Kennung hat, die in dem ID-Frame (F2) enthalten ist, und wobei die CAN-Nachricht von einer Batterieüberwachungseinheit (20) des Batteriemanagementsystems empfangen wird
  4. Das Verfahren gemäß Anspruch 1, wobei die digitale Nachricht (U) von einer Batterieüberwachungseinheit (20) eines Batteriemanagementsystems bereitgestellt wird, und wobei die CAN-Nachricht von einem Übersetzermodul (M0) empfangen wird, welches die digitale Nachricht (U) rekonstruiert.
  5. Das Verfahren gemäß Anspruch 1 oder 4, das weiter aufweist: Weiterleiten der rekonstruierten digitalen Nachricht mittels serieller Datenübertragung über eine Datenleitung an einen oder mehrere Empfänger, die durch die in dem ID-Frame enthaltene Kennung festgelegt sind.
  6. Das Verfahren gemäß Anspruch 5, soweit rückbezogen auf Anspruch 4, wobei die Empfänger Batteriezellenüberwachungsmodule (M1-M3) sind, welche mit der Datenleitung verbunden sind.
  7. Das Verfahren gemäß Anspruch 6, wobei die Batteriezellenüberwachungsmodule (M1-M3) zu einer Daisy-Chain verbunden sind und ein erstes der Batteriezellenüberwachungsmodule (M1-M3) an die Datenleitung angeschlossen ist.
  8. Das Verfahren gemäß Anspruch 3 oder 7, wobei die Batteriezellenüberwachungsmodule (M1-M3) mit mehreren Batteriezellen gekoppelt sind und eine in dem Adress-Frame (F3) enthaltene Adresse eine bestimmte Batteriezelle bezeichnet, auf die sich die in dem zumindest einen Daten-Frame (F4, F5) enthaltenen Daten beziehen.
  9. Das Verfahren gemäß Anspruch 8, wobei die in dem zumindest einen Daten-Frame (F4, F5) enthaltenen Daten eine Zellenspannung und/oder eine Zellentemperatur der Batteriezelle repräsentieren.
  10. Das Verfahren gemäß einem der Ansprüche 1 bis 9, , wobei das Erzeugen der CAN-Nachricht weiter umfasst: Codieren der in dem Adress-Frame (F3) enthaltene Adresse und Einfügen der codierten Adresse in das ID-Feld der CAN-Nachricht und/oder wobei die in dem Adress-Frame (F3) enthaltenen Daten in das Daten-Feld der CAN-Nachricht eingefügt werden.
  11. Das Verfahren gemäß Anspruch 10, wobei Codieren mittels einer Lookup-Tabelle erfolgt.
  12. Das Verfahren gemäß einem der Ansprüche 1 bis 11 soweit rückbezogen auf Anspruch 4, wobei das Erzeugen der CAN-Nachricht weiter umfasst: Setzen eines Bits in dem ID-Feld der CAN-Nachricht, welches anzeigt, ob die CAN Nachricht von der Batterieüberwachungseinheit (20) oder zu der Batterieüberwachungseinheit (20) hin übertragen wird.
  13. Ein Batteriemanagementsystem, welches aufweist: eine Batterieüberwachungseinheit (20), ein Übersetzermodul (M0), welches mit der Batterieüberwachungseinheit (20) über eine CAN-Busleitung verbunden ist; eine Vielzahl von zu einer Daisy-Chain verbundenen Batteriezellenüberwachungsmodulen (M1-M3), die mit dem Übersetzermodul (M0) mittels einer Datenleitung verbunden sind, wobei das Übersetzermodul (M0) und die Batteriezellenüberwachungsmodule (M1-M3) dazu ausgebildet sind, mittels asynchroner serieller Datenübertragung über die Datenleitung digitale Nachrichten (U) auszutauschen, wobei die digitalen Nachrichten (U) jeweils eine Vielzahl von Frames (F2, F3, F4, F5, F6) umfassen, die jeweils einen ID-Frame (F2), einen Adress-Frame (F3), zumindest einen Daten-Frame (F4, F5) und einen Prüfsummen-Frame (F6) umfassen, der einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde; und wobei das Übersetzermodul (M0) dazu ausgebildet ist: basierend auf einer von einem der Batteriezellenüberwachungsmodule (M1-M3) empfangenen digitalen Nachricht (U) eine CAN-Nachricht zu erzeugen, wobei die in dem Daten-Frame (F4, F5) und dem Prüfsummen-Frame (F6) enthaltenen Daten in ein Daten-Feld der CAN-Nachricht eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird; und die CAN-Nachricht über eine CAN-Busleitung an die Batterieüberwachungseinheit (20) zu senden.
  14. Das Batteriemanagementsystem gemäß Anspruch 13, wobei die Batterieüberwachungseinheit (20) dazu ausgebildet ist, die CAN-Nachricht von dem Übersetzermodul (M0) zu empfangen und die in der digitalen Nachricht (U), aus der die CAN-Nachricht erzeugt wurde, enthaltenen Informationen zu rekonstruieren.
  15. Ein CAN/UART-Übersetzermodul (M0), das aufweist: eine UART-Schnittstelle zum Anschluss einer Vielzahl von zu einer Daisy-Chain verbundenen Batteriezellenüberwachungsmodulen (M1-M3) mittels einer Datenleitung; einen CAN-Transceiver zum Anschluss einer Batterieüberwachungseinheit (20) mittels einer CAN-Busleitung; eine Logikschaltung, die dazu ausgebildet ist: mittels asynchroner serieller Datenübertragung über die Datenleitung digitale Nachrichten (U) zu übertragen und zu empfangen, wobei die digitalen Nachrichten (U) jeweils eine Vielzahl von Frames (F2, F3, F4, F5, F6) umfassen, die jeweils einen ID-Frame (F2), einen Adress-Frame (F3), zumindest einen Daten-Frame (F4, F5) und einen Prüfsummen-Frame (F6) umfassen, der einen Prüfsummenwert enthält, der basierend auf den in den anderen Frames enthaltenen Daten berechnet wurde; basierend auf einer empfangenen digitalen Nachricht (U) eine CAN-Nachricht zu erzeugen, wobei die in dem Daten-Frame (F4, F5) und dem Prüfsummen-Frame (F6) enthaltenen Daten in einem Daten-Feld der CAN-Nachricht eingefügt werden und wobei eine in dem ID-Frame enthaltene Kennung in ein ID-Feld der CAN-Nachricht eingefügt wird; und die CAN-Nachricht über die CAN-Busleitung zu senden.
  16. Das CAN/UART-Übersetzermodul gemäß Anspruch 15, wobei die Logikschaltung weiter dazu ausgebildet ist eine CAN-Nachricht zu empfangen und die in der digitalen Nachricht (U), aus der die CAN-Nachricht erzeugt wurde, enthaltenen Informationen zu rekonstruieren und eine rekonstruierte digitale Nachricht über die Datenleitung zu senden.
DE102020121102.3A 2020-08-11 2020-08-11 Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem Active DE102020121102B3 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE102020121102.3A DE102020121102B3 (de) 2020-08-11 2020-08-11 Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem
US17/343,309 US11956097B2 (en) 2020-08-11 2021-06-09 Battery management system and method for data transmission in a battery management system
CN202110912948.4A CN114079591A (zh) 2020-08-11 2021-08-10 电池管理系统和用于在电池管理系统中传输数据的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102020121102.3A DE102020121102B3 (de) 2020-08-11 2020-08-11 Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem

Publications (1)

Publication Number Publication Date
DE102020121102B3 true DE102020121102B3 (de) 2022-02-03

Family

ID=79300811

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020121102.3A Active DE102020121102B3 (de) 2020-08-11 2020-08-11 Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem

Country Status (3)

Country Link
US (1) US11956097B2 (de)
CN (1) CN114079591A (de)
DE (1) DE102020121102B3 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102258814B1 (ko) * 2018-10-04 2021-07-14 주식회사 엘지에너지솔루션 Bms 간 통신 시스템 및 방법
CN115242652A (zh) * 2022-06-21 2022-10-25 宁德伊控动力系统有限公司 一种多簇电池包管理系统的网络拓扑装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105306323A (zh) 2015-09-22 2016-02-03 山东超越数控电子有限公司 一种can总线通信的方法及装置
US20170346308A1 (en) 2016-05-31 2017-11-30 Infineon Technologies Ag Power balancing communication for battery management
EP3591986A1 (de) 2018-07-04 2020-01-08 Volkswagen AG Schaltungsanordnung

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5854454A (en) * 1996-09-16 1998-12-29 Otis Elevator Company Message routing in control area network (CAN) protocol
US7403560B2 (en) * 2004-02-09 2008-07-22 Lecroy Corporation Simultaneous physical and protocol layer analysis
US9215168B2 (en) * 2012-07-23 2015-12-15 Broadcom Corporation Controller area network communications using ethernet
US9425992B2 (en) * 2014-02-20 2016-08-23 Freescale Semiconductor, Inc. Multi-frame and frame streaming in a controller area network (CAN) with flexible data-rate (FD)
US10374444B2 (en) * 2014-08-26 2019-08-06 Elite Power Innovations, Llc. Method and system for battery management
US20160162268A1 (en) * 2014-12-08 2016-06-09 Nec Energy Solutions, Inc. Serial protocol communications between a computerized user device and a battery module
JP6962697B2 (ja) * 2016-05-27 2021-11-05 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America ネットワークハブ、転送方法及び車載ネットワークシステム
US11409688B1 (en) * 2019-11-01 2022-08-09 Yellowbrick Data, Inc. System and method for checking data to be processed or stored
US11145908B1 (en) * 2020-04-01 2021-10-12 Sensata Technologies, Inc. Listening only wireless network controller in a wireless battery management system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105306323A (zh) 2015-09-22 2016-02-03 山东超越数控电子有限公司 一种can总线通信的方法及装置
US20170346308A1 (en) 2016-05-31 2017-11-30 Infineon Technologies Ag Power balancing communication for battery management
EP3591986A1 (de) 2018-07-04 2020-01-08 Volkswagen AG Schaltungsanordnung

Also Published As

Publication number Publication date
CN114079591A (zh) 2022-02-22
US20220052872A1 (en) 2022-02-17
US11956097B2 (en) 2024-04-09

Similar Documents

Publication Publication Date Title
DE102010016283B4 (de) Verfahren zur Übertragung von Daten über einen CANopen-Bus sowie Verwendung des Verfahrens zum Konfigurieren und/oder Parametrieren von Feldgeräten über den CANopen-Bus
DE102020121102B3 (de) Batteriemanagementsystem und verfahren zur datenübertragung in einem batteriemanagementsystem
AT514851B1 (de) Verfahren zur Rekonstruktion eines in einem drahtlosen Sensornetzwerk fehlerhaft empfangenen Datenpakets
DE2626838B2 (de) Prüf-Schaltungsanordnung für eine Fernmeldeinstallation
EP3632040B1 (de) Verarbeitung von prozessdaten
WO2007051595A1 (de) Verfahren sowie system zur übertragung von zyklischen und azyklischen daten
DE102014221678A1 (de) Verfahren und Einrichtung zum Bereitstellen eines Fahrtenschreiberdienstes zur Fahrzeugdiagnose unter Verwendung einer fahrzeuginternen Zeitsynchronisationsnachricht.
DE112006002202B4 (de) Optimierungs-Controller und Verfahren zum Übertragen einer Mehrzahl von Nachrichten
EP2733910B1 (de) BUS-System, Verfahren zum Betrieb eines BUS-Systems und fluidisches System mit einem BUS-System
EP3568322B1 (de) Zentrale datenablage im bordnetz
WO2020193440A1 (de) Teilnehmerstation für ein serielles bussystem und verfahren zur kommunikation in einem seriellen bussystem
EP2203821B1 (de) Verfahren zur sicheren datenübertragung und gerät
WO2021165490A1 (de) Batteriemodul zum aufbau eines batteriesystems für ein fahrzeug
WO2018215290A1 (de) Initialisierung eines lokalbusses
WO2018188779A1 (de) Kommunikationssystem zur seriellen kommunikation zwischen kommunikationsgeräten
DE102017117288A1 (de) Datenübertragungsverfahren zwischen einem Drehwinkelgeber und einer Motorsteuereinrichtung oder einer Auswerteeinheit
EP3632054B1 (de) Bestimmung von datenbusteilnehmern eines lokalbusses
EP2605457A1 (de) Verfahren zum Übertragen von Nutzdaten
DE10330596A1 (de) Zuordnung von Stationsadressen zu Kommunikationsteilnehmern in einem Bussystem
DE10357422A1 (de) Verfahren zur Übertragung von Daten über einen Datenbus sowie System und Gateway zur Durchführung des Verfahrens
DE102010003741A1 (de) Verfahren zum Datenaustausch
DE102013204891B4 (de) Verfahren zur Rekonstruktion von Messdaten
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
EP2710436A1 (de) Verfahren und vorrichtung zur parametrierung eines as-i-slaves
DE102019125693A1 (de) Verfahren zum Betreiben eines Kommunikationsnetzwerks, Kommunikationsnetzwerk und Teilnehmer für ein Kommunikationsnetzwerk

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000

R020 Patent grant now final
R082 Change of representative