DE102015207657B4 - Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul - Google Patents

Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul Download PDF

Info

Publication number
DE102015207657B4
DE102015207657B4 DE102015207657.1A DE102015207657A DE102015207657B4 DE 102015207657 B4 DE102015207657 B4 DE 102015207657B4 DE 102015207657 A DE102015207657 A DE 102015207657A DE 102015207657 B4 DE102015207657 B4 DE 102015207657B4
Authority
DE
Germany
Prior art keywords
radio transceiver
mobile device
communicate
diagnostic
transceiver
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
DE102015207657.1A
Other languages
English (en)
Other versions
DE102015207657A1 (de
Inventor
Hadi Elzein
Jeffrey Raymond Ostrowski
Doron M. Elliott
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.)
Ford Global Technologies LLC
Original Assignee
Ford Global Technologies 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 Ford Global Technologies LLC filed Critical Ford Global Technologies LLC
Publication of DE102015207657A1 publication Critical patent/DE102015207657A1/de
Application granted granted Critical
Publication of DE102015207657B4 publication Critical patent/DE102015207657B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/008—Registering or indicating the working of vehicles communicating information to a remotely located station
    • 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/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
    • G06F11/0748—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 remote unit communicating with a single-box computer node experiencing an error/fault
    • 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/0766—Error or fault reporting or storing
    • 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/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • 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/0766—Error or fault reporting or storing
    • G06F11/0787—Storage of error reports, e.g. persistent data storage, storage using memory protection
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0808—Diagnosing performance data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C5/00—Registering or indicating the working of vehicles
    • G07C5/08—Registering or indicating performance data other than driving, working, idle, or waiting time, with or without registering driving, working, idle or waiting time
    • G07C5/0841—Registering performance data
    • G07C5/085—Registering performance data using electronic data carriers
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • 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/08—Configuration management of networks or network elements
    • H04L41/085—Retrieval of network configuration; Tracking network configuration history
    • H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
    • 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/08—Configuration management of networks or network elements
    • H04L41/0866—Checking the configuration
    • H04L41/0873—Checking configuration conflicts between network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Biomedical Technology (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephone Function (AREA)
  • Telephonic Communication Services (AREA)

Abstract

Fahrzeugcomputersystem (VCS), das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, umfassend:einen Funktransceiver, der dafür ausgelegt ist, mit der mobilen Einrichtung zu kommunizieren;einen mit dem Funktransceiver und einem Speicherelement kommunizierenden Prozessor, wobei der Prozessor ausgelegt ist, um:1.) am Funktransceiver erfolgende Aktivität zu überwachen;2.) eine Nachricht vom Funktransceiver zu empfangen, die Informationen in Bezug auf einen oder mehrere Softwarezustände des Funktransceivers enthält;3.) zu bestimmen, dass am Funktransceiver ein Fehler vorgekommen ist;4.) die Informationen in Bezug auf den einen oder die mehreren Softwarezustände des Funktransceivers im Speicherelement zu speichern; und5.) die Informationen in Bezug auf den einen oder die mehreren Softwarezustände zu senden, dadurch gekennzeichnet, dass der Prozessor weiter dafür ausgelegt ist, am Funktransceiver erfolgende Aktivität basierend darauf zu überwachen, dass zur Diagnoseüberwachung eine Eingabe zum Aktivieren eines Diagnosemodus empfangen wird, wobei der Diagnosemodus die Aktivität definiert, die am Funktransceiver überwacht wird, wobei der die Aktivität definierende Diagnosemodus einen Fehlerbehebungsmodus enthält, und die Diagnoseüberwachung Pufferzustände anfordert.

Description

  • Die Ausführungsbeispiele betreffen allgemein ein Gerät und ein Verfahren für Software-Implementierung zwischen einem Fahrzeug und einer mobilen Einrichtung.
  • Das Die Patentschrift US 8036788 B2 offenbart ein System und ein Verfahren zum Überwachen des Zustands eines Fahrzeugs, die eine Kommunikationseinheit, die derart angeordnet ist, dass sie eine Schnittstelle zu einem drahtlosen Kommunikationsnetz hat, mindestens einen Sensor zum Überwachen mindestens einer Komponente oder eines Subsystems des Fahrzeugs, der an die Kommunikationseinheit gekoppelt ist, und eine entfernte Stelle, die mit dem drahtlosen Kommunikationsnetz verbunden und derart angeordnet ist, dass sie Diagnose- oder Prognosenachrichten vom Fahrzeug mit der davon initiierten Übertragung empfängt, enthalten. Ein Diagnosemodul kann für den Sensor/die Sensoren bereitgestellt, darin enthalten oder daran gekoppelt sein und weist die Kommunikationseinheit nach dem Bestimmen eines tatsächlichen und/oder potenziellen Versagens einer Komponente oder eines Subsystems dazu an, eine Nachricht zur entfernten Stelle zu übertragen.
  • Die US-Patentveröffentlichung US 2010/0256861 A1 offenbart ein System zum Überwachen des Integritätsstatus eines Fahrzeugs. Das System umfasst ein Fahrzeugüberwachungs-Computersystem, das dafür ausgelegt ist, Informationen zu empfangen, die ein Mobiltelefon mit einem Fahrzeug assoziieren, ein Fahrzeug betreffende Diagnostikinformationen zu empfangen, die Fahrzeugzustände enthalten, einen Schweregradstatus für die Fahrzeugzustände auf der Basis von vordefinierten Schweregradstatuswerten automatisch zu bestimmen und, wenn der Schweregradstatus für irgendwelche der Fahrzeugzustände einen vordefinierten Schweregradstatuswert überschreitet, eine Textnachricht automatisch zu dem Mobiltelefon zu übertragen. Ein anderer Aspekt enthält ein System zum Detektieren und Überwachen des Integritätsstatus eines Fahrzeugs. Das System umfasst ein Fahrzeugüberwachungs-Computersystem und ein Fahrzeugcomputersystem, das dafür ausgelegt ist, drahtlos mit einem in einem Fahrzeug oder seiner Umgebung befindlichen Mobiltelefon zu kommunizieren, um zur Kommunikation mit dem Fahrzeugüberwachungssystem Diagnostikinformationen zu einem Telekommunikationsnetz zu übertragen.
  • In der Druckschrift US 2015 / 0 213 656 A1 wird ein System zum Monitoring des Fahrverhaltens eines Fahrzeugs beschrieben, das ein an Bord befindliches Diagnosemodul umfasst. Das System umfasst eine Steuerungseinrichtung und ein Fahrverhalten-Bewertungsserver, der vorgesehen ist, in Echtzeit mit der Steuerungseinrichtung zu kommunizieren. Der Server umfasst dabei eine Datenbank zum Speichern der ermittelten Daten. Die Daten werden verarbeitet und dem Fahrer zur Kenntnis gebracht. Weiteren Stand der Technik zum Hintergrunde der Erfindung bilden die Druckschriften US 2013 / 0 005 260 A1 und US 2014 / 0 065 965 A1 .
  • Ein erstes Ausführungsbeispiel enthält ein Fahrzeugcomputersystem, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, und einen Funktransceiver umfasst, der dafür ausgelegt ist, mit der mobilen Einrichtung zu kommunizieren. Das Fahrzeugcomputersystem enthält auch einen mit dem Funktransceiver und einem Speicherelement kommunizierenden Prozessor. Der Prozessor ist dafür ausgelegt, am Funktransceiver erfolgende Aktivität zu überwachen, eine Nachricht vom Funktransceiver zu empfangen, die Informationen in Bezug auf einen oder mehrere Softwarezustände des Funktransceivers enthält, zu bestimmen, dass am Funktransceiver ein Fehler vorgekommen ist, die Informationen in Bezug auf den einen oder die mehreren Softwarezustände des Funktransceivers im Speicherelement zu speichern und die Informationen in Bezug auf den einen oder die mehreren Softwarezustände zu senden.
  • Ein zweites Ausführungsbeispiel enthält ein Gerät, das einen Funktransceiver, der dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, und einen mit dem Funktransceiver kommunizierenden Prozessor umfasst. Der Prozessor ist dafür ausgelegt, am Funktransceiver erfolgende Aktivität zu überwachen, eine Nachricht vom Funktransceiver zu empfangen, die Informationen in Bezug auf einen oder mehrere Softwarezustände des Funktransceivers enthält, zu bestimmen, dass am Funktransceiver ein Fehler vorgekommen ist, und die Informationen in Bezug auf den einen oder die mehreren Softwarezustände zu senden.
  • Ein drittes Ausführungsbeispiel enthält ein Gerät, das einen Funktransceiver, der dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, und einen mit dem Funktransceiver kommunizierenden Prozessor umfasst. Der Prozessor ist dafür ausgelegt, eine Nachricht vom Funktransceiver zu empfangen, die Informationen in Bezug auf einen oder mehrere Softwarezustände des Funktransceivers enthält, basierend auf den Softwarezuständen zu bestimmen, dass am Funktransceiver ein Fehler vorgekommen ist, und die Informationen in Bezug auf die Softwarezustände über den Funktransceiver zu senden.
    • 1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem (Vehicle Based Computing System, VCS) für ein Fahrzeug.
    • 2 veranschaulicht ein beispielhaftes Sequenzdiagramm des fahrzeugbasierten Computersystems, das mit einer mobilen Einrichtung und einem Basisbandprozessor zur Diagnoseüberwachung interagiert.
    • 3 veranschaulicht ein Beispiel für ein DTC-Paket, das zum Kommunizieren von Daten verwendet werden kann.
    • 4 veranschaulicht einen Beispielanwendungsfall in einem beispielhaften Flussschaubild des fahrzeugbasierten Computersystems, das mit einer mobilen Einrichtung und einem Basisbandprozessor zur Diagnoseüberwachung interagiert.
  • Wie erforderlich, werden hierin detaillierte Ausführungsformen der vorliegenden Erfindung offenbart; es versteht sich jedoch, dass die offenbarten Ausführungsformen lediglich beispielhaft für die Erfindung sind, die in verschiedenen und alternativen Ausbildungen ausgeführt werden kann. Die Figuren sind nicht zwingend maßstabsgetreu; einige Merkmale sind möglicherweise übertrieben oder verkleinert, um Details spezieller Komponenten zu zeigen. Deshalb dürfen konkrete Struktur- und Funktionsdetails, die hierin offenbart werden, nicht als begrenzend ausgelegt werden, sondern lediglich als repräsentative Grundlage, um dem Fachmann zu lehren, wie von der vorliegenden Erfindung unterschiedlich Gebrauch gemacht werden kann.
  • 1 veranschaulicht eine beispielhafte Blocktopologie für ein fahrzeugbasiertes Computersystem 1 (Vehicle Based Computing System, VCS) für ein Fahrzeug 31. Ein Beispiel für ein solches fahrzeugbasiertes Computersystem 1 ist das von THE FORD MOTOR COMPANY gefertigte SYNC-System. Ein Fahrzeug, in dem ein fahrzeugbasiertes Computersystem aktiviert ist, enthält möglicherweise eine im Fahrzeug befindliche grafische Front-End-Benutzerschnittstelle 4. Der Benutzer/die Benutzerin kann möglicherweise auch mit der Schnittstelle interagieren, falls sie zum Beispiel mit einem berührungsempfindlichen Bildschirm versehen ist. In einem anderen Ausführungsbeispiel erfolgt die Interaktion durch Drücken von Schaltflächen, ein System für gesprochene Dialoge mit automatischer Spracherkennung und Sprachsynthese.
  • In dem in 1 gezeigten Ausführungsbeispiel 1 steuert ein Prozessor 3 mindestens teilweise den Betrieb des fahrzeugbasierten Computersystems. Der Prozessor, der innerhalb des Fahrzeugs bereitgestellt ist, ermöglicht eine bordseitige Verarbeitung von Befehlen und Routinen. Weiter ist der Prozessor sowohl mit einem flüchtigen 5 als auch mit einem nicht flüchtigen Speicher 7 verbunden. In diesem Ausführungsbeispiel ist der flüchtige Speicher ein Arbeitsspeicher (RAM) und der nicht flüchtige Speicher ein Festplattenlaufwerk (HDD) oder ein Flash-Speicher. Im Allgemeinen kann ein nicht flüchtiges (nicht transientes) Speicherelement alle Formen eines Speicherelements enthalten, das Daten behält, wenn ein Computer oder eine andere Einrichtung abgeschaltet wird. Dazu gehören unter anderem HDDs, CDs, DVDs, Magnetbänder, Halbleiterlaufwerke, tragbare USB-Laufwerke und jegliche sonstigen geeigneten Formen von nicht flüchtigen Speicherelementen.
  • Der Prozessor ist auch mit etlichen unterschiedlichen Eingängen ausgestattet, mittels deren der Benutzer/die Benutzerin über eine Schnittstelle mit dem Prozessor kommunizieren kann. In diesem Ausführungsbeispiel sind ein Mikrofon 29, ein Hilfseingang 25 (für den Eingang 33), ein USB-Eingang 23, ein GPS-Eingang 24, ein Bildschirm 4, der möglicherweise ein Berührungsbildschirm-Display ist, und ein BLUETOOTH-Eingang 15 alle bereitgestellt. Ein Eingangswähler 51 ist ebenfalls bereitgestellt, damit ein Benutzer/eine Benutzerin zwischen verschiedenen Eingängen wechseln kann. Der Eingang sowohl zum Mikrofon als auch zum Hilfsanschluss wird vor der Weiterleitung an den Prozessor von einem Umsetzer 27 von analog in digital umgesetzt. Wenngleich dies nicht gezeigt wird, können zahlreiche der Fahrzeugkomponenten und Hilfskomponenten, die mit dem VCS kommunizieren, ein Fahrzeugnetz (wie unter anderem einen CAN-Bus) verwenden, um Daten zu und von dem VCS (oder Komponenten davon) weiterzuleiten.
  • Ausgänge des Systems können unter anderem eine Sichtanzeige 4 und einen Lautsprecher 13 oder einen Stereosystemausgang enthalten. Der Lautsprecher ist mit einem Verstärker 11 verbunden und empfängt sein Signal vom Prozessor 3 durch einen Digital-Analog-Umsetzer 9. Der Ausgang kann auch zu einer Remote-BLUETOOTH-Einrichtung wie einem PND 54 oder einer USB-Einrichtung wie einer Fahrzeugnavigationseinrichtung 60 entlang den bidirektionalen Datenströmen mit den Bezugszeichen 19 bzw. 21 hergestellt sein.
  • In einem Ausführungsbeispiel verwendet das System 1 den BLUETOOTH-Sendeempfänger 15, um mit dem Nomadic Device 53 eines Benutzers/einer Benutzerin (z. B. Mobiltelefon, Smartphone, PDA oder einer beliebigen anderen Einrichtung mit Drahtlos-Remote-Netzkonnektivität) zu kommunizieren 17. Das Nomadic Device kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen ist der Mast 57 möglicherweise ein WiFi-Zugangspunkt.
  • Eine beispielhafte Kommunikation zwischen dem Nomadic Device und dem BLUETOOTH-Sendeempfänger wird durch das Signal 14 dargestellt.
  • Zum Paaren eines Nomadic Device 53 und des BLUETOOTH-Sendeempfängers 15 kann durch einen Button 52 oder eine ähnliche Eingabe angewiesen werden. Folglich wird die CPU dazu angewiesen, dass der bordeigene BLUETOOTH-Sendeempfänger mit einem BLUETOOTH-Sendeempfänger in einem Nomadic Device gepaart wird.
  • Daten können zum Beispiel unter Nutzung eines Datentarifs, von Data over Voice oder von mit einem Nomadic Device 53 assoziierten DTMF-Tönen zwischen der CPU 3 und dem Netz 61 kommuniziert werden. Alternativ ist es möglicherweise wünschenswert, ein bordeigenes Modem 63 mit einer Antenne 18 darin aufzunehmen, um Daten zwischen der CPU 3 und dem Netz 61 über das Sprachband zu kommunizieren 16. Das Nomadic Device 53 kann dann verwendet werden, um mit einem Netz 61 außerhalb des Fahrzeugs 31 zum Beispiel durch Kommunikation 55 mit einem Mobilfunkmast 57 zu kommunizieren 59. In einigen Ausführungsformen kann das Modem 63 eine Kommunikation 20 mit dem Mast 57 zum Kommunizieren mit dem Netz 61 aufbauen. Als nicht ausschließliches Beispiel ist das Modem 63 möglicherweise ein USB-Funkmodem und die Kommunikation 20 möglicherweise eine Mobilfunkkommunikation.
  • In einem Ausführungsbeispiel ist der Prozessor mit einem Betriebssystem ausgestattet, das eine API enthält, um mit einer Modemanwendungssoftware zu kommunizieren. Die Modemanwendungssoftware greift möglicherweise auf ein eingebettetes Modul oder eine eingebettete Firmware im BLUETOOTH-Sendeempfänger zu, um eine drahtlose Kommunikation mit einem Remote-BLUETOOTH-Sendeempfänger (wie demjenigen, der in einem Nomadic Device vorzufinden ist) durchzuführen. Bluetooth ist eine Untermenge der Protokolle für IEEE 802 PANs (Personal Area Networks). Protokolle für IEEE 802 LANs (Local Area Networks) enthalten WiFi und weisen eine sich erheblich mit IEEE 802 PANs deckende Funktionalität auf. Beide sind für drahtlose Kommunikation innerhalb eines Fahrzeugs geeignet. Ein anderes Kommunikationsmittel, das in diesem Bereich verwendet werden kann, sind optische Freiraumnachrichtenübertragung (wie IrDA) und nicht standardisierte Verbraucher-IR-Protokolle.
  • In einer anderen Ausführungsform enthält ein Nomadic Device 53 ein Modem für Sprachband- oder Breitbanddatenkommunikation. In der Data-over-Voice-Ausführungsform kann eine als Frequenzmultiplexverfahren bekannte Technik implementiert werden, wenn der Besitzer/die Besitzerin des Nomadic Device über die Einrichtung reden kann, während Daten transferiert werden. Zu anderen Zeiten, zu denen der Besitzer/die Besitzerin die Einrichtung gerade nicht verwendet, kann beim Datentransfer die ganze Bandbreite (in einem Beispiel 300 Hz bis 3,4 kHz) verwendet werden. Obwohl das Frequenzmultiplexverfahren bei der analogen Mobilfunkkommunikation zwischen dem Fahrzeug und dem Internet üblich sein kann und nach wie vor verwendet wird, wurde es weitgehend abgelöst von Hybriden wie Code Domain Multiple Access (CDMA), Time Domain Multiple Access (TDMA), Space-Domain Multiple Access (SDMA) für digitale Mobilfunkkommunikation. Diese sind je mit ITU IMT-2000 (3G) konforme Standards und bieten Datenraten von bis zu 2 Mbit/s für stationäre oder umhergehende Benutzer/Benutzerinnen und 385 Kbit/s für Benutzer/Benutzerinnen in einem sich fortbewegenden Fahrzeug. 3G-Standards werden derzeit abgelöst von IMT-Advanced (4G), der 100 Mbit/s für Benutzer/Benutzerinnen in einem Fahrzeug und 1 Gbit/s für stationäre Benutzer/ Benutzerinnen bietet. Falls der Benutzer/die Benutzerin über einen mit dem Nomadic Device assoziierten Datentarif verfügt, ist es möglich, dass der Datentarif eine Breitbandübertragung zulässt und das System eine viel größere Bandbreite verwenden könnte (was den Datentransfer beschleunigt). In noch einer anderen Ausführungsform ist das Nomadic Device 53 durch eine Mobilfunkkommunikationseinrichtung (nicht gezeigt) ersetzt, die am Fahrzeug 31 installiert ist. In noch einer anderen Ausführungsform ist das ND 53 möglicherweise eine Einrichtung für ein drahtloses Local Area Network (LAN), die zu Kommunikation zum Beispiel über (unter anderem) ein 802.11 g-Netz (d. h. WiFi) oder ein WiMax-Netz fähig ist.
  • In einer Ausführungsform können ankommende Daten durch das Nomadic Device über Data over Voice oder einen Datentarif, durch den bordeigenen BLUETOOTH-Sendeempfänger und in den internen Prozessor 3 des Fahrzeugs geleitet werden. Im Fall bestimmter temporärer Daten zum Beispiel können die Daten im HDD oder in einem anderen Datenträger 7 so lange gespeichert werden, bis die Daten nicht mehr benötigt werden.
  • Zusätzliche Quellen, die über eine Schnittstelle mit dem Fahrzeug kommunizieren können, beinhalten eine persönliche Navigationseinrichtung (Personal Navigation Device) 54, zum Beispiel mit einer USB-Verbindung 56 und/oder einer Antenne 58, eine Fahrzeugnavigationseinrichtung 60 mit einer USB- 62 oder einer anderen Verbindung, eine bordeigene GPS-Einrichtung 24 oder ein Remote-Navigationssystem (nicht gezeigt) mit Konnektivität zu einem Netz 61. USB gehört zu einer Gruppe von Protokollen für serielle Anschlüsse. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony) und Lynx™ (Texas Instruments)), Serienprotokolle der EIA (Electronics Industry Association), IEEE 1284 (Centronics Port), S/PDIF (Sony/Philips Digital Interconnect Format) und USB-IF (USB Implementers Forum) bilden das Rückgrat der seriellen Standards zwischen Einrichtungen. Die meisten Protokolle können entweder für elektrische oder für optische Kommunikation implementiert werden.
  • Weiter könnte die CPU mit verschiedenen anderen Hilfseinrichtungen 65 kommunizieren. Diese Einrichtungen können durch eine drahtlose 67 oder eine drahtgebundene 69 Verbindung verbunden sein. Die Hilfseinrichtung 65 enthält unter anderem möglicherweise Personal Media Player, drahtlose medizinische Geräte, tragbare Computer und dergleichen.
  • Auch oder alternativ könnte die CPU, zum Beispiel unter Verwendung eines Transceivers für WiFi (IEEE 803.11) 71, mit einem fahrzeugbasierten Drahtlosrouter 73 verbunden sein. Dadurch könnte ermöglicht werden, dass die CPU mit Remote-Netzen in der Reichweite des lokalen Routers 73 verbunden wird.
  • Zusätzlich dazu, dass beispielhafte Prozesse von einem in einem Fahrzeug befindlichen Fahrzeugcomputersystem ausgeführt werden, können die beispielhaften Prozesse in bestimmten Ausführungsformen von einem mit einem Fahrzeugcomputersystem kommunizierenden Computersystem ausgeführt werden. Ein solches System enthält unter anderem möglicherweise eine drahtlose Einrichtung (z. B. und ohne Begrenzung ein Handy) oder ein Remote-Computersystem (z. B. und ohne Begrenzung einen Server), das durch die drahtlose Einrichtung verbunden ist. Gemeinsam können solche Systeme als fahrzeugassoziierte Computersysteme (Vehicle Associated Computing Systems, VACS) bezeichnet werden. In bestimmten Ausführungsformen können spezielle Komponenten der VACS spezielle Abschnitte eines Prozesses abhängig von der speziellen Implementierung des Systems durchführen. Beispielhaft und ohne Begrenzung ist es, falls ein Prozess einen Schritt des Sendens oder des Empfangens von Informationen mit einer gepaarten drahtlosen Einrichtung aufweist, dann wahrscheinlich, dass die drahtlose Einrichtung den Prozess nicht durchführt, weil die drahtlose Einrichtung Informationen mit sich selbst nicht „senden und empfangen“ würde. Für den Durchschnittsfachmann ist ersichtlich, wann es unzweckmäßig ist, ein spezielles VACS auf eine jeweilige Lösung anzuwenden. Bei allen Lösungen ist vorgesehen, dass mindestens das innerhalb des Fahrzeugs selbst befindliche Fahrzeugcomputersystem (Vehicle Computing System, VCS) zum Durchführen der beispielhaften Prozesse fähig ist.
  • 2 veranschaulicht ein beispielhaftes Sequenzdiagramm des fahrzeugbasierten Computersystems 201, das mit einer mobilen Einrichtung 205 und einem Basisbandprozessor 203 zur Diagnoseüberwachung interagiert. Der Diagnosemodus kann die Integrität eines Fahrzeugcomputersystems, das mit anderen Einrichtungen über ein Protokoll wie Bluetooth interagiert, überwachen und bestimmen. Das Fahrzeugcomputersystem kann die Diagnoseüberwachung des Basisbands und seiner verschiedenen Softwareschichten durch verschiedene Softwarestapel und -profile (z. B. Bluetooth-Profile wie A2DP, HFP, PBAP etc.) nutzen. Der Diagnosemodus und die Überwachung können Daten zur Stapelleistung liefern und Einzelheiten von Fehlern loggen, die in einem Bluetooth-System während der Interaktion innerhalb eines Bluetooth-Piconetzes erfasst werden. Der Diagnosemodus/-monitor kann auch Fehler loggen, die in verschiedenen Zuständen, die Funktionsstörungen verschiedener Merkmale (z. B. des Freisprechsystems, der Spracherkennung etc.) auslösen, erfasst werden. Die Diagnoseüberwachung kann auch gültiges Verhalten verschiedener Softwarezustände loggen. Zum Beispiel können Informationen in Bezug auf erfolgreiche Verbindungen und Kommunikation zur künftigen Analyse überwacht und geloggt werden. Der Diagnosemodus kann für Bluetooth-Systeme sowie andere drahtgebundene oder drahtlose Netze (z. B. Wi-Fi, ZigBee, seriell, USB etc.) verwendet werden.
  • In einem Ausführungsbeispiel kann ein Prozessor 201 wie die CCPU mit dem Basisbandprozessor 203 zur Diagnoseüberwachung kommunizieren. Die CCPU 201 kann einen HCl-Bluetooth-Befehl 207 über einen Basisbandprozessor zu einer mobilen Einrichtung 205 senden. Der HCl-Bluetooth-Befehl kann verschiedene Befehle enthalten, die aus dem Stand der Technik wohl bekannt sind, sodass das VCS Daten von der mobilen Einrichtung steuern, senden oder empfangen kann (z. B. Ändern der Lautstärke, Spurwechsel, Entgegennahme von Telefonanrufen, Auflegen für das Telefon, Aktualisieren von Telefonbuch-Kontaktlisten etc.). Der Basisbandtransceiver 203 ermöglicht Kommunikation zwischen der mobilen Einrichtung und dem VCS zum Senden des Bluetooth-Befehls zur mobilen Einrichtung 209 für diese Anweisungen. Daraufhin kann die mobile Einrichtung 205 auf den Befehl ansprechen 205, indem sie Informationen oder Daten zum Basisbandtransceiver sendet. Zum Beispiel kann das VCS Auflegen für ein Mobiltelefon anfordern. Sobald der BT-Befehl gesendet worden ist und die mobile Einrichtung durch Auflegen für das Telefon angesprochen hat, kann die mobile Einrichtung mit Informationen ansprechen 211, um das VCS darüber zu benachrichtigen, dass der Befehl ausgeführt wurde. Mithin können im VCS verschiedene Funktionalitäten erfolgen, sobald diese Daten abgerufen sind (z. B. Aktualisieren der HMI auf dem VCS-Display).
  • Der Basisbandprozessor 203 kann fortwährend auf interne Fehler hin überwachen. Dadurch kann der Diagnosemonitor während des Austauschens von Informationen zwischen der mobilen Einrichtung und dem VCS Fehler zurückverfolgen und Informationen erfassen. Während der Kommunikation zwischen dem VCS und der mobilen Einrichtung kann ein interner Fehler vorkommen. Der Diagnosemonitor kann den Fehler zurückverfolgen und die Info erfassen 213. Die Überwachung der Fehlerdaten kann zwischen dem Basisbandtransceiver mit der CCPU oder der mobilen Einrichtung aufgeteilt sein, um zum Ermöglichen einer Fehlerbeseitigung und künftiger Diagnosereparaturen beizutragen.
  • Die CCPU kann auch einen Diagnosemonitor laufen lassen. Der Diagnosemonitor erkennt, dass kein Ansprechen 215 von der mobilen Einrichtung während der Kommunikation innerhalb eines Bluetooth-Piconetzes/-Netzes erfolgt. Während eines solchen Vorkommnisses kann die CCPU Daten aus dem Basisband-Diagnosemonitor abrufen 217. Die CCPU kann die Daten anfordern oder das Basisband kann die Daten während eines Fehlers aktiv senden 219. Die Diagnosekomponente kann zurückverfolgen, welche Komponente während einer Fehlfunktion in der Softwarekomponente ausgeführt wurde. Die Diagnosekomponente kann auch die Werte aller Zustandsvariablen der Stapelschichten wie RFCOMM/L2CAP und verschiedener Profile anfordern. Die Diagnosekomponente kann auch die Hauptpufferzustände in Form von Speicherbelegung, Überlauf etc. verfolgen. Falls zum Beispiel im MAP-Profil aufgrund eines Parsingfehlers ein Absturz stattgefunden hat, kann der Zurückverfolgungsmechanismus über ein Log dazu verfügen, wo der Absturz stattgefunden hat, bis hin zur Granularität der Leitungsnummer, wenn möglich.
  • Diese Informationen können gemäß verschiedenen DTC-Logging-Anforderungen geloggt werden. Die CCPU kann jegliche solchen Fehler zur späteren Verwendung im Speicherelement loggen 221. Die Diagnosekomponente kann DTC-Fehler mit Datenpaketen loggen, die vordefinierte Felder und Formate im Speicherelement enthalten. Diese Pakete können alle während des Zurückverfolgungsmechanismus erfassten Daten bis zum Vorkommen des Fehlers enthalten, wie später beschrieben.
  • In einem anderen Szenario kann der Basisband-Diagnosemonitor den Fehler beheben 223. Der Diagnosemonitor kann bestimmen, ob jede Schicht des Stapels aktiv ist und auf Handshaking-Transaktionen auf den hergestellten Kanälen anspricht. Zum Beispiel kann der Diagnosemonitor detektieren, ob die RFCOMM-Schicht in der CCPU nicht mehr auf die Telefon-Handshaking-Nachrichten auf einem konkreten Kanal anspricht, was einen Verbindungsabbau ausgelöst hat, und ob der Neuverbindungsversuch und wiederholte Versuche fehlgeschlagen sind. In dem Fall muss der Diagnosemonitor entweder die RFCOMM-Schicht, falls die ACL noch aktiv ist, oder den ganzen Bluetooth-Stapel gemäß einer Reset-Strategie zurücksetzen. Falls das Telefon auf wiederholte Verbindungsversuche vom Bluetooth-Stapel nicht mehr anspricht, muss der Diagnosemonitor der HMI-Schicht empfehlen, dass dem Benutzer/der Benutzerin eine Nachricht anzuzeigen ist, in der die erforderlichen Behebungsschritte stehen, gemäß denen das Telefon aus- und wieder einzuschalten ist, wie in der Telefon-HMI-Bluetooth-Spezifikation angegeben.
  • In einem anderen Szenario kann die mobile Einrichtung stattdessen einen Bluetooth-Befehl 225 an den Basisbandtransceiver initiieren. Der Befehl kann unterschiedliche Aktionen enthalten, etwa Regeln der Lautstärke, Regeln der Lautstärke, Steuern des Betriebs des VCS etc. Nachdem der Basisbandempfänger den BT-Befehl empfangen hat, kann der Basisbandempfänger anfordern, dass die CCPU oder das VCS den vom Handy angeforderten Vorgang umsetzt. Der Basisbandtransceiver kann den BT-Befehl 227 zur CCPU senden, damit das VCS den Befehl durchführt. Beim Senden des BT-Befehls kann der Transceiver das Bluetooth-Protokoll nutzen, um sicherzustellen, dass das VCS den angeforderten Befehl verstehen kann. Falls ein Fehler vorkommt, kann der Diagnosemonitor der CCPU den Fehler detektieren 229. Nach der Detektion des Fehlers kann der Diagnosemonitor die Fehlernachricht im Speicherelement loggen. Infolge des Loggens der Nachricht kann das System die Informationen in Bezug auf die Fehlernachricht und die Softwarezustände zu einer späteren Zeit senden. Die Informationen in Bezug auf die Softwarezustände oder Fehlernachrichten werden zum Beispiel möglicherweise über WiFi zu einer speziellen Website gesendet. Die Website kann die Softwarezustandinformationen zum Analysieren des Codes speichern, um künftige Fehler zu verhindern.
  • Der Diagnosemonitor kann den geloggten DTC zur Analyse und Korrektur an einen bordexternen Server (z. B. die Website eines Herstellers oder eines Anbieters, einen Softwarehersteller etc.) transferieren. Falls ein Fahrzeug zum Beispiel in der Nähe des Wohnsitzes eines Benutzers/einer Benutzerin geparkt ist, kann das VCS auf das WIFI-Netz des Benutzers/der Benutzerin zugreifen. Wenn sich das Fahrzeug der Umgebung des Heimnetzes des Kunden/der Kundin nähert, kann es eine Verbindung zu einem bordexternen Server (z. B. zur Ford-Website) aufbauen. Das Fahrzeug kann sich über ein Passwort authentifizieren, das diesem konkreten Kunden/dieser konkreten Kundin zugewiesen ist, um den DTC im Fehlerportfolio des Kunden/der Kundin zur Analyse zu loggen. Dieser Prozess lässt sich bei beliebig vielen Vorkommnissen ausführen (z. B. täglich, wöchentlich, monatlich etc.). Nach dem Transferieren der DTC-Logs zur bordexternen Stelle können die DTCs innerhalb des Fahrzeugs gelöscht und am nächsten Tag mit einer neuen Menge von DTCs überschrieben werden. Zahlreiche andere Szenarios oder Situationen sind denkbar, um Informationen zu loggen. Zum Beispiel kann der Benutzer/die Benutzerin in einem anderen Szenario einen Vertragshändler für routinemäßige Service- oder Wartungsleistungen oder eine Reparatur aufsuchen. Nach dem Ankommen beim Vertragshändler kann das Fahrzeug eine Verbindung zum Wifi-Netz des Vertragshändlers aufbauen, um die DTC-Logs zu transferieren.
  • 3 veranschaulicht ein Ausführungsbeispiel für ein DTC-Paket 301. Das DTC-Paket kann verschiedene Beschreibungen enthalten, die zum Ermöglichen einer Fehlerüberwachung beitragen. Zum Beispiel enthält das DTC-Paket möglicherweise eine Paket-ID 303. Die Paket-ID 303 kann einen Identifikationsnamen oder eine ID liefern, der bzw. die mit einem konkreten Paket assoziiert ist. Dadurch können konkrete Pakete, die konkrete Daten beinhalten, leichter identifiziert werden. Falls das Paket mithin für eine konkrete Aktion oder konkrete Informationen bestimmt ist, kann es dank der Paket-ID leichter identifiziert werden.
  • Des Weiteren kann das DTC-Paket 301 auch einen Fehlertyp 305 enthalten. Der Fehlertyp 303 beschreibt möglicherweise einen Absturz (gibt an, welche Komponente ausgefallen ist, zum Beispiel MAP), einen Verbindungsabbau für ein konkretes BT-Profil (z. B. BT, MAP, PBAP, AVRCP, A2DP), einen Verbindungsabbau für einen Stapel oder ein Protokoll (z. B. RFCOMM-Verbindungsabbau, L2CAP-Verbindungsabbau etc.), einen HCl-Pufferüberlauf, einen UART-Überlauf, einen Überlauf anderer Puffer (z. B. vor allem den Komponentenüberlauf) etc... Dadurch lassen sich Speicherverletzungen beim Verwenden verschiedener Ausführungsformen des Systems leichter verhindern.
  • Des Weiteren kann das DTC-Paket 301 einen Deskriptor für die Zustandsvariablen 207 enthalten. Alle Profile Zustandsvariablen, RFCOMM-Zustandsvariablen, L2CAP-Zustandsvariablen, HCl-Zustandsvariablen, Zustandsvariablen anderer Bluetooth-Softwarekomponenten.
  • Das DTC-Paket kann einen Deskriptor für einen Bluetooth-Pufferüberlauf 309 enthalten. Der Bluetooth-Pufferüberlauf erklärt möglicherweise, welcher Puffer beschädigt wurde, und die Speicherbelegung des Überlaufs. Durch Analysieren des Pufferüberlauffehlers kann Software aktualisiert werden, um zu verhindern, dass ein Programm oder ein Prozess mehr Daten im Puffer speichert, als er aufnehmen sollte. Dies kann auch dazu dienen, einen Pufferüberlaufangriff zu identifizieren.
  • Das DTC-Paket kann einen Deskriptor für eine Fehlerbeschreibung 311 enthalten. Die Fehlerbeschreibung kann einen Grund für einen Fehlercode beschreiben, falls er infolge der Implementierung bereitgestellt ist, etwa Verbindungsabbaugrund-Fehlercode oder Stapel-Timeout-Fehlercode, SMS-Nachricht beinhaltet schlechten Code oder unbekannte Zeichen aufweisenden Fehlercode etc.
  • Das DTC-Paket kann einen Deskriptor für eine Leitungsnummer 313 enthalten. Der Leitungsnummerndeskriptor 313 der letzten Anweisung, die ausgeführt wurde, als der Fehler vorkam. Dadurch wird die genaue Codezeile, die einen Fehler von irgendeinem Typ auslöst, leichter diagnostizierbar. Dadurch kann zum Ermöglichen einer Problembehandlung des Maschinencodes beigetragen werden, um eventuelle Fehler, die vorgekommen sind, zu berichtigen.
  • Das DTC-Paket kann einen Deskriptor für das Vorkommnis 315 enthalten. Dadurch kann der Fehler detailliert oder die Anzahl der Vorkommnisse desselben Fehlers (Paket-ID) beschrieben werden. Dadurch kann zum Ermöglichen einer Problembehandlung des Codes beigetragen werden, damit immer wieder vorkommende Fehler, die routinemäßig vorkommen, auf der Basis eines konkreten Codes, der ausgeführt wird, leichter identifiziert werden können.
  • 3 sollte nur als Beispiel dienen und zur Veranschaulichung herangezogen werden, um nur ein Beispiel für ein DTC-Paket zu erklären. Die Deskriptoren eines DTC-Pakets lassen sich anders anordnen, erweitern, minimieren oder einschränken. Zum Beispiel enthält ein DTC-Paket möglicherweise nicht jeden Deskriptor, der gezeigt wird, wie den Leitungsnummerndeskriptor. Des Weiteren kann das DTC-Paket zusätzliche Deskriptoren enthalten, um zusätzliche Informationen zum Erklären des Fehlers, der vorkommt, aufzunehmen.
  • Jeder Hersteller kann eine eindeutige Diagnosenachricht definieren, um die Integrität und den Zustand eines Funktransceivers (z. B. Bluetooth-Basisband) zu testen. Die Nachricht wird möglicherweise von den Anbietern des Transceivers unterstützt. Der Anbieter und der Erstausrüster können eine Einigung erzielen, um die Nachrichtenmenge für Interoperabilität zu bestimmen. Die Nachricht kann ein HCl-Anforderungspaket sein. Die Nachricht kann durch die CCPU zum Transceiver (z. B. Bluetooth-Basisband) gesendet werden, um verschiedene Softwarezustände, Speicherpufferzustände oder andere Informationen anzufordern. Ein Ausführungsbeispiel für das Nachrichtenfeld ist wie folgt:
    7 6 5 4 3 2 1 0
  • Bit 0: falls auf 1 gesetzt, kann die ACL-Konnektivitätsintegrität des Basisbands testen. Es kann auch bestimmen, ob das Handshaking auf dem Link Layer und dem RF Layer aktiv ist. Dieses Bit kann auch bestimmen, ob das Basisband nicht mehr auf AG-Nachrichten auf der ACL anspricht. Des Weiteren könnte es bestimmen, ob das Seitentimeout ein Softwareintegritätsproblem im Basisband oder ein Hardwareproblem ist. Das Basisband kann einen Diagnosemonitor implementieren, um zu bestimmen, ob die Software im Chipsatz einen Fehlerzustand erreicht hat, wodurch sich die Integrität der Verbindung und ihre Zustände leichter bestimmen lassen.
  • Bit eins: falls auf 1 gesetzt: Das Basisband kann seine Softwarestapel-Zustandsvariablen, die von den Ford-BT-Diagnosemonitoren geloggt werden sollen, in eine Website ausspeichern, wo sie für den Basisbandanbieter zum Debuggen bereitgestellt werden können. Dies kann vorkommen, wenn das VCS erstmals mit dem Internet verbunden wird.
  • Bit zwei: falls auf 1 gesetzt: Das Basisband sollte die Zustände seiner Speicherpuffer, ihre Größen und die Information, ob sie beschädigt sind, angeben. Dadurch lassen sich Softwareprobleme leichter beheben, um Fehler leichter debuggen zu können.
  • Bit drei: falls auf 1 gesetzt: Das Basisband sollte einen Diagnosezustand seiner BT-Hardwareeinrichtungen und -Peripheriegeräte angeben. Dadurch lassen sich Softwareprobleme leichter beheben, um Fehler leichter debuggen zu können.
  • Bit vier: falls auf 1 gesetzt: Das Basisband sollte einen Diagnosezustand des BT-HCl-UART-Treibers angeben. Dadurch lassen sich konkrete Softwareprobleme in Bezug auf die mit der BT-Hardware assoziierten Treiber leichter beheben.
  • Bits fünf - sieben: lassen sich für beliebig viele Verfahren zur künftigen Verwendung für andere Ausführungsformen verwenden, die Daten zum Identifizieren von Fehlern im Code beinhalten könnten. Mithin lassen sich die Bits fünf - sieben für andere Daten nutzen, welche die CCPU möglicherweise vom Basisbandtransceiver angefordert hat. Zum Beispiel können konkrete BT-Profile eindeutige Software beinhalten, von der die CCPU Diagnose-Informationen durch Nutzung eines dieser Bits anfordern kann. Für den Durchschnittsfachmann werden möglicherweise zusätzliche Ausführungsformen erkennbar.
  • Das VCS ist möglicherweise fähig zum Definieren verschiedener Diagnosemodi, die Fehler loggen können. Die Diagnosemodi können unterschiedlich und für unterschiedliche Situationen definiert sein. Der Diagnosemodus enthält zum Beispiel möglicherweise einen Diagnosemodus für Prüfstandtests. Ein Prüfstandtestmodus kann von Testern an einem Prüfstand oder während einer Testphase des Fahrzeugs angewendet werden. In einem Prüfstandtestmodus ist ein Benutzer/eine Benutzerin oder ein Tester/eine Testerin möglicherweise dazu fähig, eine Nachricht durch ein RS232-, USB-, Ethernet- oder ein anderes drahtgebundenes oder Drahtlosprotokoll an den Diagnosemonitor weiterzuleiten, um einen eindeutigen zuvor bestimmten HCl-Befehl oder einen eindeutigen zuvor bestimmten Profilbefehl auszuführen. Zum Beispiel bildet der Diagnosemonitor möglicherweise einen HCl-Befehl, um ihn durch den Stapel mit einer SMS-Benachrichtigungsnachricht an das MAP-Profil weiterzuleiten. Das Profil sollte diese Nachricht bestätigen, die angibt, ob die MAP-Verbindung gültig und erfolgreich ist. In einem anderen Beispiel soll der entgegengesetzte Pfad dort verlaufen, wo eines der Profile eine Nachricht an den Stapel weitergibt und ein HCl-Paket gebildet und von einem Sniffer detektiert werden soll. Diverse Nachrichten und Befehle sollen gebildet und erstellt werden. Diese Tests, wenn sie laufen, falls das Profil oder der Stapel einen fehlerhaften Zustand aufweist, verfolgen den gewählten Softwarepfad wie Funktionsnamen und Zustandsvariablen zurück und bestimmen, wo die Aufhängung erfolgt ist. Es können beliebig viele Diagnosemodi für verschiedene Situationen genutzt werden.
  • 4 veranschaulicht ein beispielhaftes Flussschaubild des fahrzeugbasierten Computersystems, das mit einer mobilen Einrichtung und einem Basisbandprozessor zur Diagnoseüberwachung interagiert. Verschiedene Ausführungsformen können einen Prozessor enthalten, der so angepasst ist, dass er Anweisungen zum Ausführen des folgenden Algorithmus zur Diagnoseüberwachung enthält. Der Prozessor kann automatisch oder manuell für Überprüfungen auf Fehler 401 hin eingestellt werden. Mithin kann der Prozessor während der Kommunikation mit einer mobilen Einrichtung permanent auf Fehler hin überwachen 403. Falls kein Fehler vorgekommen ist, kann der Prozessor wie üblich arbeiten und weiter auf Probleme hin überwachen. Falls hingegen ein Fehler vorkommt, kann der Diagnosemodus derart wirken, dass er die zugrunde liegende Ursache des Fehlers bestimmen kann.
  • Der Prozessor kann auf die Komponente hin überprüfen, die von verschiedenen Softwaremodulen oder -anwendungen ausgeführt wurde 405. Dadurch lässt sich die zugrunde liegende Ursache der Fehler leichter bestimmen. Der Diagnosemodus kann Fehler erfassen, Fehlervorkommnisse in Software zurückverfolgen, Fehler loggen, Heartbeats aus den Stapelschichten als Hinweis auf die Konnektivität überwachen, die Werte von Zustands- und Hauptvariablen von Stapeln und Profilen während eines Fehlervorkommnisses loggen, das Basisband testen und Fehler über WiFi senden. In einem Beispiel kann der Diagnosemodus das Basisband durch Weiterleiten von zuvor bestimmten Nachrichten an das Basisband testen und eine Rückantwort erwarten, die Daten und die Status seines Zustands liefert. Der Diagnosemodus ist möglicherweise auch fähig, zuvor bestimmte Nachrichten durch die Stapel-HCl bis hinauf zu den Profilen und von den Profilen hinab zur HCl im Pushverfahren zu übertragen, um die Systemintegrität im speziellen Diagnosemodus, der noch mehr Logging-Möglichkeiten bietet, zu testen.
  • Des Weiteren können bei der Diagnoseüberwachung Werte verschiedener Zustandsvariablen im Basisbandprozessor oder in der CCPU angefordert werden 407. Der Diagnosemodus kann den Zustand des Bluetooth-Systems während Zuständen mit Funktionsstörungen erfassen und Aktivität oder Fehler im Speicherelement loggen. Die Diagnosekomponente kann auch die Werte aller Zustandsvariablen der Stapelschichten wie RFCOMM/L2CAP und andere Profile zum Loggen anfordern. Über das Loggen können die Voraussetzungen dafür geschaffen werden, dass Informationen vom Fahrer/von der Fahrerin für eine Analyse, zum Debuggen und/oder zur Untersuchung über ein WIFI-Netz zu einer bordexternen Website gesendet werden. Der Diagnosemodus kann anderen Softwarekomponenten im System signalisieren, dass die Softwarezustände der Komponente oder der Komponenten mit Funktionsstörung wie des Stapels und der Profile zurückzusetzen sind, um ein Problem zu lösen. Zum Beispiel initiiert der Diagnosemodus möglicherweise eine neue Verbindung zum Handy. Die Logging-Daten können auch manuell von einer das externe Speicherelement verwendenden Person abgerufen werden.
  • Die Diagnoseüberwachung fordert Pufferzustände an 409. Dadurch kann die Diagnosekomponente auch einfacher die Hauptpufferzustände in Form von Speicherbelegung, Überlauf etc. verfolgen. Falls zum Beispiel im MAP-Profil aufgrund eines Parsingfehlers ein Absturz stattgefunden hat, kann der Zurückverfolgungsmechanismus über ein Log dazu verfügen, wo der Absturz stattgefunden hat, bis hin zur Granularität der Leitungsnummer, wenn möglich. Solche Daten können hilfreich sein, wenn sie aus dem Log extrahiert werden, um eventuelle Softwarefehler zu debuggen.
  • Nach dem Abrufen von Diagnoseüberwachungsinformationen kann die CCPU die empfangenen Informationen loggen 411. Die Daten können während bestimmter Szenarios zu einem bordexternen Server gesendet oder von einem Benutzer/einer Benutzerin oder einem Techniker/einer Technikerin (z. B. einem Vertragshändlertechniker/einer Vertragshändlertechnikerin) manuell abgerufen werden. In einem Szenario kann die CCPU einen Fehler loggen, der während des Bluetooth-Paarungsprozesses vorgekommen ist. Die CPU kann so programmiert werden, dass die Logging-Informationen während eines bestimmten Szenarios zu einem bordexternen Server gesendet werden. Sobald ein Fehler geloggt ist, kann die CCPU zum Beispiel beim ersten Vorkommen eines Verbindungsaufbaus zum Internet Anweisungen zum Basisbandprozessor oder zu einem anderen Transceiver senden, um die Informationen zum Server eines Erstausrüsters zu senden. Das VCS kann eine Verbindung zum Internet durch Nutzung des Handys eines Benutzers/einer Benutzerin (z. B. Datenverbindung über 3G/CDMA/GSM4G/LTE) oder über eine Wi-Fi-Verbindung aufbauen. Ein Drittanbieterserver kann genutzt werden, um die Fehler mit Blick auf künftige Softwareupgrade-Korrekturen zu analysieren. In einem anderen Szenario kann die CCPU die Daten senden, wenn ein Vertragshändlertechniker/eine Vertragshändlertechnikerin oder ein Kunde/eine Kundin einen USB-Stick (oder eine andere Speichereinrichtung) einführt, nachdem ein Fehler geloggt worden ist. Eine Nachricht kann auf dem VCS-Display erscheinen, um zu bestätigen, ob die geloggten Informationen zu einer externen Einrichtung transferiert oder zu einem bordexternen Server gesendet werden sollen.
  • Wenngleich oben beispielhafte Ausführungsformen beschrieben werden, ist nicht beabsichtigt, dass diese Ausführungsformen alle möglichen Ausbildungen der Erfindung beschreiben. Vielmehr sind die in der Patentschrift genutzten Begriffe beschreibende und keine begrenzenden Begriffe, und es versteht sich, dass verschiedene Änderungen vorgenommen werden können, ohne vom Gedanken und vom Schutzbereich der Erfindung abzuweichen. Des Weiteren lassen sich die Merkmale verschiedener implementierender Ausführungsformen so kombinieren, dass weitere Ausführungsformen der Erfindung gebildet werden.
  • ZEICHENERKLÄRUNG
    • 3
      DTC Packet
      DTC-Paket
      303
      Paket-ID
      305
      Fehlertyp [Fehler-typ]
      307
      Zustandsvariable [Zustands-variable]
      309
      BT-Pufferüberlauf [BT-Puffer-überlauf]
      311
      Fehlerbeschreibung [Fehler-beschreibung]
      313
      Fehler-Nr.
      315
      Vorkommnis
    • 4
      401
      Überprüfen auf Fehler
      403
      Ist Fehler vorgekommen?
      N
      Nein
      405
      Überprüfen auf von SW ausgeführte Komponente
      407
      Anfordern von Werten von Zustandsvariablen
      409
      Anfordern von Pufferzuständen
      411
      Loggen empfangener Informationen
      413
      Empfangen von Anforderung zum Senden?
      415
      Senden von Fehlerlog [Fehler-log]

Claims (8)

  1. Fahrzeugcomputersystem (VCS), das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, umfassend: einen Funktransceiver, der dafür ausgelegt ist, mit der mobilen Einrichtung zu kommunizieren; einen mit dem Funktransceiver und einem Speicherelement kommunizierenden Prozessor, wobei der Prozessor ausgelegt ist, um: 1.) am Funktransceiver erfolgende Aktivität zu überwachen; 2.) eine Nachricht vom Funktransceiver zu empfangen, die Informationen in Bezug auf einen oder mehrere Softwarezustände des Funktransceivers enthält; 3.) zu bestimmen, dass am Funktransceiver ein Fehler vorgekommen ist; 4.) die Informationen in Bezug auf den einen oder die mehreren Softwarezustände des Funktransceivers im Speicherelement zu speichern; und 5.) die Informationen in Bezug auf den einen oder die mehreren Softwarezustände zu senden, dadurch gekennzeichnet, dass der Prozessor weiter dafür ausgelegt ist, am Funktransceiver erfolgende Aktivität basierend darauf zu überwachen, dass zur Diagnoseüberwachung eine Eingabe zum Aktivieren eines Diagnosemodus empfangen wird, wobei der Diagnosemodus die Aktivität definiert, die am Funktransceiver überwacht wird, wobei der die Aktivität definierende Diagnosemodus einen Fehlerbehebungsmodus enthält, und die Diagnoseüberwachung Pufferzustände anfordert.
  2. Fahrzeugcomputersystem nach Anspruch 1, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Prozessor weiter dafür ausgelegt ist, am Funktransceiver erfolgende Aktivität zu überwachen, indem er ein Anforderungspaket zum Funktransceiver sendet, mit dem Informationen hinsichtlich des einen oder der mehreren Softwarezustände des Funktransceivers angefordert werden.
  3. Fahrzeugcomputersystem nach Anspruch 1, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Prozessor weiter dafür ausgelegt ist, die Informationen in Bezug auf den einen oder die mehreren Softwarezustände des Funktransceivers über den Funktransceiver zu einem bordexternen Server zu senden.
  4. Fahrzeugcomputersystem nach Anspruch 1, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Prozessor weiter dafür ausgelegt ist, die Informationen in Bezug auf den einen oder die mehreren Softwarezustände über einen Langstrecken-Funktransceiver zu einem bordexternen Server zu senden.
  5. Fahrzeugcomputersystem nach Anspruch 4, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Langstrecken-Transceiver ein Funkmodem ist.
  6. Fahrzeugcomputersystem nach Anspruch 1, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Prozessor weiter dafür ausgelegt ist, die Informationen in Bezug auf den einen oder die mehreren Softwarezustände über einen Kurzstrecken-Transceiver zu einer externen Speichereinrichtung zu senden.
  7. Fahrzeugcomputersystem nach Anspruch 6, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei der Kurzstrecken-Transceiver ein Universal-Serial-Bus(USB)-Transceiver ist.
  8. Fahrzeugcomputersystem nach Anspruch 1, das dafür ausgelegt ist, mit einer mobilen Einrichtung zu kommunizieren, wobei die Informationen in Bezug auf den einen oder die mehreren Softwarezustände Daten hinsichtlich eines Fehlerverhaltens und eines gültigen Verhaltens des Funktransceivers enthalten.
DE102015207657.1A 2014-04-29 2015-04-27 Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul Active DE102015207657B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/264,672 2014-04-29
US14/264,672 US9304846B2 (en) 2014-04-29 2014-04-29 Apparatus and method of error monitoring with a diagnostic module

Publications (2)

Publication Number Publication Date
DE102015207657A1 DE102015207657A1 (de) 2015-10-29
DE102015207657B4 true DE102015207657B4 (de) 2024-04-18

Family

ID=54262029

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015207657.1A Active DE102015207657B4 (de) 2014-04-29 2015-04-27 Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul

Country Status (3)

Country Link
US (2) US9304846B2 (de)
CN (1) CN105025074B (de)
DE (1) DE102015207657B4 (de)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015199754A1 (en) * 2014-06-24 2015-12-30 Ruckus Wireless, Inc. Provisioning radios associated with acess points for testing a wireless network
KR102298767B1 (ko) * 2014-11-17 2021-09-06 삼성전자주식회사 음성 인식 시스템, 서버, 디스플레이 장치 및 그 제어 방법
JP6398758B2 (ja) * 2015-02-03 2018-10-03 株式会社デンソー 車両用通信機
DE102015214739B4 (de) * 2015-08-03 2022-12-29 Volkswagen Aktiengesellschaft Verfahren zur Bestimmung einer Fehlerursache bei einem Fahrzeug und Server zum Durchführen der Bestimmung der Fehlerursache
KR101768138B1 (ko) * 2015-10-26 2017-08-30 현대자동차주식회사 블루투스 호환성 문제 해결 방법 및 그를 위한 장치
DE102017206559A1 (de) * 2017-04-19 2018-10-25 Robert Bosch Gmbh Steuergerät und Betriebsverfahren hierfür
WO2019021064A1 (en) * 2017-07-25 2019-01-31 Aurora Labs Ltd CONSTRUCTION OF SOFTWARE DELTA UPDATES FOR VEHICLE ECU SOFTWARE AND TOOL-BASED ANOMALY DETECTION
US20190392042A1 (en) * 2018-06-20 2019-12-26 TuSimple Method and system of managing error data associated with a vehicle
CN111105520B (zh) * 2018-10-29 2022-08-02 浙江吉利汽车研究院有限公司 一种车辆事件数据记录方法和设备
KR102604010B1 (ko) * 2019-01-22 2023-11-20 주식회사 아도반테스토 온-칩-시스템 테스트 제어기를 사용하는 자동 테스트 장비
JP7139971B2 (ja) * 2019-01-23 2022-09-21 トヨタ自動車株式会社 ソフトウェア配布システムおよびソフトウェア配布方法
CN110233871B (zh) * 2019-04-30 2021-10-12 努比亚技术有限公司 通信控制方法、设备、系统及可读存储介质
CN112146885B (zh) * 2020-09-29 2021-11-23 东风汽车集团有限公司 一种远程车载故障排查和修复的方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100256861A1 (en) 2009-04-07 2010-10-07 Ford Global Technologies, Llc System and method for performing vehicle diagnostics
US8036788B2 (en) 1995-06-07 2011-10-11 Automotive Technologies International, Inc. Vehicle diagnostic or prognostic message transmission systems and methods
US20130005260A1 (en) 2011-06-30 2013-01-03 Denso Corporation Short range wireless communication apparatus
US20140065965A1 (en) 2012-09-06 2014-03-06 Ford Global Technologies, Llc Context adaptive content interaction platform for use with a nomadic device
US20150213656A1 (en) 2012-07-26 2015-07-30 Wunelli Limited Driving Behavior Monitoring System

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6604038B1 (en) * 1999-11-09 2003-08-05 Power Talk, Inc. Apparatus, method, and computer program product for establishing a remote data link with a vehicle with minimal data transmission delay
US7006845B2 (en) * 2002-04-03 2006-02-28 General Motors Corporation Method and system for interfacing a portable transceiver in a telematics system
US20040203379A1 (en) 2002-04-23 2004-10-14 Johnson Controls Technology Company Bluetooth transmission of vehicle diagnostic information
DE10313467A1 (de) * 2003-03-26 2004-10-07 Daimlerchrysler Ag Verfahren zur Fehlerdiagnose und dabei einsetzbarer Datenprotokollwandler
US20060229777A1 (en) * 2005-04-12 2006-10-12 Hudson Michael D System and methods of performing real-time on-board automotive telemetry analysis and reporting
US9117319B2 (en) * 2005-06-30 2015-08-25 Innova Electronics, Inc. Handheld automotive diagnostic tool with VIN decoder and communication system
CA2621775A1 (en) * 2005-08-31 2007-03-08 Pinpoint Tracking Solutions, Llc Method and apparatus for secure wireless tracking and control
DE102006019972A1 (de) * 2006-04-29 2007-11-08 Daimlerchrysler Ag Diagnosesystem mit WLAN Übertragungsmodul und implementiertem Diagnosenkurztest
US9483880B2 (en) * 2006-06-13 2016-11-01 Cellassist, Llc Automotive ECU mobile phone interface
US20080086266A1 (en) * 2006-10-04 2008-04-10 Howard Dwight A System and method for storing a vehicle location on the occurrence of an error
US8370020B2 (en) 2007-06-22 2013-02-05 Lear Corporation Method and system for communicating vehicle diagnostic data to internet server via Bluetooth enabled cell phone for subsequent retrieval
US20090328189A1 (en) * 2008-05-05 2009-12-31 Gm Global Technology Operations, Inc. Secure wireless communication initialization system and method
US8280581B2 (en) * 2008-05-07 2012-10-02 Spx Corporation Dynamic discovery of vehicle communication interface device and method
US8180519B2 (en) * 2008-09-02 2012-05-15 International Business Machines Corporation Cooperative vehicle diagnostics
CN201335955Y (zh) * 2009-01-16 2009-10-28 深圳市浚海仪表设备有限公司 一种基于CANopen协议的CAN总线智能电动装置
US20110225096A1 (en) * 2010-03-15 2011-09-15 Hanbum Cho Method And System For Providing Diagnostic Feedback Based On Diagnostic Data
US9094436B2 (en) * 2010-05-27 2015-07-28 Ford Global Technologies, Llc Methods and systems for interfacing with a vehicle computing system over multiple data transport channels
US20120029759A1 (en) * 2010-08-02 2012-02-02 Suh Peter Jung-Min Method of providing vehicle maintenance information and service
US8559932B2 (en) * 2010-12-20 2013-10-15 Ford Global Technologies, Llc Selective alert processing
US8831817B2 (en) * 2011-03-07 2014-09-09 Ford Global Technologies, Llc Methods and apparatus for lost connection handling
CN102291444A (zh) * 2011-08-04 2011-12-21 哈尔滨海铭科技有限公司 基于通信网络实时信息的车载电脑和服务中心诊断系统
US20130205412A1 (en) * 2011-11-16 2013-08-08 Flextronics Ap, Llc On board vehicle media controller
US9043073B2 (en) * 2011-11-16 2015-05-26 Flextronics Ap, Llc On board vehicle diagnostic module
US9173100B2 (en) * 2011-11-16 2015-10-27 Autoconnect Holdings Llc On board vehicle network security
US9128156B2 (en) * 2012-05-03 2015-09-08 Bosch Automotive Service Solutions Inc. Alternator and starter tester with other failures determination functionality and method
JP5943792B2 (ja) * 2012-09-24 2016-07-05 ヤフー株式会社 運転支援システム、運転支援装置、運転支援方法及びプログラム
CN103312818A (zh) * 2013-07-03 2013-09-18 深圳市元征科技股份有限公司 一种车辆诊断方法及服务器
US9286736B2 (en) * 2013-12-16 2016-03-15 Manish Punjabi Methods and systems of vehicle telematics enabled customer experience
US20170024943A1 (en) * 2014-03-19 2017-01-26 Cummins, Inc. System and Method for Service Assessment
US9990781B2 (en) * 2014-09-05 2018-06-05 Vinli Vehicle information system
US10282923B2 (en) * 2014-12-30 2019-05-07 Craig A. Tieman Connected vehicle system with infotainment interface for mobile devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8036788B2 (en) 1995-06-07 2011-10-11 Automotive Technologies International, Inc. Vehicle diagnostic or prognostic message transmission systems and methods
US20100256861A1 (en) 2009-04-07 2010-10-07 Ford Global Technologies, Llc System and method for performing vehicle diagnostics
US20130005260A1 (en) 2011-06-30 2013-01-03 Denso Corporation Short range wireless communication apparatus
US20150213656A1 (en) 2012-07-26 2015-07-30 Wunelli Limited Driving Behavior Monitoring System
US20140065965A1 (en) 2012-09-06 2014-03-06 Ford Global Technologies, Llc Context adaptive content interaction platform for use with a nomadic device

Also Published As

Publication number Publication date
US20150309859A1 (en) 2015-10-29
DE102015207657A1 (de) 2015-10-29
US20160189441A1 (en) 2016-06-30
CN105025074A (zh) 2015-11-04
CN105025074B (zh) 2019-08-27
US10002467B2 (en) 2018-06-19
US9304846B2 (en) 2016-04-05

Similar Documents

Publication Publication Date Title
DE102015207657B4 (de) Gerät und verfahren zur fehlerüberwachung mit einem diagnosemodul
DE102014224133B4 (de) Verfahren und Vorrichtung zum Registrieren eines neuen Bluetooth-Geräts
DE102012211930B4 (de) Detektion der Kontaktaufnahme durch paarweise zugeordnete Fahrzeugvorrichtungen mit Bluetooth Low Energy
US20160110929A1 (en) Method and system for providing vehicle security service
DE102016100430A1 (de) Verfahren und Systeme zur Aktualisierung von Fahrzeugsteuerungen
DE102016101327A1 (de) Reagieren auf elektronisches Eindringen im Fahrzeug
US20160308743A1 (en) Determining performance criteria of a vehicle communication network connection
DE102015104651A1 (de) Fernfahrzeugkonnektivitätsstatus
DE102008030974A1 (de) Verfahren zum Bereitstellen von datenbezogenen Diensten für ein Fahrzeug mit Telematikausstattung
DE102015107505A1 (de) Verfahren und System zum Starten einer Anwendung
EP3011541A1 (de) Modul und system zur fahrzeugdiagnose
DE102014217407A1 (de) Verfahren und Einrichtung für ein Borddiagnose-Schnittstellenwerkzeug
DE102015109295A1 (de) Fahrergeräteerkennung
DE102016105400A1 (de) Verfahren und systeme zur konfiguration eines fahrzeugmerkmals
DE102017120505A1 (de) System zur Verifikation einer unregistrierten Vorrichtung basierend auf Informationen eines Ethernet-Switchs und Verfahren für dasselbige
DE102017117039A1 (de) Betrieb eines drahtlosen fahrzeugzugangspunkts zum selektiven verbinden mit drahtlosen fahrzeugvorrichtungen
DE102016102186A1 (de) Verfahren und Vorrichtung zur Fahrzeugwarnlichtbehandlung
DE102014118949A1 (de) Verfahren und Systeme für einen Head Unit Anwendungs-Host
DE102014009242A1 (de) Verfahren zum Aufbau und zum Betrieb eines drahtlosen Netzwerks
DE102014220069B4 (de) Vorrichtung zum verbinden von mobilgeräten
DE102005048427B3 (de) Kommunikations-Anordnung für ein Fahrzeug
DE102017109107A1 (de) Verwaltung von lizenzierten und nicht lizenzierten kommunikationen unter verwendung von zellularen protokollen
DE102017102616A1 (de) Verwalten von remote-bereitstellung an einer mobilen vorrichtung
CN104301405A (zh) 一种车辆诊断方法、模块及系统
DE102019104486A1 (de) Charakterisieren eines fahrzeugs basierend auf drahtlosen übertragungen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R082 Change of representative

Representative=s name: PATERIS THEOBALD ELBEL & PARTNER, PATENTANWAEL, DE

Representative=s name: PATERIS THEOBALD ELBEL FISCHER, PATENTANWAELTE, DE

R016 Response to examination communication
R084 Declaration of willingness to licence
R018 Grant decision by examination section/examining division