DE102014112095B4 - Verfahren zum Überwachen eines Fehlers in einem Controller Area Network - Google Patents

Verfahren zum Überwachen eines Fehlers in einem Controller Area Network Download PDF

Info

Publication number
DE102014112095B4
DE102014112095B4 DE102014112095.7A DE102014112095A DE102014112095B4 DE 102014112095 B4 DE102014112095 B4 DE 102014112095B4 DE 102014112095 A DE102014112095 A DE 102014112095A DE 102014112095 B4 DE102014112095 B4 DE 102014112095B4
Authority
DE
Germany
Prior art keywords
fault
inactive
controller
nodes
node
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
DE102014112095.7A
Other languages
English (en)
Other versions
DE102014112095A1 (de
Inventor
Shengbing Jiang
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.)
GM Global Technology Operations LLC
Original Assignee
GM Global Technology Operations LLC
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 GM Global Technology Operations LLC filed Critical GM Global Technology Operations LLC
Publication of DE102014112095A1 publication Critical patent/DE102014112095A1/de
Application granted granted Critical
Publication of DE102014112095B4 publication Critical patent/DE102014112095B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3048—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the topology of the computing system or computing system component explicitly influences the monitoring activity, e.g. serial, hierarchical systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G06F11/2205—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing using arrangements specific to the hardware being tested
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • 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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • 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
    • 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
    • Y04—INFORMATION OR COMMUNICATION TECHNOLOGIES HAVING AN IMPACT ON OTHER TECHNOLOGY AREAS
    • Y04S—SYSTEMS INTEGRATING TECHNOLOGIES RELATED TO POWER NETWORK OPERATION, COMMUNICATION OR INFORMATION TECHNOLOGIES FOR IMPROVING THE ELECTRICAL POWER GENERATION, TRANSMISSION, DISTRIBUTION, MANAGEMENT OR USAGE, i.e. SMART GRIDS
    • Y04S40/00—Systems for electrical power generation, transmission, distribution or end-user application management characterised by the use of communication or information technologies, or communication or information technology specific aspects supporting them

Abstract

Verfahren zum Überwachen eines Controller Area Network (CAN) an einem mobilen System, das mehrere CAN-Elemente umfasst, die einen Kommunikationsbus und mehrere Knoten umfassen, umfassend, dass:
inaktive Knoten des CAN detektiert werden;
ein externer Controller eingesetzt wird, um einen Kandidatenfehler in dem CAN auf der Grundlage der inaktiven Knoten des CAN und einer Netztopologie für das CAN zu identifizieren; und
ein Fehler in dem CAN auf der Grundlage des Kandidatenfehlers isoliert wird; dadurch gekennzeichnet, dass
das Einsetzen des externen Controllers zum Identifizieren eines Kandidatenfehlers in dem CAN umfasst, dass:
die inaktiven Knoten des CAN mit mehreren Fehlersignaturvektoren, die der Netztopologie für das CAN zugehörig sind, verglichen werden;
einer der Fehlersignaturvektoren, die dem inaktiven Knoten des CAN entsprechen, identifiziert wird;
ein Fehlersymptom ermittelt wird, das dem identifizierten Fehlersignaturvektor zugehörig ist; und
der Kandidatenfehler in dem CAN auf der Grundlage des Fehlersymptoms identifiziert wird.

Description

  • TECHNISCHES GEBIET
  • Diese Erfindung betrifft ein Verfahren gemäß dem Oberbegriff des Anspruchs 1 zum Überwachen eines Controller Area Network (CAN) an einem mobilen System, wie es der Art nach im Wesentlichen aus der DE 10 2008 002 738 A1 bekannt ist.
  • HINTERGRUND
  • Fahrzeugsysteme umfassen mehrere Subsysteme, die beispielsweise Motor, Getriebe, Fahrgefühl/Handhabung, Bremsung, HLK und Insassenschutz umfassen. Es können mehrere Controller eingesetzt werden, um den Betrieb der Subsysteme zu überwachen und zu steuern. Die Controller können ausgestaltet sein, um über ein Controller Area Network (CAN) zu kommunizieren, um den Betrieb des Fahrzeugs in Ansprechen auf Bedienerbefehle, Fahrzeugbetriebszustände und externe Bedingungen zu koordinieren. In einem der Controller kann ein Fehler auftreten, der Kommunikationen über einen CAN-Bus beeinflusst.
  • Die Topologie eines Netzes, wie beispielsweise eines CAN, bezieht sich auf eine verbindende Anordnung zwischen Netzelementen und umfasst vorzugsweise mehrere Knoten mit gekoppelten oder verteilten Leistungs-, Masse- oder Kommunikationsverbindungen dazwischen. Eine physikalische Topologie beschreibt die Anordnung oder Aufteilung physikalischer Elemente, die Verbindungen und Knoten umfassen, wobei Knoten Controller umfassen und andere verbundene Einrichtungen und Verbindungen entweder Leistungs-, Masse- oder Kommunikationsverbindungen umfassen. Eine logische Topologie beschreibt den Fluss von Datennachrichten oder Leistung in einem Netz zwischen Knoten, wobei Verbindungen eingesetzt werden. Bekannte CAN-Systeme setzen eine Bustopologie für die Kommunikationsverbindung zwischen allen Controllern ein, die eine Linientopologie, eine Sterntopologie oder eine Kombination aus Stern- und Linientopologie umfassen kann. Bekannte CAN-Systeme für hohe Geschwindigkeit setzen eine Linientopologie ein, wohingegen bekannte CAN-Systeme für niedrige Geschwindigkeit eine Kombination aus Stern- und Linientopologie einsetzen. Bekannte CAN-Systeme setzen separate Leistungs- und Massetopologien für die Leistungs- und Masseleitungen zu allen Controllern ein. Bekannte Controller kommunizieren über Nachrichten miteinander, die in verschiedenen Perioden an dem CAN-Bus gesendet werden.
  • Bekannte Systeme detektieren Fehler an einem Nachrichtenempfangscontroller, wobei die Fehlerdetektion für die Nachricht unter Verwendung einer Signalkontrolle und einer Signalzeitüberschreitungsüberwachung an einer Interaktionsschicht des Controllers erreicht wird. Die Fehler können als Verlust von Kommunikationen, z.B. als Verlust einer übermittelten Datennachricht, berichtet werden. Solche Detektionssysteme sind im Allgemeinen nicht dazu in der Lage, eine Grundursache eines Fehlers zu identifizieren, und sind nicht dazu in der Lage, transiente und intermittierende Fehler zu unterscheiden. Ein bekanntes System erfordert eine separate Überwachungshardware und dimensionale Details einer physikalischen Topologie eines Netzes, um Kommunikationsfehler in dem Netz effektiv zu überwachen und zu detektieren.
  • ZUSAMMENFASSUNG
  • Erfindungsgemäß wird ein Verfahren zum Überwachen eines Controller Area Network (CAN) an einem mobilen System vorgestellt, das die Merkmale des Anspruchs 1 aufweist.
  • Figurenliste
  • Nachstehend werden eine oder mehrere Ausführungsformen beispielhaft in Bezug auf die begleitenden Zeichnungen beschrieben, in denen:
    • 1 ein mobiles Fahrzeug, das ein Controller Area Network (CAN) umfasst, welches einen CAN-Bus und mehrere Knoten, z.B. Controller, umfasst, und eine externe Einrichtung gemäß der Offenbarung zeigt;
    • 2 ein beispielhaftes CAN, das Controller, einen Überwachungscontroller, eine Leistungsversorgung, eine Batteriesterneinrichtung und eine Masse, die jeweils über eine Verbindung verbunden sind, umfasst, gemäß der Offenbarung zeigt;
    • 3 eine bordeigene CAN-Überwachungsroutine, die inaktive Controller in einem CAN detektiert, gemäß der Offenbarung zeigt; und
    • 4 eine externe Fehlerisolierungsroutine zum Ermitteln von Fehlerkandidaten, d.h. unterbrochenen Verbindungen, Kurzschlüssen oder fehlerhaften Controllern, wobei Fehlersignaturvektoren eingesetzt werden, gemäß der Offenbarung zeigt.
  • DETAILLIERTE BESCHREIBUNG
  • Nun auf die Zeichnungen Bezug nehmend, wobei die Darstellungen lediglich dem Zweck des Erläuterns bestimmter beispielhafter Ausführungsformen dienen, zeigt 1 schematisch ein mobiles Fahrzeug 8, das ein Controller Area Network (CAN) 50 mit einem CAN-Bus 15 und mehreren Knoten, d.h. Controllern 10, 20, 30 und 40, umfasst. Der Begriff „Knoten“ bezieht sich auf jede aktive elektronische Einrichtung, die über Signale mit dem CAN-Bus 15 verbunden ist und eine Information über den CAN-Bus 15 senden, empfangen und/oder weiterleiten kann. Jeder der Controller 10, 20, 30 und 40 ist über Signale mit dem CAN-Bus 15 verbunden und elektrisch mit einem Leistungsnetz 60 und einem Massenetz 70 verbunden. Jeder der Controller 10, 20, 30 und 40 umfasst einen elektronischen Controller oder eine andere bordeigene Einrichtung, die ausgestaltet ist, um den Betrieb eines Subsystems des Fahrzeugs 8 zu überwachen oder zu steuern und über den CAN-Bus 15 zu kommunizieren. Bei einer Ausführungsform ist einer der Controller, z.B. Controller 40, ausgestaltet, um das CAN 50 und den CAN-Bus 15 zu überwachen, und er kann hierin als CAN-Controller bezeichnet werden. Der Controller 40 ist über Signale mit einer Kommunikationseinrichtung 42 verbunden, die ausgestaltet ist, um eine digitale Nachricht an eine externe Einrichtung 45 zu übermitteln, wobei eine direkte drahtgebundene Verbindung 43 und/oder eine drahtlose Telematikverbindung 44 eingesetzt werden. Die direkte drahtgebundene Verbindung 43 und die drahtlose Telematikverbindung 44 setzen ein beliebiges geeignetes Kommunikationsprotokoll/beliebige geeignete Kommunikationsprotokolle ein.
  • Die dargestellte Ausführungsform des CAN 50 ist ein nicht einschränkendes Beispiel eines CAN, das bei einer beliebigen mehrerer Systemausgestaltungen eingesetzt werden kann. Jedes CAN wird als eine Netztopologie einsetzend beschrieben, die eine physikalische Anordnung von Leistungs-, Masse- und Kommunikationsverbindungen zwischen den Knoten umfasst, die Controller und andere elektronische Einrichtungen umfassen. Eine Netztopologie, wie beispielsweise ein CAN, bezieht sich auf eine verbindende Anordnung zwischen Netzelementen und umfasst vorzugsweise mehrere Knoten mit gekoppelten oder verteilten Leistungs-, Masse- oder Kommunikationsverbindungen dazwischen. Es werden Topologiediagramme entwickelt, die eine Kommunikationstopologie, eine Leistungstopologie und eine Massetopologie umfassen. Die Netztopologie bezieht sich auf eine Signal-, Leistungs- und Massekonnektivität zwischen den Knoten und anderen Elementen, z.B. Leistungs- und Massequellen, und physikalische oder lineare Distanzen zwischen Knoten, physikalische Kopplungen, Übertragungsraten und/oder Signaltypen sind sekundäre Betrachtungen. Somit kann eine gemeinsame Netztopologie an unterschiedlichen Fahrzeugausgestaltungen zu finden sein, die gemeinsame Funktionen bereitstellen.
  • Der CAN-Bus 15 umfasst mehrere Kommunikationsverbindungen, die eine erste Kommunikationsverbindung 51 zwischen den Controllern 10 und 20, eine zweite Kommunikationsverbindung 53 zwischen den Controllern 20 und 30 und eine dritte Kommunikationsverbindung 55 zwischen den Controllern 30 und 40 umfassen. Das Leistungsnetz 60 umfasst eine Leistungsversorgung 62, z.B. eine Batterie, die elektrisch mit einem ersten Leistungsbus 64 und einem zweiten Leistungsbus 66 verbunden ist, um den Controllern 10, 20, 30 und 40 über Leistungsverbindungen elektrische Leistung bereitzustellen. Wie gezeigt ist die Leistungsversorgung 62 mit dem ersten Leistungsbus 64 und dem zweiten Leistungsbus 66 über Leistungsverbindungen, die in einer seriellen Ausgestaltung angeordnet sind, verbunden, wobei eine Leistungsverbindung 69 den ersten und den zweiten Leistungsbus 64 und 66 verbindet. Der erste Leistungsbus 64 ist mit den Controllern 10 und 20 über Leistungsverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Leistungsverbindung 61 den ersten Leistungsbus 64 und den Controller 10 verbindet und Leistungsverbindung 63 den ersten Leistungsbus 64 mit dem Controller 20 verbindet. Der zweite Leistungsbus 66 ist mit den Controllern 30 und 40 über Leistungsverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Leistungsverbindung 65 den zweiten Leistungsbus 66 und den Controller 30 verbindet und Leistungsverbindung 67 den zweiten Leistungsbus 66 mit dem Controller 40 verbindet. Das Massenetz 70 umfasst eine Fahrzeugmasse 72, die mit einem ersten Massebus 74 und einem zweiten Massebus 76 verbunden ist, um den Controllern 10, 20, 30 und 40 über Masseverbindungen eine elektrische Masse bereitzustellen. Wie gezeigt ist die Fahrzeugmasse 72 über Masseverbindungen, die in einer seriellen Ausgestaltung angeordnet sind, mit dem ersten Massebus 74 und dem zweiten Massebus 76 verbunden, wobei Masseverbindung 79 den ersten und zweiten Massebus 74 und 76 verbindet. Der erste Massebus 74 ist mit den Controllern 10 und 20 über Masseverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Masseverbindung 71 den ersten Massebus 74 und den Controller 10 verbindet und Masseverbindung 73 den ersten Massebus 74 mit dem Controller 20 verbindet. Der zweite Massebus 76 ist mit den Controllern 30 und 40 über Masseverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Masseverbindung 75 den zweiten Massebus 76 und den Controller 30 verbindet und Masseverbindung 77 den zweiten Massebus 76 mit dem Controller 40 verbindet. Andere Topologien für die Verteilung von Kommunikationen, Leistung und Masse für die Controller 10, 20, 30 und 40 und den CAN-Bus 15 können mit einer ähnlichen Auswirkung eingesetzt werden.
  • Die externe Einrichtung 45 kann ein in der Hand gehaltenes Abtastwerkzeug umfassen, das an einer Servicestelle in einer Fahrzeugdiagnose- und -reparaturwerkstatt eingesetzt wird. Die externe Einrichtung 45 kann auch eine entfernt angeordnete Servicewerkstatt umfassen. Die externe Einrichtung 45 ist ausgestaltet, um mit der Kommunikationseinrichtung 42 zu kommunizieren, was das Abfragen des Controllers 40 hinsichtlich Nachrichten umfasst. Die externe Einrichtung 45 umfasst vorzugsweise ein Controllerelement, ein Speicherelement, das eine Netztopologie umfasst, die mit dem CAN 50 in Korrelation gebracht werden kann, und ein analytisches Element, das wie hierin beschrieben arbeitet, um aus der Ferne einen Fehler in dem CAN 50 zu identifizieren.
  • Steuermodul, Modul, Steuerung, Controller, Steuereinheit, Prozessor und ähnliche Begriffe umfassen eines oder verschiedene Kombinationen eines/r oder mehrerer anwendungsspezifischen/r integrierten/r Schaltkreise(s) (ASIC), elektronischen/r Schaltkreise(s), zentralen/r Verarbeitungseinheit(en) (vorzugsweise Mikroprozessor(en)) und einen zugeordneten Speicher (Nur-Lese-Speicher, programmierbarer Nur-Lese-Speicher, Direktzugriffsspeicher, Festplatte etc.), die ein(e) oder mehrere Software- oder Firmwareprogramme oder Routinen ausführen, Schaltkreise(s) einer kombinatorischen Logik, Eingabe/Ausgabe-Schaltkreise(s) und -Einrichtungen, geeigneten Signalkonditionierungs- und -pufferschaltung und andere Komponenten, um die beschriebene Funktionalität bereitzustellen. Software, Firmware, Programme, Anweisungen, Routinen, Code, Algorithmen und ähnliche Begriffe umfassen jegliche Anweisungssätze, die Kalibrierungen und Nachschlagetabellen umfassen. Das Steuermodul weist einen Satz von Steuerroutinen auf, die ausgeführt werden, um die gewünschten Funktionen bereitzustellen. Routinen werden beispielsweise durch eine zentrale Verarbeitungseinheit ausgeführt und dienen dazu, Eingänge von Erfassungseinrichtungen und anderen vernetzten Steuermodulen zu überwachen und Steuer- und Diagnoseroutinen auszuführen, um den Betrieb von Aktoren zu steuern. Routinen können in regelmäßigen Intervallen, beispielsweise alle 100 Mikrosekunden, 3,125, 6,25, 12,5, 25 und 100 Millisekunden, während des fortwährenden Maschinen- und Fahrzeugbetriebs ausgeführt werden. Alternativ können Routinen in Ansprechen auf das Auftreten eines Ereignisses ausgeführt werden.
  • Jeder der Controller 10, 20, 30 und 40 überträgt und empfängt Nachrichten über das CAN 50 über den CAN-Bus 15, wobei Nachrichtenübertragungsraten entweder mit der gleichen oder mit verschiedenen Perioden für verschiedene der Controller erfolgen. Eine CAN-Nachricht weist ein bekanntes, vorbestimmtes Format auf, das bei einer Ausführungsform einen Frame-Start (SOF von start of frame), einen Identifikator (11-Bit-ldentifikator), eine einzelne Fernübertragungsanforderung (RTR von remote transmission request), eine dominante einzelne Identifikatorerweiterung (IDE von identifier extension), ein Reservebit (r0), einen Datenlängencode (DLC von data length code) mit 4 Bit, bis zu 64 Bit Daten (DATA), eine zyklische Redundanzprüfung (CDC von cyclic redundancy check) mit 16 Bit, eine Bestätigung (ACK von acknowledgement) mit 2 Bit, ein Frame-Ende (EOF von end-of-frame) mit 7 Bit und einen Zwischen-Frame-Raum (IFS von interframe space) mit 3 Bit umfasst. Eine CAN-Nachricht kann beschädigt sein, wobei bekannte Störungen Füllstörungen, Formstörungen, ACK-Störungen, Bit-1-Störungen, Bit-0-Störungen und CRC-Störungen umfassen. Die Störungen werden verwendet, um einen Störungswarnungsstatus zu erzeugen, der einen Störung-Aktiv-Status oder einen Störung-Passiv-Status oder einen Bus-Aus-Störungsstatus umfasst. Der Störung-Aktiv-Status, der Störung-Passiv-Status und der Bus-Aus-Störungsstatus werden auf der Grundlage einer zunehmenden Menge an detektierten Busstörungs-Frames, d.h. eines sich erhöhenden Bus-Störungszählwerts, zugeordnet. Bekannte CAN-Busprotokolle umfassen das Bereitstellen einer Netzweitendatenkonsistenz, was zu einer Globalisierung von lokalen Störungen führen kann. Dies ermöglicht einem fehlerhaften, nicht stillstehenden Controller, eine Nachricht an dem CAN-Bus 15 zu beschädigen, die von einem anderen der Controller stammt.
  • Ein Kommunikationsfehler, der zu einer verlorenen Nachricht an dem CAN-Bus führt, kann das Ergebnis eines Fehlers bei einem der Controller, eines Fehlers bei einer der Kommunikationsverbindungen des CAN-Busses, eines Fehlers bei einer der Leistungsverbindungen des Leistungsnetzes und eines Fehlers bei einer der Masseverbindungen des Massenetzes sein. Es können Topologiediagramme entwickelt werden, die eine Kommunikationstopologie, eine Leistungstopologie und eine Massetopologie umfassen. Es wird eine Erreichbarkeitsanalyse für jedes der Topologiediagramme mit entfernter Verbindungsunterbrechung durchgeführt. Eine Ausführungsform einer Erreichbarkeitsanalyse eines Topologiediagramms wird in Bezug auf 2 beschrieben.
  • 2 zeigt eine Netztopologie für ein beispielhaftes CAN 400, die die Controller 402, 404 und 406, einen Überwachungscontroller 408, eine Leistungsversorgung 410, eine Batteriesterneinrichtung 412 und eine Masse 414 umfasst, die jeweils über eine Verbindung wie gezeigt verbunden sind. Der Überwachungscontroller 408 beobachtet Symptome, die verschiedene Fehlersätze angeben, wobei jeder Fehlersatz eine entsprechende Fehlersignatur aufweist, die einen Satz von inaktiven Controllern umfasst. Die Überwachungsfunktion ist als durch Controller 408 ausgeführt gezeigt, wobei jedoch zu verstehen ist, dass jeder beliebige oder alle der Controller 402, 404, 406 und 408 an dem Kommunikationsbus ausgestaltet sein können, um eine Fehlerdiagnose auszuführen, da jede Nachricht an dem CAN-Bus an einem beliebigen der und allen Controllerknoten beobachtet werden kann.
  • Für die Netztopologie wird ein Fehlermodell erzeugt, das mehrere Symptome, die durch einen Überwachungscontroller für jeden mehrerer Fehler beobachtet werden, und einen entsprechenden Fehlersignaturvektor Vfinactive umfasst, der einen Satz von beobachteten zugehörigen inaktiven Controllern umfasst. Ein beispielhaftes Fehlermodell, das der in Bezug auf 2 gezeigten Netztopologie zugehörig ist, umfasst folgendes in Bezug auf Tabelle 1, wobei die Netztopologie für das CAN 400 die Controller 402 [1], 404 [2] und 406 [3], den Überwachungscontroller 408 [0], die Leistungsversorgung 410 [4], die Batteriesterneinrichtung 412 [5] und die Masse 414 [6] umfasst. Das Fehlermodell wird unter Einsatz einer Erreichbarkeitsanalyse der Netztopologie abgeleitet, wobei das Symptom hervorgerufen wird und Kommunikationen überwacht werden, um zu ermitteln, welcher der Controller bei diesem Symptom inaktiv ist. Tabelle 1
    Fehlersatz Symptom Inhalte von Fehlersiqnaturvektor Vf inactive
    f1 Unterbrochene Verbindung [1]-[2] [1]
    Unterbrochene Verbindung [1]-[5]
    Unterbrochene Verbindung [1]-[6]
    [1]-Fehler
    f2 Unterbrochene Verbindung [2]-[4] [2]
    Unterbrochene Verbindung [2]-[6]
    [2]-Fehler
    f3 Unterbrochene Verbindung [3]-[5] [3]
    Unterbrochene Verbindung [3]-[6]
    [3]-Fehler
    f4 Unterbrochene Verbindung [2]-[3] [1], [2]
    f5 Unterbrochene Verbindung [4]-[5] [1], [3]
    f6 Unterbrochene Verbindung [1]-[2] [1], [2], [3]
    CAN-Bus-Kurzschluss
  • Ein erster Fehlersatz f1 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller 402 und Batteriesterneinrichtung 412 oder Controller 402 und Masse 414 oder Controller 402 und Controller 404 und einen Fehler bei Controller 402 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive Controller 402 als inaktiv umfasst. Ein zweiter Fehlersatz f2 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller 404 und Batterie 410 oder Controller 404 und Masse 414 und einen Fehler bei Controller 404 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive Controller 404 als inaktiv umfasst. Ein dritter Fehlersatz f3 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller 406 und Batteriesterneinrichtung 412 oder Controller 406 und Masse 414 und einen Fehler bei Controller 406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive Controller 406 als inaktiv umfasst. Ein vierter Fehlersatz f4 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller 404 und Controller 406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive die Controller 402 und 404 als inaktiv umfasst. Ein fünfter Fehlersatz f5 kann ein Symptom einer unterbrochenen Verbindung zwischen Batterie 410 und Batteriesterneinrichtung 412 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive die Controller 402 und 406 als inaktiv umfasst. Ein sechster Fehlersatz f6 kann ein Symptom einer unterbrochenen Verbindung zwischen Überwachungscontroller 408 und Controller 406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive die Controller 402, 404 und 406 als inaktiv umfasst. Andere Fehlersignaturvektoren Vf inactive können gemäß einer spezifischen Architektur eines CAN-Systems entwickelt werden, wobei eine Erreichbarkeitsanalyse eines Topologiediagramms des CAN eingesetzt wird. Da die Überwachungsfunktion, die eine Fehlerdiagnose umfasst, in einem beliebigen der oder allen Controllern 402, 404, 406 und 408 ausgeführt werden kann, können geeignete Fehlersätze und Symptome entwickelt werden, um Fehlersignaturvektoren Vf inactive zu erreichen, die einen einzelnen verfolgbaren Fehler isolieren.
  • 3 zeigt eine bordeigene CAN-Überwachungsroutine 300, die eine bordeigene Fehlerdetektion und -isolierung ausführt, indem ein Systemmodell erzeugt wird, das VECU umfasst, der einen Satz von Controllern in dem CAN einschließlich eines oder mehrerer Überwachungsknoten darstellt, welcher einen oder mehrere der Controller und/oder einen Überwachungscontroller umfassen kann. Jeder der Controller überträgt einen Satz von Nachrichten, die verschiedene Perioden oder Wiederholungsraten aufweisen können.
  • Die bordeigene CAN-Überwachungsroutine 300 wird ausgeführt, um auf der Grundlage des Überwachens von Kommunikationen, die von den Controllern in dem CAN stammen, Controller-Aktiv-Berichte zu erhalten, wodurch detektiert wird, ob die Controller, die mit dem CAN-Bus verbunden sind, aktiv oder inaktiv sind. Tabelle 2 wird als Legende für die bordeigene CAN-Überwachungsroutine 300 von 3 bereitgestellt, wobei die numerisch bezeichneten Kasten und die entsprechenden Funktionen wie folgt ausgeführt werden. Tabelle 2
    KASTEN KASTENINHALTE
    302 Start
    304 Führe Controller-Aktiv/Inaktiv-Detektion durch
    306 Führe eine Datenfilterung durch, um Rauschen in Controller-Aktiv/Inaktiv-Detektion zu entfernen
    308 Gibt es einen inaktiven Controller/inaktive Controller?
    310 Fault_Num = 0
    312 Inkrementiere Fault_Num
    Fault Num = Fault Num + 1
    314 R_lnactive[Fault_Num] = Satz von inaktiven Controllern
    316 Zeichne Fehlerinformation
    Time_Stamp, Fault_Num, R_lnactive[k],
    k=1,...,Fault_Num, auf
    320 Ende
  • Die CAN-Überwachungsroutine 300 wird während des Fahrzeugbetriebs periodisch, z.B. alle 100 ms, ausgeführt. Beim Start (302) wird der Überwachungscontroller ausgeführt, um zu detektieren, welcher der Controller an dem CAN-Bus aktiv ist, und somit, welcher der Controller an dem CAN-Bus inaktiv ist (304). Diese Aktiv/Inaktiv-Detektion kann jede Form annehmen und umfasst vorzugsweise eine Form des Überwachens und des Detektierens, ob Kommunikationen, die von den Controllern stammen, innerhalb einer vorbestimmten Zeitperiode stattgefunden haben, die dem Betrieb des jeweiligen Controllers zugehörig ist, und des Identifizierens jener Controller, die keine Nachricht erzeugten, als inaktiv. Die Aktiv/Inaktiv-Detektionsergebnisse werden einer Datenfilterung unterzogen, um Datenrauschen zu entfernen (306), und die Ergebnisse werden ausgewertet, um zu ermitteln, ob irgendeiner der Controller inaktiv ist (308). Wenn kein Controller inaktiv ist (308)(0) wird die Variable Fault_Num gleich Null gesetzt (310), und diese Iteration der Routine 300 endet (320). Die Variable Fault_Num wird verwendet, um die Anzahl an Fehlern anzugeben, die aufgetreten sind, und sie ist anfänglich Null. Wenn irgendeiner der Controller inaktiv ist (308)(1), wird die Variable Fault_Num inkrementiert (312). Für jeden durch die Variable Fault_Num indizierten Fehler wird der Satz von inaktiven Controllern nach dem Datenfiltern durch R_Inactive[Fault_Num] gespeichert und die aufgezeichneten inaktiven Controller R_lnactive[Fault_Num] werden gleich dem Satz von inaktiven Controllern gesetzt (314).
  • Es wird eine zugehörige Fehlerinformation erfasst, die einen Zeitstempel, eine Fehleranzahl und den Satz von inaktiven Controllern für jede der Fehlerzahlen R_Inactive[k], k = 1, ..., Fault_Num, umfasst (316). Somit umfasst jede Fehleraufzeichnung: (Time_stamp, Fault_Num, R_Inactive[k], k = 1, ..., Fault_Num), wobei Fault_Num die Gesamtanzahl an bei dieser Aufzeichnung aufgetretenen Fehlern ist und R_Inactive[k] der Satz von inaktiven Controllern für jeden Fehler, indiziert durch k, ist. Diese Iteration der Routine 300 endet (320).
  • 4 zeigt eine externe Fehlerisolierungsroutine 200 zum Ermitteln von Fehlerkandidaten, d.h. unterbrochene Verbindungen, Kurzschlüsse oder fehlerhafte Controller, die Fehlersignaturvektoren Vfinactive einsetzt, wofür Beispiele in Bezug auf 2 beschrieben sind. Topologiediagramme wie z.B. in Bezug auf 2 gezeigt umfassen die Topologien Gbus, Gbat und Ggnd des Kommunikationsbusses, des Leistungsbusses bzw. des Massebusses. Ein Fehlersatz F kann jeden Controllerknotenfehler, jeden Busverbindungsunterbrechungsfehler, jeden Leistungsverbindungsunterbrechungsfehler, jeden Masseverbindungsunterbrechungsfehler und andere Fehler für die Topologiediagramme umfassen. Eine Vorbetriebsanwendung erzeugt einen Fehlersignaturvektor Vf inactive, der aus einem Satz von inaktiven Controllern für jeden Fehler f in dem Fehlersatz F besteht, wie es hierin vorstehend z.B. in Bezug auf 2 und Tabelle 1 beschrieben ist. Der Fehlersignaturvektor Vfinactive wird durch die externe Fehlerisolierungsroutine 200 eingesetzt, um einen Fehler zu isolieren.
  • Tabelle 3 wird als Legende für die externe Fehlerisolierungsroutine 200 von 4 bereitgestellt, wobei die numerisch bezeichneten Kasten und die entsprechenden Funktionen wie folgt ausgeführt werden. Tabelle 3
    KASTEN KASTENINHALTE
    202 Initialisiere
    204 Erhalte Fehlerinformation von bordeigenem Controller Time_Stamp, Fault_Num, R_Inactive[k],
    k=1,...,Fault. Num
    206 k=1
    208 FC={S ⊆ F: |S|≥k und ist das kleinste, so dass R_Inactive[k] = (Uf ∈ s Vf inactive),
    und wenn k>1 dann V R ∈ Pre_FC, R ⊆ S}
    210 Pre FC = FC
    212 k < Fault_Num?
    214 k = k+1
    216 Gib FC als den Satz von Fehlerkandidaten aus
    218 Ende
  • Die externe Fehlerisolierungsroutine 200 wird in Ansprechen auf eine Abfragenachricht ausgeführt, die von einer externen Serviceeinrichtung stammt, wobei eine direkte drahtgebundene Verbindung und/oder eine drahtlose Telematikverbindung eingesetzt werden, wovon eine Ausführungsform in Bezug auf 1 beschrieben ist. Die externe Serviceeinrichtung umfasst Daten in Form einer Systemtopologie, die den Fehlersignaturvektor Vf inaktive für jeden Fehler f umfassen, wobei der Satz von zugehörigen inaktiven Controllern angegeben wird.
  • Während jeder Ausführung der externen Fehlerisolierungsroutine 200 werden Terme initialisiert (202), was umfasst, dass sichergestellt wird, dass ein Fehlerkandidatenregister FC und ein Fehlerkandidatenregister von einer vorherigen Iteration pre_FC leer sind. Eine Fehlerinformation in Form von Fehleraufzeichnungen wird von dem bordeigenen Controller abgerufen (204). Jede Fehleraufzeichnung umfasst: Time_stamp, Fault_Num, R_lnactive[k], k = 1, ..., Fault_Num), wobei Fault_Num die Gesamtanzahl an Fehlern ist, die bei dieser Aufzeichnung auftreten, und R_lnactive[k] der Satz von inaktiven Controllern für jeden Fehler, indiziert durch k, ist. Der Index k wird mit einem Wert von „1“ initialisiert (206). Die Routine ermittelt für jeden Fehlerindex k einen Fehlerkandidaten FC als Teilmenge S von F, so dass S der kleinste (gemessen an der Größe) aus den Sätzen mit
    |S| ≥k ist, der die folgenden Beziehungen erfüllt. R_Inactive [ k ] = ( U f ∈ S V f inactive ) ,
    Figure DE102014112095B4_0001
     und wenn k > 1,  dann  ∀  R ∈ Pre_FC , R ⊆ S
    Figure DE102014112095B4_0002
  • Der Fehlerkandidat von der vorherigen Iteration pre_FC wird in den aktuellen FC-Satz einbezogen, so dass jeder Kandidat des vorherigen Fehlers ein Teil des aktuellen Fehlerkandidatensatzes FC wird (210), und wenn der Index k kleiner als die Menge an Fehlern Fault_Num ist (212)(1), wird der Index k inkrementiert und wird der nächste Satz von Fehlerkandidaten ausgewertet (208). Wenn alle Fehler ausgewertet wurden (212)(0), wird der Fehlerkandidatensatz FC als Satz von Fehlerkandidaten ausgegeben (216), und die Ausführung der externen Fehlerisolierungsroutine 200 endet (218).
  • CAN-Systeme werden eingesetzt, um Signalkommunikationen zwischen Controllern in einem System, z.B. einem Fahrzeug, zu bewirken. Der hierin beschriebene Fehlerisolierungsprozess ermöglicht das Auffinden und die Isolierung eines einzelnen Fehlers, mehrerer Fehler und intermittierender Fehler in den CAN-Systemen einschließlich Fehlern in einem Kommunikationsbus, einer Leistungsversorgung und einer elektrischen Masse, wobei die Systemtopologie eingesetzt wird, die den Fehlersignaturvektor Vf inactive für jeden Fehler f umfasst, wobei der Satz von zugehörigen inaktiven Controllern angegeben wird.
  • Bei einer Ausführungsform können verschiedene der Controller als Überwachungscontroller eingesetzt werden, um eine Ausführungsform der bordeigenen CAN-Überwachungsroutine 300 auszuführen, wobei Ergebnisse, die inaktive Knoten identifizieren, an eine Ausführungsform der externen Fehlerisolierungsroutine 200 übermittelt werden, um Fehlerkandidaten zu identifizieren, indem Netztopologien eingesetzt werden, die spezifisch für die ausgewählten Überwachungscontroller sind und unterschiedliche Fehlersignaturen und Symptome für die unterschiedlichen Überwachungscontroller aufweisen. Solch eine Anordnung ermöglicht dem System, ferner den Ort eines CAN-Fehlers zu isolieren, indem Ergebnisse von den Ausführungen der externen Fehlerisolierungsroutine 200 verglichen werden.

Claims (9)

  1. Verfahren zum Überwachen eines Controller Area Network (CAN) an einem mobilen System, das mehrere CAN-Elemente umfasst, die einen Kommunikationsbus und mehrere Knoten umfassen, umfassend, dass: inaktive Knoten des CAN detektiert werden; ein externer Controller eingesetzt wird, um einen Kandidatenfehler in dem CAN auf der Grundlage der inaktiven Knoten des CAN und einer Netztopologie für das CAN zu identifizieren; und ein Fehler in dem CAN auf der Grundlage des Kandidatenfehlers isoliert wird; dadurch gekennzeichnet, dass das Einsetzen des externen Controllers zum Identifizieren eines Kandidatenfehlers in dem CAN umfasst, dass: die inaktiven Knoten des CAN mit mehreren Fehlersignaturvektoren, die der Netztopologie für das CAN zugehörig sind, verglichen werden; einer der Fehlersignaturvektoren, die dem inaktiven Knoten des CAN entsprechen, identifiziert wird; ein Fehlersymptom ermittelt wird, das dem identifizierten Fehlersignaturvektor zugehörig ist; und der Kandidatenfehler in dem CAN auf der Grundlage des Fehlersymptoms identifiziert wird.
  2. Verfahren nach Anspruch 1, wobei das Ermitteln des dem identifizierten Fehlersignaturvektor zugehörigen Fehlersymptoms umfasst, dass eine Erreichbarkeitsanalyse der Netztopologie des CAN eingesetzt wird, wobei Kommunikationen überwacht werden, um zu ermitteln, welcher der Knoten für das Fehlersymptom inaktiv ist.
  3. Verfahren nach Anspruch 1, wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Verbindung zwischen einer Leistungsversorgung und einem Knoten umfasst.
  4. Verfahren nach Anspruch 1, wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Verbindung zwischen einer elektrischen Masse und einem Knoten umfasst.
  5. Verfahren nach Anspruch 1, wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Kommunikationsverbindung zwischen einem ersten Knoten und einem zweiten Knoten umfasst.
  6. Verfahren nach Anspruch 1, wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom einen Fehler in einem Knoten umfasst.
  7. Verfahren nach Anspruch 1, wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom einen Kurzschluss bei einer Kommunikationsverbindung zwischen einem ersten Knoten und einem zweiten Knoten umfasst.
  8. Verfahren nach Anspruch 1, wobei das Detektieren von inaktiven Knoten des CAN umfasst, dass ein bordeigener Controller eingesetzt wird, um Kommunikationen von den Knoten des CAN zu überwachen, und jeder Knoten des CAN, dem es nicht gelingt, innerhalb einer vorbestimmten Zeitperiode eine Nachricht an dem CAN zu erzeugen, als inaktiv identifiziert wird.
  9. Verfahren nach Anspruch 1, das ferner umfasst, dass: eine bordeigene Überwachungsroutine eingesetzt wird, um die inaktiven Knoten des CAN zu detektieren und einen entsprechenden Zeitstempel zu erfassen; und in Ansprechen auf eine Abfrage die inaktiven Knoten des CAN und der entsprechende Zeitstempel an den externen Controller übermittelt werden.
DE102014112095.7A 2013-09-16 2014-08-25 Verfahren zum Überwachen eines Fehlers in einem Controller Area Network Active DE102014112095B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/027,549 2013-09-16
US14/027,549 US9110951B2 (en) 2013-09-16 2013-09-16 Method and apparatus for isolating a fault in a controller area network

Publications (2)

Publication Number Publication Date
DE102014112095A1 DE102014112095A1 (de) 2015-03-19
DE102014112095B4 true DE102014112095B4 (de) 2021-06-02

Family

ID=52580078

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014112095.7A Active DE102014112095B4 (de) 2013-09-16 2014-08-25 Verfahren zum Überwachen eines Fehlers in einem Controller Area Network

Country Status (3)

Country Link
US (1) US9110951B2 (de)
CN (1) CN104468175B (de)
DE (1) DE102014112095B4 (de)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9600372B2 (en) * 2012-09-05 2017-03-21 GM Global Technology Operations LLC Approach for controller area network bus off handling
US9524222B2 (en) * 2013-09-16 2016-12-20 GM Global Technology Operations LLC Method and apparatus for fault detection in a controller area network
US9110951B2 (en) * 2013-09-16 2015-08-18 GM Global Technology Operations LLC Method and apparatus for isolating a fault in a controller area network
BR112015008318A2 (pt) 2013-09-23 2017-07-04 Farmobile Llc dispositivo de retransmissão, e, sistemas de troca de dados de agricultura e de servidor
US9354965B2 (en) * 2013-10-18 2016-05-31 GM Global Technology Operations LLC Method and apparatus for isolating a fault in a controller area network
US9727431B2 (en) * 2013-12-30 2017-08-08 Sital Ltd. Communication monitoring system
US9678847B2 (en) * 2014-05-27 2017-06-13 GM Global Technology Operations LLC Method and apparatus for short fault detection in a controller area network
US10800363B2 (en) 2017-09-18 2020-10-13 GM Global Technology Operations LLC Analog-to-digital fault detection, isolation, and mitigation for a low-voltage communications network
CN108072806B (zh) * 2017-11-13 2020-12-15 北京全路通信信号研究设计院集团有限公司 一种轨道电路故障诊断系统及诊断方法
US11516046B2 (en) 2020-01-14 2022-11-29 GM Global Technology Operations LLC Controller area network fault detection and recovery
CN112193072B (zh) * 2020-09-29 2022-06-21 奇瑞新能源汽车股份有限公司 一种电动汽车can总线错误帧的排查方法
CN112463428B (zh) * 2020-11-30 2024-03-26 深圳市道通科技股份有限公司 汽车总线故障诊断方法、装置及计算设备
CN113114518B (zh) * 2021-05-28 2023-05-23 一汽奔腾轿车有限公司 一种基于总线物理拓扑的通信类线束故障排查方法
CN113942486B (zh) * 2021-10-22 2022-12-20 交控科技股份有限公司 一种制动故障处理方法及信号系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008002738A1 (de) * 2008-06-27 2010-01-07 Airbus Deutschland Gmbh Verfahren zum Erkennen eines fehlerhaften Knotens

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040004951A1 (en) * 2002-07-05 2004-01-08 Interdigital Technology Corporation Method for performing wireless switching
US7812617B2 (en) 2006-07-07 2010-10-12 Sital Technology & Hw Design 1997 Ltd. System and method for detecting and locating faults in electronic communication bus systems
US8213321B2 (en) 2007-02-01 2012-07-03 Deere & Company Controller area network condition monitoring and bus health on in-vehicle communications networks
JP4582192B2 (ja) * 2008-05-20 2010-11-17 トヨタ自動車株式会社 車両故障解析システム、車両故障解析装置、車両故障解析方法
CN201281659Y (zh) * 2008-10-08 2009-07-29 湖北三江航天万山特种车辆有限公司 一种汽车底盘故障识别及诊断系统
CN101764657A (zh) * 2008-12-26 2010-06-30 长春轨道客车股份有限公司 城市轨道客车上新闻实时传输方法
US8831821B2 (en) 2010-12-17 2014-09-09 GM Global Technology Operations LLC Controller area network message transmission disable testing systems and methods
US9110951B2 (en) * 2013-09-16 2015-08-18 GM Global Technology Operations LLC Method and apparatus for isolating a fault in a controller area network
US9524222B2 (en) * 2013-09-16 2016-12-20 GM Global Technology Operations LLC Method and apparatus for fault detection in a controller area network

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008002738A1 (de) * 2008-06-27 2010-01-07 Airbus Deutschland Gmbh Verfahren zum Erkennen eines fehlerhaften Knotens

Also Published As

Publication number Publication date
CN104468175B (zh) 2019-01-22
US20150082089A1 (en) 2015-03-19
CN104468175A (zh) 2015-03-25
DE102014112095A1 (de) 2015-03-19
US9110951B2 (en) 2015-08-18

Similar Documents

Publication Publication Date Title
DE102014112095B4 (de) Verfahren zum Überwachen eines Fehlers in einem Controller Area Network
DE102015108342B4 (de) Leitungsunterbrechungsfehlerdetektion und -diagnose in einem controller area network
DE102015108315B4 (de) Kurzschlussfehlerdetektion in einem controller area network
DE112010001370B4 (de) Signalübertragungsvorrichtung für einen Aufzug
DE102015108333B4 (de) Kurzschlussfehlerisolierung in einem controller area network
EP2301200B1 (de) Verfahren zum erkennen eines fehlerhaften knotens
WO2015074938A1 (de) Fahrzeug mit einem ethernet-bussystem und verfahren zum betreiben eines solchen bussystems
DE102016107923B4 (de) Detektion eines ECU-Erdungsfehlers mit Spannungsmessungen am CAN-Bus
US9354965B2 (en) Method and apparatus for isolating a fault in a controller area network
DE102016124352A1 (de) Kommunikationssystem und ein in dem Kommunikationssystem ausgeführtes Informationssammelverfahren
DE102011083254A1 (de) Verfahren und Vorrichtung zum Koppeln eines ersten Sensors mit zumindest einem zweiten Sensor
DE112012003420B4 (de) Fahrzeugsteuerungsvorrichtung und Fahrzeugsteuerungssystem
DE112015005253T5 (de) Controller Area Network (CAN)-Kommunikationssystem und Aufzeichnungsvorrichtung für Fehlerinformationen
EP2132638B1 (de) Vorrichtung zum anschluss eines externen gerätes an einen seriellen flexray-datenbus
DE102020121542A1 (de) Kommunikationseinrichtung, Kommunikationssystem und Protokollumschaltverfahren
DE102013209953A1 (de) Verfahren und Systeme für das Überwachen eines Fahrzeugs bezüglich Fehlern
DE102014114783B4 (de) Verfahren zum überwachen eines controller area network
DE102014112103B4 (de) Verfahren zum Isolieren eines Fehlers in einem Controller Area Network
DE102014112102B4 (de) Verfahren zum Überwachen eines Controller Area Network zur Fehlerdetektion
DE102013204891B4 (de) Verfahren zur Rekonstruktion von Messdaten
DE102020209171B4 (de) Verfahren und System zum Überwachen eines drahtlosen Kommunikationsnetzwerkes
DE102016217127A1 (de) Betriebsverfahren eines Kommunikationsknotens in einem Netzwerk
DE102005031724B4 (de) Verfahren und Vorrichtung zur Diagnose von elektronischen Systemen eines Kraftfahrzeugs
EP4187858A1 (de) Eine sekundärsteuereinheit für ein fahrzeug mit einer primärsteuereinheit und einem datenübertragungsweg
DE10243763B4 (de) Verfahren zur Erfassung und Auswertung von Busfehlern

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: H04L0012260000

Ipc: H04L0043000000

R020 Patent grant now final