DE102014112095B4 - Verfahren zum Überwachen eines Fehlers in einem Controller Area Network - Google Patents
Verfahren zum Überwachen eines Fehlers in einem Controller Area Network Download PDFInfo
- 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
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 22
- 238000000034 method Methods 0.000 title claims abstract description 14
- 238000004891 communication Methods 0.000 claims abstract description 33
- 239000013598 vector Substances 0.000 claims abstract description 28
- 208000024891 symptom Diseases 0.000 claims abstract description 24
- 230000004044 response Effects 0.000 claims description 4
- 238000002955 isolation Methods 0.000 description 12
- 230000000875 corresponding effect Effects 0.000 description 10
- 238000001514 detection method Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 6
- 230000005540 biological transmission Effects 0.000 description 5
- 230000007547 defect Effects 0.000 description 3
- 125000004122 cyclic group Chemical group 0.000 description 2
- 238000003745 diagnosis Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000001914 filtration Methods 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 1
- 230000003750 conditioning effect Effects 0.000 description 1
- 230000002596 correlated effect Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000000763 evoking effect Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
- 230000001052 transient effect Effects 0.000 description 1
Images
Classifications
-
- 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
-
- 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
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computing Systems (AREA)
- Mathematical Physics (AREA)
- Computer Hardware Design (AREA)
- Environmental & Geological Engineering (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Small-Scale Networks (AREA)
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.
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 Fahrzeug8 , das ein Controller Area Network (CAN)50 mit einem CAN-Bus15 und mehreren Knoten, d.h. Controllern10 ,20 ,30 und40 , umfasst. Der Begriff „Knoten“ bezieht sich auf jede aktive elektronische Einrichtung, die über Signale mit dem CAN-Bus15 verbunden ist und eine Information über den CAN-Bus15 senden, empfangen und/oder weiterleiten kann. Jeder der Controller10 ,20 ,30 und40 ist über Signale mit dem CAN-Bus15 verbunden und elektrisch mit einem Leistungsnetz60 und einem Massenetz70 verbunden. Jeder der Controller10 ,20 ,30 und40 umfasst einen elektronischen Controller oder eine andere bordeigene Einrichtung, die ausgestaltet ist, um den Betrieb eines Subsystems des Fahrzeugs8 zu überwachen oder zu steuern und über den CAN-Bus15 zu kommunizieren. Bei einer Ausführungsform ist einer der Controller, z.B. Controller40 , ausgestaltet, um das CAN50 und den CAN-Bus15 zu überwachen, und er kann hierin als CAN-Controller bezeichnet werden. Der Controller40 ist über Signale mit einer Kommunikationseinrichtung42 verbunden, die ausgestaltet ist, um eine digitale Nachricht an eine externe Einrichtung45 zu übermitteln, wobei eine direkte drahtgebundene Verbindung43 und/oder eine drahtlose Telematikverbindung44 eingesetzt werden. Die direkte drahtgebundene Verbindung43 und die drahtlose Telematikverbindung44 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 Kommunikationsverbindung51 zwischen den Controllern10 und20 , eine zweite Kommunikationsverbindung53 zwischen den Controllern20 und30 und eine dritte Kommunikationsverbindung55 zwischen den Controllern30 und40 umfassen. Das Leistungsnetz60 umfasst eine Leistungsversorgung62 , z.B. eine Batterie, die elektrisch mit einem ersten Leistungsbus64 und einem zweiten Leistungsbus66 verbunden ist, um den Controllern10 ,20 ,30 und40 über Leistungsverbindungen elektrische Leistung bereitzustellen. Wie gezeigt ist die Leistungsversorgung62 mit dem ersten Leistungsbus64 und dem zweiten Leistungsbus66 über Leistungsverbindungen, die in einer seriellen Ausgestaltung angeordnet sind, verbunden, wobei eine Leistungsverbindung69 den ersten und den zweiten Leistungsbus64 und66 verbindet. Der erste Leistungsbus64 ist mit den Controllern10 und20 über Leistungsverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Leistungsverbindung61 den ersten Leistungsbus64 und den Controller10 verbindet und Leistungsverbindung63 den ersten Leistungsbus64 mit dem Controller20 verbindet. Der zweite Leistungsbus66 ist mit den Controllern30 und40 über Leistungsverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Leistungsverbindung65 den zweiten Leistungsbus66 und den Controller30 verbindet und Leistungsverbindung67 den zweiten Leistungsbus66 mit dem Controller40 verbindet. Das Massenetz70 umfasst eine Fahrzeugmasse72 , die mit einem ersten Massebus74 und einem zweiten Massebus76 verbunden ist, um den Controllern10 ,20 ,30 und40 über Masseverbindungen eine elektrische Masse bereitzustellen. Wie gezeigt ist die Fahrzeugmasse72 über Masseverbindungen, die in einer seriellen Ausgestaltung angeordnet sind, mit dem ersten Massebus74 und dem zweiten Massebus76 verbunden, wobei Masseverbindung79 den ersten und zweiten Massebus74 und76 verbindet. Der erste Massebus74 ist mit den Controllern10 und20 über Masseverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Masseverbindung71 den ersten Massebus74 und den Controller10 verbindet und Masseverbindung73 den ersten Massebus74 mit dem Controller20 verbindet. Der zweite Massebus76 ist mit den Controllern30 und40 über Masseverbindungen verbunden, die in einer Sternkonfiguration angeordnet sind, wobei Masseverbindung75 den zweiten Massebus76 und den Controller30 verbindet und Masseverbindung77 den zweiten Massebus76 mit dem Controller40 verbindet. Andere Topologien für die Verteilung von Kommunikationen, Leistung und Masse für die Controller10 ,20 ,30 und40 und den CAN-Bus15 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 Einrichtung45 kann auch eine entfernt angeordnete Servicewerkstatt umfassen. Die externe Einrichtung45 ist ausgestaltet, um mit der Kommunikationseinrichtung42 zu kommunizieren, was das Abfragen des Controllers40 hinsichtlich Nachrichten umfasst. Die externe Einrichtung45 umfasst vorzugsweise ein Controllerelement, ein Speicherelement, das eine Netztopologie umfasst, die mit dem CAN50 in Korrelation gebracht werden kann, und ein analytisches Element, das wie hierin beschrieben arbeitet, um aus der Ferne einen Fehler in dem CAN50 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 und40 überträgt und empfängt Nachrichten über das CAN50 über den CAN-Bus15 , 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-Bus15 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 CAN400 , die die Controller402 ,404 und406 , einen Überwachungscontroller408 , eine Leistungsversorgung410 , eine Batteriesterneinrichtung412 und eine Masse414 umfasst, die jeweils über eine Verbindung wie gezeigt verbunden sind. Der Überwachungscontroller408 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 Controller408 ausgeführt gezeigt, wobei jedoch zu verstehen ist, dass jeder beliebige oder alle der Controller402 ,404 ,406 und408 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 CAN400 die Controller402 [1], 404 [2] und 406 [3], den Überwachungscontroller408 [0], die Leistungsversorgung410 [4], die Batteriesterneinrichtung412 [5] und die Masse414 [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 1Fehlersatz 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 Batteriesterneinrichtung412 oder Controller402 und Masse414 oder Controller402 und Controller404 und einen Fehler bei Controller402 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive Controller402 als inaktiv umfasst. Ein zweiter Fehlersatz f2 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller404 und Batterie410 oder Controller404 und Masse414 und einen Fehler bei Controller404 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive Controller404 als inaktiv umfasst. Ein dritter Fehlersatz f3 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller406 und Batteriesterneinrichtung412 oder Controller406 und Masse414 und einen Fehler bei Controller406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive Controller406 als inaktiv umfasst. Ein vierter Fehlersatz f4 kann ein Symptom einer unterbrochenen Verbindung zwischen Controller404 und Controller406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vfinactive die Controller402 und404 als inaktiv umfasst. Ein fünfter Fehlersatz f5 kann ein Symptom einer unterbrochenen Verbindung zwischen Batterie410 und Batteriesterneinrichtung412 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive die Controller402 und406 als inaktiv umfasst. Ein sechster Fehlersatz f6 kann ein Symptom einer unterbrochenen Verbindung zwischen Überwachungscontroller408 und Controller406 umfassen, wobei ein entsprechender Fehlersignaturvektor Vf inactive die Controller402 ,404 und406 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 Controllern402 ,404 ,406 und408 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-Überwachungsroutine300 , 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-Überwachungsroutine300 von3 bereitgestellt, wobei die numerisch bezeichneten Kasten und die entsprechenden Funktionen wie folgt ausgeführt werden. Tabelle 2KASTEN 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 Routine300 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 Fehlerisolierungsroutine200 zum Ermitteln von Fehlerkandidaten, d.h. unterbrochene Verbindungen, Kurzschlüsse oder fehlerhafte Controller, die Fehlersignaturvektoren Vfinactive einsetzt, wofür Beispiele in Bezug auf2 beschrieben sind. Topologiediagramme wie z.B. in Bezug auf2 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 auf2 und Tabelle 1 beschrieben ist. Der Fehlersignaturvektor Vfinactive wird durch die externe Fehlerisolierungsroutine200 eingesetzt, um einen Fehler zu isolieren. - Tabelle 3 wird als Legende für die externe Fehlerisolierungsroutine
200 von4 bereitgestellt, wobei die numerisch bezeichneten Kasten und die entsprechenden Funktionen wie folgt ausgeführt werden. Tabelle 3KASTEN 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 auf1 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. - 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 Fehlerisolierungsroutine200 ü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 Fehlerisolierungsroutine200 verglichen werden.
Claims (9)
- 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.
- 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. - Verfahren nach
Anspruch 1 , wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Verbindung zwischen einer Leistungsversorgung und einem Knoten umfasst. - Verfahren nach
Anspruch 1 , wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Verbindung zwischen einer elektrischen Masse und einem Knoten umfasst. - Verfahren nach
Anspruch 1 , wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom eine unterbrochene Kommunikationsverbindung zwischen einem ersten Knoten und einem zweiten Knoten umfasst. - Verfahren nach
Anspruch 1 , wobei ein dem identifizierten Fehlersignaturvektor zugehöriges Fehlersymptom einen Fehler in einem Knoten umfasst. - 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. - 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. - 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.
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)
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 |
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 |
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)
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)
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 |
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 |
-
2013
- 2013-09-16 US US14/027,549 patent/US9110951B2/en active Active
-
2014
- 2014-08-25 DE DE102014112095.7A patent/DE102014112095B4/de active Active
- 2014-09-16 CN CN201410470400.9A patent/CN104468175B/zh active Active
Patent Citations (1)
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 |
---|---|
CN104468175A (zh) | 2015-03-25 |
US9110951B2 (en) | 2015-08-18 |
US20150082089A1 (en) | 2015-03-19 |
CN104468175B (zh) | 2019-01-22 |
DE102014112095A1 (de) | 2015-03-19 |
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 | |
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 | |
DE102013205390A1 (de) | Datenausgabevorrichtung für ein fahrzeug | |
DE112012003420B4 (de) | Fahrzeugsteuerungsvorrichtung und Fahrzeugsteuerungssystem | |
DE102011083254A1 (de) | Verfahren und Vorrichtung zum Koppeln eines ersten Sensors mit zumindest einem zweiten Sensor | |
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 | |
DE102013209953A1 (de) | Verfahren und Systeme für das Überwachen eines Fahrzeugs bezüglich Fehlern | |
DE102020121542A1 (de) | Kommunikationseinrichtung, Kommunikationssystem und Protokollumschaltverfahren | |
DE102020132573A1 (de) | Erkennung und behebung von fehlern im controller area network | |
DE69015967T3 (de) | Passiver netzwerkmonitor und entsprechendes überwachungsverfahren. | |
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 | |
EP4187858A1 (de) | Eine sekundärsteuereinheit für ein fahrzeug mit einer primärsteuereinheit und einem datenübertragungsweg |
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 |