DE10392279T5 - Kommunikationsbrücke zwischen einem Fahrzeuginformationsnetz und einem Fernsystem - Google Patents

Kommunikationsbrücke zwischen einem Fahrzeuginformationsnetz und einem Fernsystem Download PDF

Info

Publication number
DE10392279T5
DE10392279T5 DE10392279T DE10392279T DE10392279T5 DE 10392279 T5 DE10392279 T5 DE 10392279T5 DE 10392279 T DE10392279 T DE 10392279T DE 10392279 T DE10392279 T DE 10392279T DE 10392279 T5 DE10392279 T5 DE 10392279T5
Authority
DE
Germany
Prior art keywords
port
usb
communication
adapter
interface
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.)
Granted
Application number
DE10392279T
Other languages
English (en)
Other versions
DE10392279B4 (de
Inventor
Alexander N. Columbus Knight
Andrew J. Columbus Pajakowski
Jon E. Greenwood Krutulis
Daniel P. Columbus Wolf
Michael W. Columbus Phillips
Joseph T. Cincinnati Beitzinger
Lee G. Columbus Shipman
J. Patrick Cincinnati Eberly
W. Patrick Columbus Niehus
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.)
Cummins Inc
Original Assignee
Cummins Inc
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
Priority claimed from US10/082,196 external-priority patent/US7778750B2/en
Application filed by Cummins Inc filed Critical Cummins Inc
Publication of DE10392279T5 publication Critical patent/DE10392279T5/de
Application granted granted Critical
Publication of DE10392279B4 publication Critical patent/DE10392279B4/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/03—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for
    • B60R16/0315—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for supply of electrical power to vehicle subsystems or for using multiplexing techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/40006—Architecture of a communication node
    • H04L12/40013—Details regarding a bus controller
    • 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/403—Bus networks with centralised control, e.g. polling
    • 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/46—Interconnection of networks
    • 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/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • 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/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • 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
    • 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
    • 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/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/303—Terminal profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Automation & Control Theory (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)
  • Information Transfer Systems (AREA)
  • Bus Control (AREA)
  • Selective Calling Equipment (AREA)

Abstract

Adapter zum Ermöglichen einer Kommunikation zwischen einem mit einem Fahrzeugkommunikationsnetz gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei der Adapter umfasst:
– eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem Fahrzeugkommunikationsnetz ausgelegt ist, und
– eine zweite Schnittstelle, welche Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist,
wobei der Fahrzeugsteuercomputer und der entfernte Computer über das Fahrzeugkommunikationsnetz und die erste und die zweite Schnittstelle kommunizieren.

Description

  • Querverweis auf eine verwandte Anmeldung
  • Dies ist eine Teilfortsetzung der gleichzeitig anhängigen US-Anmeldung mit der Seriennummer 10/082,196, die am 25. Februar 2002 eingereicht wurde und den Titel FAHRZEUGKOMMUNIKATIONSNETZADAPTER trägt.
  • Fachgebiet der Erfindung
  • Die vorliegende Erfindung betrifft allgemein Informationskommunikationssysteme und im Speziellen eine Kommunikationsbrücke, um den Informationsaustausch zwischen einem oder mehreren Fahrzeuginformationsnetzen und einem oder mehreren Fernsystemen zu besorgen, wobei die Kommunikationsprotokolle des einen oder der mehreren Fahrzeuginformationsnetze von denen des einen oder der mehreren Fernsysteme verschieden sind.
  • Hintergrund der Erfindung
  • Kraftfahrzeuge weisen verschiedene elektronische Steuercomputer auf, die in das Fahrzeug eingebaut sind. Die Steuercomputer können verschiedene Systeme und/oder Subsysteme in dem Fahrzeug steuern. Beispielsweise kann ein Steuercomputer das Kraftstoffsystem, das Getriebe, die Bremsen oder den Lenkmechanismus steuern. Diese Steuercomputer sind typischerweise mit einer Vielzahl von Sensoren und/oder Aktoren gekoppelt. In Nutzfahrzeugen sind oftmals Steuercomputer vorgesehen, die Daten protokollieren, welche die Nutzung des Fahrzeugs betreffen, etwa die Maximalgeschwindigkeit, den Kraftstoffverbrauch, die maximale Beschleunigung, die Einsatzstunden und dergleichen. Solche Systeme können sogar einen GPS-Empfänger (GPS = Global Positioning System) enthalten, um zu protokollieren, wo das Fahrzeug gefahren ist.
  • Diese Steuercomputer kommunizieren miteinander und mit externen Servicegeräten über ein oder mehrere Fahrzeugkommunikationsnetze. Es wurden Standards für Fahrzeugkommunikationsnetzprotokolle entwickelt, die in der Fachwelt wohlbekannt sind. Beispielsweise hat die Society of Automotive Engineers (SAE) Standards entwickelt, die die Auslegung und den Gebrauch von Geräten betreffen, welche elektronische Signale und Steuerinformationen zwischen Fahrzeugkomponenten übertragen.
  • Einige dieser Standards sind SAE J1939, SAE J1850 und SAE J1587/J1708 (SAE J1708 ist eine spezielle Ausführung einer RS-485-Kommunikationshardwarestruktur, wobei die Kommunikation über eine J1708-Struktur nach einem durch SAE J1587 festgelegten Kommunikationsprotokoll erfolgen kann, wie in der Fachwelt bekannt ist). Weitere Standards wurden von anderen Organisationen entwickelt, wie etwa ISO-9141, der von der International Standards Organization entwickelt wurde.
  • Servicegeräte wurden in der Vergangenheit benutzt, um Probleme mit Steuercomputern zu diagnostizieren, Informationen herunterzuladen, die von Steuercomputern protokolliert bzw. gesammelt wurden, und Informationen auf Steuercomputer zu laden. Beispielsweise kann ein Steuercomputer die Maximalgeschwindigkeit oder das maximale Drehmoment des Fahrzeugs begrenzen, wobei dieser maximale Wert mittels eines computerbasierten Servicewerkzeugs programmierbar sein kann. Bei einigen Fahrzeugen kann eine ganze Gruppe von Parametern, sogar das Kraftstoffkennfeld, durch Servicegeräte modifiziert werden.
  • Servicegeräte können allgemein in handtragbare oder stationäre Geräte eingeteilt werden, die dazu verwendet werden, Informationen zu einem oder mehreren von einem Kraftfahrzeug mitgeführten Steuercomputern zu übertragen oder von diesen entgegenzunehmen. Ein handtragbares Servicegerät wird oftmals als „Servicewerkzeug" bezeichnet und kann unter anderem zur Untersuchung von Fehlern eingesetzt werden, die mit bordseitigen Steuercomputern zusammenhängen. Ein typisches Servicewerkzeug umfasst eine zentrale Verarbeitungseinheit (cpu) sowie eine spezielle Schnittstellenschaltung, um die Kommunikation zwischen der cpu und den ein oder mehreren Steuercomputern im Fahrzeug zu erleichtern. Viele Servicewerkzeuge sind „speziell" hergestellt, wobei sie dazu ausgelegt sind, nur mit einem oder mehreren der von einem bestimmten Hersteller hergestellten Steuercomputer zusammenzuwirken und oftmals nur mit bestimmten Modellen, die von einem bestimmten Hersteller hergestellt werden.
  • Stationäre Servicegeräte werden allgemein zur Gewinnung von Datenaufzeichnungen und andere kompliziertere Aufgaben verwendet, wenngleich handtragbare und stationäre Servicegeräte für viele Zwecke wechselseitig austauschbar sein können. Jüngste Entwicklungen bei stationären Servicegeräten haben Personalcomputer (PCs) implementiert. Gegenwärtige Methoden, um einen oder mehrere Fahrzeugsteuercomputer an einen Personalcomputer (PC) anzukoppeln, erfordern speziell angefertigte, cpu-basierte Schnittstellen, welche die Kommunikationsprotokolle des einen oder der mehreren Fahrzeugsteuercomputer (d.h. SAE J1939 und/oder SAE J1587/J1708) in einen PC-Kommunikationsstandard übersetzen, wie etwa RS-232 (standardmäßig seriell) oder PCI (Peripheral Computer Interface). Diese speziellen Schnittstellenadapter weisen typischerweise eine in den PC eingebaute PCI-Schnittstellenkarte oder eine externe „Baugruppe" auf, die zwischen den einen oder die mehreren Fahrzeugsteuercomputer und den PC geschaltet ist.
  • Viele Hersteller vertreiben heutzutage handtragbare Computer für fahrzeugfremde Anwendungen. Beispielsweise ist ein persönlicher digitaler Assistent (PDA) ein handtragbarer, stiftbasierter Computer, der die Funktionalität eines persönlichen Informationsmanagers (PIM), wie etwa eines Kalenders und eines Adressbuchs, mit Rechenmerkmalen vereinigt. Die meisten PDAs sind zur Kommunikation mit einem „Host"-Computer, allgemein einem Personalcomputer (PC), über entweder einen seriellen RS-232-Port oder einen USB- (Universal Serial Bus) Port ausgelegt.
  • Derartige handtragbare Computersysteme können als Gerät verwendet werden, um bei der Gewinnung, der Anzeige und dem Laden von Motor-/Fahrzeuginformationen für die Übertragung und Analyse zu helfen. Ein derartiges System ist in der US-Patentanmeldung 09/583,892 beschrieben, die den Titel „Handheld computer based system for collection, display, and analysis of engine/vehicle data" trägt, auf die Inhaberin der vorliegenden Erfindung übertragen ist und deren Offenbarung durch Verweis hier einbezogen wird.
  • Sowohl PDAs als auch PCs umfassen üblicherweise USB-Ports oder können hiermit nachgerüstet werden. USB-Ports sind aus einer Anzahl von Gründen wesentlich vielseitiger als standardmäßige serielle Ports. Beispielsweise sind standardmäßige serielle Ports „Punkt-zu-Punkt", sodass lediglich zwei Geräte zur Kommunikation über eine standardmäßige serielle Verbindung zusammengeschaltet werden können. Dagegen stellt USB eine serielle Mehrpunktverbindung bereit, sodass mehrere Computer über eine Datenverbindung zur Kommunikation zusammengeschaltet werden können. Als weiteres Beispiel sind standardmäßige serielle Ports wesentlich langsamer als USB-Ports. Die maximal erreichbare Geschwindigkeit eines standardmäßigen seriellen Ports liegt gegenwärtig im Bereich von 115 kB/s. Im Unterschied hierzu ist Hochgeschwindigkeits-USB über vierhundertmal schneller und erreicht Übertragungsraten von 480 MB/s und Vollgeschwindigkeits-USB ist hundertmal schneller und erreicht Datenraten von 12 MB/s.
  • Allerdings muss ein an eine serielle USB-Mehrpunktverbindung angeschlossener Computer entweder als „Gerät" oder als „Host" konfiguriert sein. Viele Geräte können an einen Host angeschlossen werden. Allerdings können bei einer Verbindung keine zwei Hosts direkt miteinander verbunden sein; auch können zwei Geräte nicht direkt miteinander verbunden sein. Einige Computer enthalten einen On-The-Go- (OTG) USB-Port, der es ihnen erlaubt, abhängig von der Art des in den Port eingesteckten Kabels als Gerät oder als funktionsbegrenzter Host zu dienen. Computer mit einem On-The-Go-USB-Port können stets mit einem Host verbunden werden (das heißt als Gerät dienen) oder sie können auch mit einem Gerät verbunden werden (das heißt als Host dienen), wenn das Gerät eines ist, das der mit dem On-The-Go-USB-Port ausgerüstete Computer unterstützen kann. Darüber hinaus umfassen einige USB-Controller einen einzelnen Port, der dynamisch als Gerät, Host oder OTG-Port konfigurierbar ist, sodass nur ein einzelner Port benötigt wird, um jede der USB-Konfigurationen zu unterstützen.
  • Es existieren auch „Taschen-PCs" mit USB-Hostfähigkeit sowie PCs, PDAs und anderen computerisierte Geräte mit USB-On-The-Go-Fähigkeit. Jedes USB-Rechengerät (PC, PDA, Taschen-PC usw.) kann jede Kombination von USB-Host-, Geräte- oder On-The-Go-Ports aufweisen. Nichts in dieser Offenbarung beabsichtigt, auf eine Beschränkung der möglichen USB-Kombinationen hinzuweisen, die bei einem gegebenen Typ von Computer vorliegen können.
  • Das USB-Protokoll ist in der „Universal Serial Bus Specification", Überarbeitung 2.0, 27. April 2000, in „Errata to the USB 2.0 Specification", 7. Dezember 2000, und in "On-The-Go Supplement to the USB 2.0 Specification", Überarbeitung 1.0, 18. Dezember 2001, beschrieben, die alle drei hiermit durch Verweis einbezogen werden.
  • Es ist wünschenswert, eine Kommunikationsbrücke bereitzustellen, die dazu ausgelegt ist, ein oder mehrere Motor-/Fahrzeugdatenverbindungskommunikationsprotokolle (z.B. J1939, J1587/J1708 usw.) auf ein oder mehrere Kommunikationsprotokolle für computerbasierte Fernsysteme oder -einheiten (z.B. RS-232, USB usw.) umzuwandeln, um die Kommunikation zwischen einem von einem Kraftfahrzeug mitgeführten Steuercomputer und einem computerbasierten Fernsystem oder einer Ferneinheit zu erleichtern. Durch Experimente hat es sich jedoch herausgestellt, dass mikroprozessorbasierte Kommunikationsbrücken dieses Typs an einer Anzahl von Nachteilen leiden. Beispielsweise erleben mikroprozessorbasierter Kommunikationsbrücken aufgrund der Mehrbefehlszyklus-Natur und dem beschränkten Arbeitsdurchsatz typischer mikroprozessorbasierter Architekturen oftmals Fehler oder Ausfälle, wenn sie versuchen, Mehrrahmen-Datennachrichten umzuwandeln und zu übertra gen. Wenn dies geschieht, wird die umgewandelte und gesendete Nachricht verworfen und muss daher erneut gesendet werden.
  • Was daher benötigt wird, ist eine Kommunikationsbrücke, die dazu ausgelegt ist, ein oder mehrere Motor-/Fahrzeugdatenverbindungs-Kommunikationsprotokolle (z.B. J1939, J1587/J1708 usw.) auf ein oder mehrere Kommunikationsprotokolle für computerbasierte Fernsysteme oder Ferneinheiten (z.B. RS-232, USB usw.) umzuwandeln, die aber nicht an den vorstehenden Nachteilen leidet.
  • Abriss der Erfindung
  • Nach einem Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen einem mit einem Fahrzeugkommunikationsnetz gekoppelten Fahrzeugsteuercomputer und einen entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem Fahrzeugkommunikationsnetz ausgelegt ist, eine zweite Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einen USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist. Der Fahrzeugsteuercomputer und der entfernte Computer kommunizieren über das Fahrzeugkommunikationsnetz und die erste und die zweite Schnittstelle.
  • Gemäß diesem Gesichtspunkt der Erfindung kann der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der persönliche digitale Assistent Servicewerkzeugsoftware umfassen. Gemäß diesem Gesichtspunkt der Erfindung kann der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann bei diesem Gesichtspunkt der Erfindung der Personalcomputer Fahrzeugdiagnosesoftware umfassen.
  • Alternativ kann der USB-Hostport des Controllers für den universellen seriellen Bus bei diesem Gesichtspunkt der Erfindung zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt sein, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung mindestens einer der Mehrzahl von entfernten Computern Fahrzeugdiagnosesoftware umfassen.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung das Fahrzeugkommunikationsnetz ein J1939-Netzsegment umfassen, wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1939-Netzsegment gekoppelt ist.
  • Ferner können gemäß diesem Gesichtspunkt der Erfindung Nachrichten, die über das J1939-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist und wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung das Fahrzeugkommunikationsnetz ein J1587-Netzsegment umfassen, wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1587-Netzsegment gekoppelt ist.
  • Ferner können gemäß diesem Gesichtspunkt der Erfindung Nachrichten, die über das J1587-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1587-Netzsegement kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der Adapter ferner eine dritte Schnittstelle umfassen, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port sein, wobei der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der persönliche digitale Assistent Servicewerkzeugsoftware umfassen.
  • Gemäß diesem Gesichtspunkt der Erfindung kann der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port sein, wobei der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der Personalcomputer Fahrzeugdiagnosesoftware umfassen.
  • Gemäß diesem Gesichtspunkt der Erfindung kann der Controller für den universellen seriellen Bus einen USB-On-The-Go-Port umfassen.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer einen persönlichen digitalen Assistenten mit einem USB-Geräteport umfassen, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Nach einem weiteren Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen einem mit einem J1939-Netz eines Fahrzeuges gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem J1939-Netz gekoppelt ist, sowie eine zweite Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport gekoppelt ist. Der Fahrzeugsteuercomputer und der entfernte Computer kommunizieren über das J1939-Netz und die erste und die zweite Schnittstelle.
  • Gemäß diesem Gesichtspunkt der Erfindung kann der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt sein, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der Adapter ferner eine dritte Schnittstelle umfassen, welche zur betriebsmäßigen Kopplung mit einem Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der Controller für den universellen seriellen Bus ferner einen USB-On-The-Go-Port umfassen.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Nach einem weiteren Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen einem mit einem J1587-Netz eines Fahrzeugs gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem J1587-Netz ausgelegt ist, sowie eine zweite Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einen USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist. Der Fahrzeugsteuercomputer und der entfernte Computer kommunizieren über das J1587-Netz und die erste und die zweite Schnittstelle.
  • Gemäß diesem Aspekt der Erfindung kann der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt sein, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der Adapter ferner eine dritte Schnittstelle umfassen, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der Controller für den universellen seriellen Bus ferner einen USB-On-The-Go-Port umfassen.
  • Ferner kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Nach einem weiteren Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen Steuercomputern eines Fahrzeugs und einem entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1939-Netzsegment des Fahrzeugs ausgelegt ist, eine zweite Schnittstelle, welche zur betriebsmäßigen Kopplung mit einen J1587-Netzsegment des Fahrzeugs ausgelegt ist, sowie eine dritte Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst. Die dritte Schnittstelle ist zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt. Jeder Steuercomputer des Fahrzeugs und der entfernte Computer kommunizieren über das J1939-Netz und die erste sowie die dritte Schnittstelle oder über das J1587-Netz und die zweite sowie die dritte Schnittstelle.
  • Gemäß diesem Gesichtspunkt der Erfindung kann der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB- Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt sein, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  • Alternativ kann gemäß diesem Gesichtspunkt der Erfindung der Controller für den universellen seriellen Bus einen USB-On-The-Go-Port umfassen.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Nach einem weiteren Gesichtpunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen einem betriebsmäßig mit einem Kommunikationsnetz eines Fahrzeugs gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer zu ermöglichen. Das Verfahren umfasst das Empfangen von Daten über eine erste Schnittstelle, wobei die erste Schnittstelle betriebsmäßig mit dem Kommunikationsnetz des Fahrzeugs gekoppelt ist, das Übertragen der Daten über eine zweite Schnittstelle, wobei die zweite Schnittstelle einen Controller für einen universellen seriellen Bus mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit einem Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist. Die ersten Daten werden von dem Fahrzeugsteuercomputer übertragen und die ersten Daten werden seitens des entfernten Computers empfangen.
  • Nach diesem Gesichtspunkt der Erfindung können die Daten eine Netznachricht sein, wobei die Netznachricht eine Zieladresse umfasst.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der Übertragungsschritt das Ermitteln umfassen, ob die Netznachricht für die zweite Schnittstelle bestimmt ist, sowie das Übertragen der Netznachricht über eine zweite Schnittstelle nur dann, wenn die Netznachricht für die zweite Schnittstelle bestimmt ist.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung das Ermitteln, ob die Netznachricht für die zweite Schnittstelle bestimmt ist, das Lesen der Adresse und das Vergleichen derselben mit einer existierenden Adresse umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der Übertragungsschritt das Übertragen der Netznachricht über eine zweite Schnittstelle ungeachtet der Zieladresse der Netznachricht umfassen.
  • Nach einem weiteren Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen einem betriebsmäßig mit einem Fahrzeugkommunikationsnetz gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem Fahrzeugkommunikationsnetz ausgelegt ist, sowie eine zweite Schnittstelle, welche einen USB-On-The-Go-Port umfasst. Die zweite Schnittstelle ist zur betriebsmäßigen Kopplung mit den entfernten Computer über den USB-On-The-Go-Port ausgelegt. Der Fahrzeugsteuercomputer und der entfernte Computer kommunizieren über das Fahrzeugkommunikationsnetz und die erste sowie die zweite Schnittstelle.
  • Nach diesem Gesichtspunkt der Erfindung kann der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der persönliche digitale Assistent Servicewerkzeugsoftware umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Perso nalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der Personalcomputer Fahrzeugdiagnosesoftware umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung das Fahrzeugkommunikationsnetz ein J1939-Netzsegment umfassen, wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1939-Netzsegment gekoppelt ist.
  • Ferner können nach diesem Gesichtspunkt der Erfindung Nachrichten, die über das J1939-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit den USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung das Fahrzeugkommunikationsnetz ein J1587-Netzsegment umfassen und die erste Schnittstelle des Adapters betriebsmäßig mit dem J1587-Netzsegement gekoppelt sein.
  • Ferner können nach diesem Gesichtspunkt der Erfindung Nachrichten, die über das J1587-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB- Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist und Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der Adapter ferner eine dritte Schnittstelle umfassen, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port sein und der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt sein.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der persönliche digitale Assistent Servicewerkzeugsoftware umfassen.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port sein und der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt sein.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der Personalcomputer Fahrzeugdiagnosesoftware umfassen.
  • Nach einem weiteren Gesichtspunkt der Erfindung ist ein Adapter vorgesehen, um eine Kommunikation zwischen Steuercomputern eines Fahrzeugs und einem entfernten Computer zu ermöglichen. Der Adapter umfasst eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1939-Netzsegment des Fahrzeugs ausgelegt ist, eine zweite Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1587-Netzsegment des Fahrzeugs ausgelegt ist, sowie eine dritte Schnittstelle, welcher einen USB-On-The-Go-Port umfasst, wobei die dritte Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-On-The-Go-Port ausgelegt ist. Jeder Steuercomputer des Fahrzeugs und der entfernte Computer kommunizieren über das J1939-Netz und die erste sowie die dritte Schnittstelle oder über das J1587-Netz und die zweite sowie die dritte Schnittstelle.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent oder ein Personalcomputer mit einem USB-On-The-Go-Port sein, wobei der USB-On-The-Go-Port des entfernten Computers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport sein, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer ein Personalcomputer mit einem USB-Hostport sein, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer Servicewerkzeugsoftware umfassen.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer Fahrzeugdiagnosesoftware umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der Adapter ferner eine vierte Schnittstelle umfassen, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die vierte Schnittstelle einen seriellen RS-232-Port umfasst.
  • Ferner kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port sein, wobei der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port sein, wobei der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer Servicewerkzeugsoftware umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der zweite entfernte Computer Fahrzeugdiagnosesoftware umfassen.
  • Alternativ kann nach diesem Gesichtspunkt der Erfindung der entfernte Computer der zweite entfernte Computer sein.
  • Die vorliegende Erfindung kann ferner eines oder mehrere der folgenden Merkmale oder Kombinationen hiervon umfassen. Eine Kommunikationsbrücke zwischen einem von einem Kraftfahrzeug mitgeführten und zur Kommunikation nach einem ersten Protokoll ausgelegten Kommunikationsnetz und einem zur Kommunikation nach einem zweiten Protokoll ausgelegten Fernsystem kann eine erste Schnittstelle umfassen, welche zur Kopplung mit dem Kommunikationsnetz ausgelegt ist, eine zweite Schnittstelle, welche zur Kopplung mit dem Fernsystem ausgelegt ist, sowie einen digitalen Signalprozessor (DSP), welcher zur Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist. Der DSP kann von dem Kommunikationsnetz über die erste Schnittstelle nach dem ersten Protokoll konfigurierte Informationen empfangen, die von dem Kommunikationsnetz empfangenen und nach dem ersten Protokoll konfigurierten Informationen auf das zweite Protokoll umwandeln und die auf das zweite Protokoll umgewandelten Informationen über die zweite Schnittstelle zu dem Fernsystem übertragen. Der DSP kann ferner von dem Fernsystem über die zweite Schnittstelle nach dem zweiten Protokoll konfigurierte Informationen empfangen, die von dem Fernsystem empfangenen und nach dem zweiten Protokoll konfigurierten Informationen auf das erste Protokoll umwandeln und die auf das erste Protokoll umgewandelten Informationen über die erste Schnittstelle zu dem Kommunikationsnetz übertragen.
  • Die Kommunikation kann ferner einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem Kommunikationsnetz stehenden Steuercomputer beinhalten, wobei der Steuercomputer die nach dem ersten Protokoll konfigurierten Informationen an das Kommunikationsnetz liefert.
  • Das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz kann ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) sein, wobei das erste Protokoll ein für die Kommunikation über das SAE J1708-Hardwarenetz ausgelegter SAE J1587-Kommunikationsprotokoll ist. Die erste Schnittstelle kann ein erster Transceiver sein, der zur Kopplung mit dem SAE J1708-Hardwarenetz ausgelegt ist, wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1587-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1708-Hardwarenetz zu übertragen und von diesem zu empfangen. Das Kommunikationsnetz kann ferner einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem SAE J1708-Hardwarenetz stehenden Steuercomputer umfassen, wobei der Steuercomputer die nach dem J1587-Protokoll konfigurierten Informationen an das SAE J1708-Hardwarenetz liefert. Das zweite Protokoll kann bei dieser Ausführungsform ein RS-232-Kommunikationsprotokoll sein und die zweite Schnittstelle kann ein zweiter Transceiver sein, der zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist, wobei der zweite Transceiver dazu betreibbar ist, die nach dem RS-232-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Alternativ kann das zweite Protokoll ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) sein, wobei die zweite Schnittstelle ein USB-Controller mit einem ersten USB-Schnittstellenport sein kann, der zur Kopplung mit einem zweiten USB-Schnittstellenport des Fernsystems ausgelegt ist, wobei der USB-Controller dazu betreibbar ist, die nach dem USB-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Das Fernsystem kann als USB-Gerät konfiguriert sein, wobei der erste USB-Schnittstellenport als USB-Hostport oder On-The-Go-USB-Port konfiguriert ist, welcher als Host-USB-Port betreibbar ist. Das Fernsystem kann alternativ als USB-Host konfiguriert sein, wobei der erste USB-Schnittstellenport als USB-Geräteport oder als On-The-Go-USB-Port konfiguriert ist, welcher als Geräte-USB-Port betreibbar ist. In jedem Fall kann das Fernsystem ein Personalcomputer, ein handtragbares persönliches digitales Assistenzgerät oder ein anderes Fernsystem oder eine Ferneinheit sein.
  • Das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz kann alternativ ein J1939-Hardwarenetz der Society of Automotive Engineers (SAE) sein, wobei das erste Protokoll ein für die Kommunikation über das SAE J1939-Hardwarenetz ausgelegtes SAE J1939-Kommunikationsprotokoll ist. Die erste Schnittstelle kann ein Transceiver sein, der zur Kopplung mit dem SAE J1939-Hardwarenetz ausgelegt ist, wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1939- Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1939-Hardwarenetz zu übertragen und von diesem zu empfangen. Das Kommunikationsnetz kann ferner einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem SAE J1939-Hardwarenetz stehenden Steuercomputer umfassen, wobei der Steuercomputer die nach dem SAE J1939-Protokoll konfigurierten Informationen an das SAE J1939-Hardwarenetz liefert. Bei dieser Ausführungsform kann das zweite Protokoll ein RS-232-Kommunikationsprotokoll sein, wobei die zweite Schnittstelle ein zweiter Transceiver sein kann, der zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist, wobei der zweite Transceiver dazu betreibbar ist, die nach dem RS-232-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Das zweite Protokoll kann alternativ ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) sein, wobei die zweite Schnittstelle ein USB-Controller mit einem ersten USB-Schnittstellenport sein kann, welcher zur Kopplung mit einem zweiten USB-Schnittstellenport des Fernsystems ausgelegt ist, wobei der USB-Controller dazu betreibbar ist, die nach dem USB-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Das Fernsystem kann als USB-Gerät konfiguriert sein, wobei der erste USB-Schnittstellenport als USB-Hostport oder als On-The-Go-USB-Port konfiguriert ist, welcher als Host-USB-Port betreibbar ist. Alternativ kann das Fernsystem als USB-Host konfiguriert sein, wobei der erste USB-Schnittstellenport als USB-Geräteport oder als On-The-Go-USB-Port konfiguriert ist, welcher als Geräte-USB-Port betreibbar ist. In jedem Fall kann das Fernsystem ein Personalcomputer, ein handtragbares persönliches digitales Assistenzgerät oder ein anderes Fernsystem oder eine Ferneinheit sein.
  • Die Kommunikationsbrücke kann ferner eine Energieversorgung umfassen, welche dazu ausgelegt ist, eine erste Versorgungsspannung an den ersten Transceiver zu liefern.
  • Die Kommunikationsbrücke kann ferner eine Energiequellenwählschaltung umfassen, welche eine oder mehrere Quellenspannungen erhält und der Energieversorgung selektiv eine der einen oder mehreren Quellenspannungen als Eingangsspannung zuführt, wobei die Energieversorgung die erste Versorgungsspannung als Funktion der Eingangsspannung erzeugt. Die Energieversorgung kann ferner dazu ausgelegt sein, eine zweite Versorgungsspannung als Funktion der Eingangsspannung an den DSP und an den zweiten Transceiver zu liefern, wobei die zweite Versorgungsspannung kleiner als die erste Versorgungsspannung ist. Der DSP kann ferner einen pro grammierbaren Flash-Speicher umfassen, wobei die Energieversorgung ferner dazu ausgelegt sein kann, eine Flash-Speicher-Programmierspannung als Funktion der Eingangsspannung an den DSP zu liefern.
  • Die eine oder die mehreren Quellenspannungen können eine der Kommunikationsbrücke über eine externe Spannungsquelle zugeführte Gleichspannung umfassen.
  • Die Kommunikationsbrücke kann ferner mindestens eine Batterie umfassen, welche eine Batteriespannung liefert, wobei die eine oder die mehreren Quellenspannungen die von der Batterie gelieferte Batteriespannung umfassen können.
  • Die Kommunikationsbrücke kann ferner ein Ladegerät zum Laden externer Batterien umfassen, wobei das Ladegerät eine von der Energieversorgung erzeugte Ladespannung erhält und die Ladespannung nach außerhalb der Kommunikationsbrücke liefert. Das Fernsystem kann ein persönliches digitales Assistenz- (PDA) Gerät sein, wobei die von der Ladeschaltung zum Laden externer Batterien erzeugte Ladespannung dem PDA zugeführt werden kann, um eine oder mehrere von demselben mitgeführte Batterien zu laden. Der DSP kann einen Spannungsmesseingang umfassen, welcher die von der Energieversorgung erzeugte Ladespannung überwacht, wobei der DSP die Ladespannung misst und einen resultierenden Messspannungswert mittels einer von dem zweiten Transceiver übertragenen Diagnosenachricht an den PDA liefert.
  • Der DSP kann einen Spannungsmesseingang umfassen, welcher die der Energiequellenwählschaltung zugeführte externe Quellenspannung überwacht.
  • Die Kommunikationsbrücke kann ferner einen Energieversorgungsstatusanzeiger sowie eine Treiberschaltung umfassen, welche einen mit einem Steuerausgang des DSP verbundenen Steuereingang sowie einen mit dem Energieversorgungsstatusanzeiger verbundenen Treiberausgang aufweist, wobei der DSP dazu betreibbar ist, den Energieversorgungsstatusanzeiger über die Treiberschaltung zu steuern, um eine Sichtanzeige des gemessenen Werts der externen Quellenspannung zu liefern. Der Energieversorgungsstatusanzeiger kann eine lichtemittierende Energieversorgungsstatusdiode (LED) sein, wobei der DSP die Energieversorgungsstatus-LED über die Treiberschaltung derart steuert, dass die Energieversorgungsstatus-LED leuchtet, wenn der gemessene Wert der externen Quellenspannung innerhalb eines vorbestimmten Spannungsbereichs liegt, und in einen ausgeschalteten Zustand eingestellt ist, wenn der gemessene Wert der externen Quellenspannung unter einem Schwel lenspannungswert liegt, der kleiner als der vorbestimmte Spannungsbereich ist. Der DSP kann ferner dazu betreibbar sein, die Energieversorgungsstatus-LED über die Treiberschaltung derart zu steuern, dass die Energieversorgungsstatus-LED mit einer vorbestimmten Wechselrate ein- und ausgeschaltet wird, wenn der gemessene Wert der externen Quellenspannung außerhalb des vorbestimmten Spannungsbereichs liegt.
  • Die Kommunikationsbrücke kann ferner einen weiteren Statusanzeiger sowie eine Treiberschaltung umfassen, welche einen mit einem Steuerausgang des DSP verbundenen Steuereingang und einen mit dem Statusanzeiger verbundenen Treiberausgang aufweist, wobei der DSP dazu betreibbar ist, den Statusanzeiger über die Treiberschaltung zu steuern, um eine Sichtanzeige des Status der Informationsübertragung zwischen dem Kommunikationsnetz und dem Fernsystem zu liefern.
  • Das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz kann ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) sein, wobei das erste Protokoll ein für die Kommunikation über das SAE J1708-Hardwarenetz ausgelegtes SAE J1587-Komunikationsprotokoll ist, wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1587-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1708-Hardwarenetz zu übertragen und von diesem zu empfangen. Der Statusanzeiger kann in diesem Fall eine lichtemittierende J1587/J1708-Kommunikationsstatusdiode (LED) sein, wobei der DSP die J1587/J1708-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn das J1708-Hardwarenetz nicht anspricht und der DSP Daten über den ersten Transceiver überträgt, wobei der DSP die J1587/J1708-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn das J1708-Hardwarenetz anspricht und der DSP Informationen über den ersten Transceiver zu dem Kommunikationsnetz überträgt und Informationen von diesem empfängt, und wobei der DSP die J1587/J1708-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den ersten Transceiver zu dem J1708-Hardwarenetz überträgt noch Informationen von diesem empfängt.
  • Das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz kann alternativ ein J1939-Hardwarenetz der Society of Automotive Engineers (SAE) sein oder ein solches einschließen, wobei das erste Protokoll ein für die Kommunikation über das SAE J1939-Hardwarenetz ausgelegtes SAE J1939-Kommunikationsprotokoll ist und wobei der erste Transceiver ein CAN- (Controller Area Network) Transceiver ist, der dazu betreibbar ist, die nach dem SAE J1939-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1939-Hardwarenetz zu übertragen und von diesem zu empfangen. Der Statusanzeiger kann in diesem Fall eine lichtemittierende J1939-Kommunikationsstatusdiode (LED) sein, wobei der DSP die J1939-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn das J1939-Hardwarenetz nicht anspricht und der DSP Daten über den ersten Transceiver überträgt, wobei der DSP die J1939-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn das J1939-Hardwarenetz anspricht und der DSP Informationen über den CAN-Transceiver zu dem Kommunikationsnetz überträgt und Informationen von diesem empfängt, und wobei der DSP die J1939-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den CAN-Transceiver zu dem J1939-Hardwarenetz überträgt noch Informationen von diesem empfängt.
  • Das zweite Protokoll kann ein RS-232-Kommunikationsprotokoll sein, wobei der zweite Transceiver zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist und der zweite Transceiver dazu betreibbar ist, die nach dem RS-232-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Der Statusanzeiger kann in diesem Fall eine lichtemittierende RS-232-Kommunikationsstatusdiode (LED) sein, wobei der DSP die RS-232-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn der RS-232-Kommunikationsport des Fernsystems nicht anspricht und der DSP Daten über den zweiten Transceiver überträgt, wobei der DSP die RS-232-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn der RS-232-Kommunikationsport des Fernsystem anspricht und der DSP Informationen über den zweiten Transceiver zu dem Fernsystem überträgt und Informationen von diesem empfängt, und wobei der DSP die RS-232-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den zweiten Transceiver zu dem Fernsystem überträgt noch Informationen von diesem empfängt.
  • Das zweite Protokoll kann ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) sein, wobei der zweite Transceiver eine USB-Controller- und Transceiverschaltung mit einem ersten USB-Port ist, welcher zur Kopplung mit einem zweiten USB-Port des Fernsystems ausgelegt ist, wobei die USB-Controller- und Transceiverschaltung dazu betreibbar ist, die nach dem USB-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen. Der Statusanzeiger kann in diesem Fall eine lichtemittierende USB-Kommunikationsstatusdiode (LED) sein, wobei der DSP die USB-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn der zweite USB-Port des Fernsystems nicht anspricht und der DSP Daten über die USB-Controller- und Transceiverschaltung überträgt, wobei der DSP die USB-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, welche schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn der zweite USB-Port des Fernsystems anspricht und der DSP Informationen über die USB-Controller- und Transceiverschaltung zu dem Fernsystem überträgt und Informationen von diesem empfängt, und wobei der DSP die USB-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über die USB-Controller- und Transceiverschaltung zu dem Fernsystem überträgt noch Informationen von diesem empfängt.
  • Ein Verfahren zum Kommunizieren von Informationen zwischen mindestens einem von einem Kraftfahrzeug mitgeführten Kommunikationsnetz und einem Fernsystem, wobei das mindestens eine Kommunikationsnetz zur Kommunikation nach einem ersten Protokoll ausgelegt ist und das Fernsystem zur Kommunikation nach einem dritten Protokoll ausgelegt ist, kann die Schritte umfassen: Empfangen eines nach dem ersten Protokoll konfigurierten ersten Datensatzes von dem mindestens ein Kommunikationsnetz über eine mit dem mindestens einen Kommunikationsnetz gekoppelte erste Schnittstelle, Liefern des über die erste Schnittstelle empfangenen ersten Datensatzes an einen digitalen Signalprozessor (DSP), welcher zur Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist, Umwandeln des ersten Datensatzes mit Hilfe des DSP von dem ersten Protokoll auf das zweite Protokoll, Liefern des nach dem zweiten Protokoll konfigurierten ersten Datensatzes von dem DSP an eine mit dem Fernsystem gekoppelte zweite Schnittstelle und Übertragen des nach dem zweiten Protokoll konfigurierten ersten Datensatzes über die zweite Schnittstelle zu dem Fernsystem.
  • Das Verfahren kann ferner die Schritte umfassen: Empfangen eines nach dem zweiten Protokoll konfigurierten zweiten Datensatzes über die zweite Schnittstelle von dem Fernsystem, Liefern des über die zweite Schnittstelle empfangenen zweiten Datensatzes an den digitalen Signalprozessor (DSP), Umwandeln des zweiten Datensatzes mit Hilfe des DSP von dem zweiten Protokoll auf das erste Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, Liefern des nach dem ersten Protokoll konfigurierten zweiten Datensatzes von dem DSP zur ersten Schnittstelle und Übertragen des nach dem ersten Protokoll konfigurierten zweiten Datensatzes über die erste Schnittstelle zu dem mindestens einen Kommunikationsnetz.
  • Das das mindestens eine Kommunikationsnetz mitführende Fahrzeug kann ein weiteres Kommunikationsnetz umfassen, das zur Kommunikation nach einem dritten Protokoll ausgelegt ist, wobei das Verfahren ferner die Schritte umfassen kann: Empfangen eines nach dem dritten Protokoll konfigurierten dritten Datensatzes von dem weiteren Kommunikationsnetz über eine mit dem weiteren Kommunikationsnetz gekoppelte dritte Schnittstelle, Liefern des über die dritte Schnittstelle empfangenen dritten Datensatzes zu dem digitalen Signalprozessor (DSP), Umwandeln des dritten Datensatzes mit Hilfe des DSP von dem dritten Protokoll auf das zweite Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, Liefern des nach dem zweiten Protokoll konfigurierten dritten Datensatzes von dem DSP zu der zweiten Schnittstelle und Übertragen des nach dem zweiten Protokoll konfigurierten dritten Datensatzes über die zweite Schnittstelle zu dem Fernsystem.
  • Das Verfahren kann ferner die Schritte umfassen: Empfangen eines nach dem zweiten Protokoll konfigurierten vierten Datensatzes über die zweite Schnittstelle von dem Fernsystem, Liefern des über die zweite Schnittstelle empfangenen vierten Datensatzes zu dem digitalen Signalprozessor (DSP), Umwandeln des vierten Datensatzes mit Hilfe des DSP von dem zweiten Protokoll auf das dritte Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, Liefern des nach dem dritten Protokoll konfigurierten vierten Datensatzes von dem DSP zu der dritten Schnittstelle und Übertragen des nach dem dritten Protokoll konfigurierten vierten Datenstatzes über die dritte Schnittstelle zu dem weiteren Kommunikationsnetz.
  • Das das mindestens eine Kommunikationsnetz kann ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) sein, wobei das erste Protokoll ein für die Kommunikation über das J1708-Hardwarenetz ausgelegtes SAE J1587-Kommunikationsprotokoll ist, und das weitere Kommunikationsnetz kann ein SAE J1939-Hardwarenetz sein, wobei das dritte Protokoll ein für die Kommunikation über das J1939-Hardwarenetz ausgelegtes SAE J1939-Kommunikationsprotokoll ist.
  • Das zweite Protokoll kann ein RS-232-Kommunikationsprotokoll sein.
  • Das zweite Protokoll kann alternativ ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) sein.
  • Diese und andere Zielsetzungen der Erfindung werden aus der folgenden Beschreibung der beispielhaften Ausführungsformen klarer werden.
  • Kurzbeschreibung der Zeichnungen
  • 1A ist ein Blockdiagramm, das eine bevorzugte Ausführungsform eines Fahrzeugkommunikationsnetzes gemäß der vorliegenden Erfindung darstellt.
  • 1B ist ein Blockdiagramm, das eine andere Ausführungsform eines Fahrzeugkommunikationsnetzes gemäß der vorliegenden Erfindung darstellt.
  • 2 ist ein Blockdiagramm, das eine bevorzugte Ausführungsform eines Fahrzeugkommunikationsnetzadapters gemäß der vorliegenden Erfindung zeigt.
  • 3 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 4 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 5 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 6 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 7 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 8 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 9 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 10 ist ein Ablaufdiagramm, das eine Ausführungsform eines Algorithmus zur Nachrichtenübertragung zwischen einem Fahrzeugkommunikationsnetz und einem Computer gemäß der vorliegenden Erfindung darstellt.
  • 11 ist eine Blockdarstellung einer Ausführungsform eines Kommunikationsnetzes mit einem Kommunikationsbrückensystem, welches den Informationsaustausch zwischen einem oder mehreren Fahrzeuginformationsnetzen und einem oder mehreren Fernsystemen oder Ferneinheiten besorgt.
  • 12 ist eine Blockdarstellung einer Ausführungsform des Kommunikationsbrückensystems der 11.
  • 13 ist eine Blockdarstellung eines Teils des Kommunikationsbrückensystems der 12, wobei eine Ausführungsform der Anzeigeschaltung, der Anzeigetreiberschaltung und von Betriebsspannungsüberwachungsmerkmalen desselben dargestellt ist.
  • 14 ist eine Blockdarstellung eines anderen Teils des Kommunikationsbrückensystems der 12, wobei eine Ausführungsform der Verbindungsschnittstellen zwischen dem DSP und den verschiedenen Kommunikationstransceivern dargestellt ist.
  • 15 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozess zur Informationsübertragung von einem oder mehreren Fahrzeugkommunikationsnetzen zu einem zur Kommunikation gemäß einem ersten Fernsystemprotokoll ausgelegten Fernsystem oder einer Ferneinheit über das Kommunikationsbrückensystem der 11–14 darstellt.
  • 16 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zur Informationsübertragung von dem zur Kommunikation gemäß dem ersten Fernsystemkommunikationssystem ausgelegten Fernsystem über das Kommunikationsbrückensystem der 11–14 zu dem einen oder mehreren Fahrzeugkommunikationsnetzen darstellt.
  • 17 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zur Informationsübertragung von einem oder mehreren Fahrzeugkommunikationsnetzen zu einem zur Kommunikation gemäß einem zweiten Fernsystemprotokoll ausgelegten Fernsystem über das Kommunikationsbrückensystem der 11–14 darstellt.
  • 18 ist ein Ablaufdiagramm, das eine Ausführungsform eines Prozesses zur Informationsübertragung von dem zur Kommunikation nach dem zweiten Fernsystemkommunikationsprotokoll ausgelegten Fernsystem über das Kommunikationsbrückensytem der 11–14 zu dem einen oder den mehreren Fahrzeugkommunikationsnetzen darstellt.
  • Beschreibung der beispielhaften Ausführungsformen
  • Es werden hier beispielhafte Ausführungsformen eines Adapters zur Verwendung mit einem Fahrzeugkommunikationsnetz beschrieben. Ein Fachmann wird verstehen, dass die Vorrichtung auch in Anwendungen und Ausführungsformen nützlich ist, die sich von der folgenden Beschreibung unterscheiden.
  • Bezugnehmend nunmehr allgemein auf 1A ist eine bevorzuge Ausführungsform der vorliegenden Erfindung gezeigt. Ein Fahrzeugsteuersystem 100 umfasst: einen Kraftstoffsystemsteuercomputer 102, einen Getriebesteuercomputer 104, einen Datenprotokolliersteuercomputer 106 sowie ein Fahrzeugkommunikationsnetz 108. Auf dem Fachgebiet Bewanderte werden erkennen, dass das Fahrzeugsteuersystem 100 zu Darstellungszwecken vereinfacht ist und eine Vielzahl weiterer Steuercomputer enthalten kann, etwa einen Antiblockiersystem- (ABS) Controller, einen Zündsystem-Controller und dergleichen. Zwei Serviceelemente, nämlich ein USB-Host 110 und ein USB-Gerät 112, sind gezeigt, die über einen USB-Adapter 200 mit dem Fahrzeugsteuersystem 100 in Kommunikation stehen, wobei der USB-Adapter 200 fern bzw. abseits des Fahrzeugsteuersystems 100 angeordnet ist.
  • Bezugnehmend nunmehr allgemein auf 1B ist eine alternative Ausführungsform der vorliegenden Erfindung gezeigt. Wie in 1B gezeigt, umfasst bei dieser alternativen Ausführungsform das Fahrzeugsteuersystem 100 einen USB-Adapter 200 zusätzlich zu einem Kraftstoffsystemsteuercomputer 102, einem Getriebesteuercomputer 104, einem Datenprotokolliersteuercomputer 106 und einem Fahrzeugkommunikationsnetz 108. Die beiden Serviceelemente, nämlich der USB-Host 110 und das USB-Gerät 112 sind als mit dem Fahrzeugsteuersystem 100 über den USB-Adapter 200 in Kommunikation stehend gezeigt, wobei der USB-Adapter 200 in das Fahrzeugsteuersystem 100 integriert ist. Ein Fachmann wird verstehen, dass die Funktionalität des USB-Adapters 200 unabhängig von dem physikalischen Ort desselben ist.
  • Der Kraftstoffsystemsteuercomputer 102 (auch bekannt als Motorsteuercomputer oder Motorsteuermodul) liefert ein Kraftstoffzufuhrsignal an ein Kraftstoffsystem, welches die in den Zylindern angebotene Kraftstoff/Luft-Mischung reguliert. Wie an sich bekannt, sind solche Daten wie ein Kraftstoffzufuhrkennfeld für den Motor in den Kraftstoffsystemsteuercomputer 102 einprogrammiert. Der Kraftstoffsystemsteuercomputer 102 erhält ein Drehmomentanforderungssignal und verschiedene Daten, die den momentanen Zustand des Fahrzeugs und des Motors betreffen (wie etwa die Motordrehzahl und die Fahrzeuggeschwindigkeit), und nutzt das Kraftstoffzufuhrkennfeld und andere gespeicherte Daten, um das Kraftstoffzufuhrsignal zu berechnen. Etliche Datenelemente sind variabel und können von Anwendung zu Anwendung variieren. Beispielsweise kann der Kraftstoffsystemsteuercomputer 102 Variablen für eine maximale Motordrehzahl und eine maximale Fahrzeuggeschwindigkeit enthalten. Wenn ein bestimmtes Fahrzeug beispielsweise ein Lastwagen ist, kann es die Variable für die maximale Fahrzeuggeschwindigkeit auf 35 Meilen pro Stunde eingestellt haben, wenn es für lokale Lieferfahrten eingesetzt wird, und auf 65 Meilen pro Stunde, wenn es für Langstrecken-Lieferfahrten eingesetzt wird. Als ein weiteres Beispiel ist die Lehrlaufdrehzahl des Motors oftmals eine Variable und kann nach Wunsch eingestellt werden.
  • In ähnlicher Weise liefert der Getriebesteuercomputer 104 ein Schaltsignal an ein Automatikgetriebe, welches das Schalten der Gänge des Getriebes reguliert. Wie an sich bekannt, sind auch in den Getriebesteuercomputer 104 Daten einprogrammiert, wobei er verschiedene Daten, die den momentanen Zustand des Fahrzeugs und des Motors betreffen, erhält und die gespeicherten Daten benutzt, um das Schalten der Gänge zu berechnen. Etliche in den Getriebesteuercomputer 104 einprogrammierte Datenelemente sind auch variabel und können von Anwendung zu Anwendung variieren.
  • Der Datenprotokolliersteuercomputer 106 stellt einen Mechanismus dar, um Informationen zu sammeln bzw. zu protokollieren, die den Betrieb des Fahrzeugs betreffen. Wie an sich bekannt, sind auch in den Datenprotokolliersteuercomputer 106 Daten einprogrammiert, wobei er verschiedene Daten erhält, die den momentanen Zustand des Fahrzeugs betreffen, bei Bedarf Berechnungen durchführt und die Daten speichert. Einige in den Datenprotokolliersteuercomputer 106 einprogrammierte Datenelemente sind ebenfalls variabel und können von Anwendung zu Anwendung variieren. Beispielsweise kann der Datenprotokolliersteuercomputer 106 mit einem fahrzeugseitigen GPS-Empfänger gekoppelt sein und den Ort des Fahrzeugs in vor programmierten Abständen, etwa jede Minute, aufzeichnen. Bei einem anderen Beispiel, bei dem der Datenprotokolliersteuercomputer 106 mit einem fahrzeugseitigen GPS-Empfänger gekoppelt ist, kann er den momentanen Fahrzeugort mit einer „Karte" vergleichen, die zulässige Fahrzeugorte enthält, und nur solche Orte aufzeichnen, die „außerhalb der Grenzen" liegen.
  • Das Fahrzeugkommunikationsnetz 108 ist eine Ansammlung eines oder mehrerer Computernetze, die die Kommunikation zwischen Netzknoten erleichtern. Bei dieser beispielhaften Ausführungsform sind der Kraftstoffsystemsteuercomputer 102, der Getriebesteuercomputer 104, der Datenprotokolliersteuercomputer 106 und der USB-Adapter 200 diejenigen Knoten, zwischen denen Daten kommuniziert werden. Weil der USB-Adapter 200 als „Brücke" wirkt, können auch das (die) USB-Geräte) 112 und der USB-Host 110 als Netzknoten des Fahrzeugkommunikationsnetzes 108 angesehen werden.
  • Der Unterausschuss der Society of Automotive Engineers (SAE) für die Steuerung und Kommunikation bei Lastwagen und Bussen hat eine Familie von Standards entwickelt, die die Ausgestaltung und den Gebrauch von Geräten betreffen, welche elektronische Signale und Steuerinformationen zwischen Fahrzeugkomponenten übertragen. Ein solcher Standard, bekannt als SAE J1939, ist ein akzeptierter Industriestandard für das Kommunikationsnetzdesign bei Schwerlastwagen geworden. Weitere akzeptierte Industriestandards sind die SAE J1587- und J1850-Standards. Diese Standards sind in der Fachwelt bekannt. Bei einer bevorzugten Ausführungsform sind eines oder mehrere Segmente des Fahrzeugkommunikationsnetzes 108 konform mit J1939 und/oder J1587 und/oder J1850. Das Fahrzeugkommunikationsnetz 108 kann jedoch auch andere bekannte Kommunikationsprotokolle unterstützen, wie etwa den ISO-9141-Standard für Diagnoseschnittstellen oder die Standards 2.0A und 2.0B für das Controller Area Network (CAN) von Bosch. Nachrichten, die über das Fahrzeugkommunikationsnetz 108 übertragen werden, werden entweder an einen bestimmten Knoten „adressiert" oder an ein oder mehrere Unternetze „rundfunkartig gesendet". Verfahren zur Nachrichtenübertragung, die mit diesen Protokollen konform sind, sind in der Fachwelt wohlbekannt.
  • Bei einer bevorzugten Ausführungsform erfolgt die Kommunikation nach Maßgabe veröffentlichter empfohlener Praktiken, die in der Fachwelt bekannt sind. Beispielsweise hat The Maintenance Council (TMC) eine standardisierte Schnittstelle für die Fahrzeugcomputerkommunikation und -steuerung etabliert, die in RP1210 „Windows Communication Application Program Interface (API) Version A" des TMC dokumen tiert ist. Diese empfohlene Praktik (RP; Recommended Practice) definiert eine Kommunikations-API (Application Program Interface) zwischen der fahrzeugseitigen Datenverbindung und PC-Anwendungssoftwareprogrammen, die unter der WindowsTM-Familie von Betriebssystemen laufen. Diese RP etabliert eine Standardschnittstelle zwischen der physikalischen Datenverbindung (J1708, CAN/J1939 oder J1850) und WindowsTM-Softwareanwendungen für den Personalcomputer. Bei anderen bevorzugten Ausführungsformen sind andere in der Fachwelt bekannte empfohlene Praktiken implementiert.
  • Der USB-Adapter 200 (der nachfolgend im Detail beschrieben wird) dient als Netzbrücke zwischen dem Fahrzeugkommunikationsnetz 108 und dem USB-Host 110 und dem (den) USB-Geräten) 112. Eine Netzbrücke ist eine Vorrichtung, die es zwei Netzen – selbst solchen, die sich hinsichtlich der Topologie, der Verdrahtung oder den Kommunikationsprotokollen unterscheiden – gestattet, Daten auszutauschen. Das Konzept einer Netzbrücke ist in der Fachwelt wohlbekannt. Der USB-Host 110 kann ein beliebiger Computer mit einem USB-Host-Controller sein, etwa ein standardmäßiger PC. Das (die) USB-Geräte) 112 kann ein beliebiger Computer mit einem USB-Geräte-Controller sein, etwa ein handelsüblich erhältlicher PDA oder auch ein Breitband-Internetmodem (Kabel oder DSL). Gegenwärtig können bis zu 127 USB-Geräte 112 angeschlossen sein, vorausgesetzt, dass die Geräte nicht alle energiemäßig vom USB-Adapter 200 abhängen, und vorausgesetzt, dass die Bandbreitenbeanspruchung unter der Bandbreite des implementierten USB-Standards gehalten wird.
  • Bei einer bevorzugten Ausführungsform kann der USB-Host 110 ein stationäres Servicelement sein, wie etwa ein Motoranalysierer. Bei einer anderen bevorzugten Ausführungsform kann der USB-Host 110 ein Wartungsprotokolliercomputer sein, der Protokollierinformationen vom Datenprotokolliersteuercomputer 106 herunterlädt. Im wesentlichen kann der USB-Host 110 ein beliebiges bekanntes tragbares Servicewerkzeug oder irgendein Computer sein, der dazu ausgebildet ist, mit den Knoten eines Fahrzeugkommunikationsnetzes über eine Schnittstelle zusammenzuarbeiten.
  • In ähnlicher Weise können das USB-Gerät bzw. die USB-Geräte 112 ein beliebiger Computer sein, der dazu ausgelegt ist, mit den Knoten eines Fahrzeugkommunikationsnetzes über eine Schnittstelle zusammenzuarbeiten, etwa ein PDA, der dazu ausgebildet ist, als Servicewerkzeug zu arbeiten. Beispielsweise kann ein standardmäßiger PDA eine Vielzahl von Fahrzeugkonfigurationen enthalten, die auf Fahrzeugsteuercomputer geladen werden können. Dies würde es einem Fahrzeugbe diener ermöglichen, eine aktualisierte Konfigurationsdatei für ein Fahrzeug beispielsweise mittels einer Email vom Fahrzeughersteller zu erhalten, die Konfigurationsdatei auf einen geeignet konfigurierten PDA zu laden und sodann den PDA zu seinem Fahrzeug zu bringen, um das Update zu installieren. Diese Vorgehensweise wäre vorteilhaft für Fahrzeugeigener, die nicht eine vollständige „Arbeitsecke" mit Motorserviceausrüstung besitzen, da es die Notwendigkeit beseitigen würde, einen schweren Desktop- oder Laptop-Computer zum Fahrzeug zu tragen. Es ist allgemein bekannt, dass USB-Kabellängen auf 5 Meter begrenzt sind, sofern nicht ein Repeater verwendet wird.
  • Bezugnehmend nunmehr allgemein auf 2 ist eine bevorzugte Ausführungsform des USB-Adapters 200 gezeigt. Der USB-Adapter 200 umfasst: einen USB-Controller 202, eine zentrale Verarbeitungseinheit (CPU) 204, eine Schnittstellenlogik 206, einen Kristalloszillator 208, Treiber 210 für lichtemittierende Dioden (LED), LEDs 212 einen J1939-Transceiver 214, einen J1587-Transceiver 216, einen optionalen RS-232-Transceiver 218, einen optionalen zusätzlichen Direktzugriffsspeicher (RAM) 220, einen optionalen Festwertspeicher (ROM) 222 sowie eine Energieversorgung (nicht gezeigt).
  • Bei einer bevorzugten Ausführungsform ist der USB-Controller 202 eine handelsüblich erhältliche USB-Host/Gerät-Controller/Transceiverschaltung, wie etwa der von Trans-Dimension, Incorporated aus Irvine, Kalifornien hergestellte Einchip-USB-Host- und Gerätecontroller OTG243 oder der von Royal Philips Electronics aus den Niederlanden hergestellte USB-Host- und Gerätecontroller ISP1362. Eine kundespezifische sehr hoch integrierte (VLSI) Schaltung oder eine andere proprietäre Schaltung mit gesonderten Host- und Gerätecontrollern könnte jedoch ebenfalls verwendet werden, um diese Funktion zu erfüllen. Der USB-Controller 202 stellt das geeignete Schnittstellen- und Nachrichtenprotokoll zur Kommunikation über einen universellen seriellen Bus bereit. Der USB-Controller 202 stellt sowohl einen Host-Downstream-Port (Port 1) als auch einen Gerät-Upstream-Port (Port 2) bereit. Optional kann der USB-Controller 202 einen On-The-Go-USB-Port (Port 3) bereitstellen, welcher abhängig davon, ob ein „mini-A"- oder ein „mini-B"-Stecker in die „mini-AB"-Aufnahme des Ports eingesteckt ist, entweder als Host- oder als Geräteport dient. Bei anderen bevorzugten Ausführungsformen ist der USB-Controller als bordseitige Peripheriekomponente in der CPU 204 implementiert. Bei noch anderen bevorzugten Ausführungsformen ist der USB-Transceiver gesondert von dem USB-Controller.
  • Ein On-The-Go-USB-Port stellt die volle Funktionalität als USB-Gerät und eine begrenzte Funktionalität als USB-Host bereit. Die primär vorgesehene Verwendung eines USB-On-The-Go-Ports ist es, zwei ähnlichen Geräten, etwa zwei PDAs, eine direkte Kommunikation miteinander sowie mit nur einem Host zu ermöglichen. Damit dies geschehen kann, muss wesentlich eines der „Geräte" in einer Gerät-zu-Gerät-Verbindung zeitweilig als Host dienen. Es kann bei einigen Ausführungsformen erwünscht sein, eine Geräte- und Host-Funktionalität nur mit einem einzigen USB-On-The-Go-Port (Port 3) zu implementieren. Ein Fachmann wird verstehen, dass die Verwendung eines einzigen USB-On-The-Go-Ports bei einigen Ausführungsformen erwünscht sein kann, dass die Verwendung diskreter Host- und Geräte-Ports bei einigen anderen Ausführungsformen erwünscht sein kann und dass die Verwendung diskreter Host- und Geräte-Ports in Verbindung mit einem On-The-Go-Port bei noch weiteren Ausführungsformen erwünscht sein kann. Ein Fachmann wird auch verstehen, dass keine dieser Ausführungsformen vom Umfang der hier offenbarten Erfindung abweicht.
  • Jeder USB-Port weist eine geeignete USB-Aufnahme auf, die Vbus- und GND-Anschlüsse für Energie, positive Datenanschlüsse (D+) und negative Datenanschlüsse (D–) für Daten, einen ID-Anschluss für den Fall, dass es eine On-The-Go-Funktionalität gibt (nicht gezeigt), sowie einen Abschirmanschluss (nicht gezeigt) umfasst. Mit jedem Port kann ein USB-Hub verbunden sein, wenngleich für den Host-Port ein selbstversorgter Hub aufgrund von Beschränkungen empfohlen wird, die sich darauf beziehen, wie viel Energie der USB-Controller 202 liefern kann. Enthalten ist auch eine Schutzschaltung, um dauerhafte Schäden an dem Adapter 200 durch gewisse externe Fehlerzustände zu verhindern.
  • Bei einer bevorzugten Ausführungsform umfasst die zentrale Verarbeitungseinheit (CPU) 204 einen Mikrocontroller. Bei anderen Ausführungsformen kann jedoch die CPU 204 einen digitalen Signalprozessor, einen Mikroprozessor oder andere Schaltungen umfassen, die in der Lage sind, Berechnungen auszuführen. Die CPU 204 führt die in einem bordseitigen ROM oder EPROM (nicht gezeigt) oder in einem optionalen entfernt angeordneten ROM oder EPROM 222 gespeicherte Software aus. Der bordseitig oder entfernt angeordnete EPROM-Speicher 222 kann eine Flash-EPROM-, eine EEPROM- oder eine UV-EPROM-Schaltung sein. Die Software stellt ein Mittel zur Ausführung der Adapterfunktion bereit. Bei einer bevorzugten Ausführungsform umfasst die CPU 204 einen bordseitigen Direktzugriffsspeicher (RAM) zur Ausführung der Software, und bei anderen bevorzugten Ausführungsformen umfasst der USB-Adapter 200 einen optionalen bordfernen RAM 220.
  • Die Verwendung eines Flash-EPROM- und eines EEPROM-Speichers für den bordseitigen EPROM der CPU 204 oder für den EPROM 222 erlaubt es, die Software über einen der Kommunikationsports des Adapters 200 zu aktualisieren. Beispielsweise würde ein Softwareupdate auf einen externen Computer geladen werden und dieser Computer würde die aktualisierte Software zum Adapter 200 übermitteln, wobei die CPU 204 einen Aktualisierungsalgorithmus ausführen würde, um die Software in den Flash-EPROM- und den EEPROM-Speicher zu laden.
  • Bei einer bevorzugten Ausführungsform umfasst die CPU 204 einen Kristalloszillatoreingang (XTAL), eine parallele Adress-/Datenbusschnittstelle (A/D-Bus), eine Controller Area Network- (CAN) Schnittstelle, zwei serielle Kommunikationsschnittstellen (Serial 1, Serial 2) sowie digitale Eingabe/Ausgabe-Schnittstellen (I/O). Diese Schnittstellen sind so konfiguriert, dass sie mit anderen Elementen des USB-Adapters 200 wie folgt interoperabel sind.
  • Der Kristalloszillatoreingang (XTAL) der CPU 204 steht in Verbindung mit dem Kristalloszillator 208. Der Kristalloszillator 208 umfasst entweder gesonderte Kristalle oder eine vollständige aktive Oszillatorschaltung, um die erforderlichen Oszillatoreingangstakte für die CPU 204 und den USB-Controller 202 zu liefern. Alternativ kann der Kristalloszillator 208 eine beliebige Taktschaltung sein, die in der Lage ist, die geeigneten Wellenformen zu erzeugen, wie in der Fachwelt bekannt.
  • Die digitalen Eingabe/Ausgabe-Schnittstellen (I/O) der CPU 204 stehen in Verbindung mit den LED-Treibern 210. Die LED-Treiber 210 liefern die notwendige Energie, um die LEDs 212 einzuschalten. Die LEDs 212 zeigen den Betriebsstatus des Adapters 200 sowie den Betriebsstatus jedes der Kommunikationsnetze an. Auch der USB-Controller 202 kann mit den LED-Treibern in Verbindung stehen, um eine Anzeige des Status des universellen seriellen Busses zu liefern, wenngleich die LEDs und deren unterstützende Hardware nicht in sämtlichen Ausführungsformen enthalten sein müssen.
  • Was die LEDs 212 anbelangt, so zeigt bei einer bevorzugten Ausführungsform eine LED an, dass Strom an den USB-Adapter 200 angelegt ist, während andere den Status der Kommunikation über die universellen seriellen Busse, das J1939-Netz, das J1587-Netz und die optionale serielle RS-232-Kommunikationsverbindung nach Electronics Industry Association (EIA) oder Recommended Standards (RS) (auch bekannt als EIA-232) anzeigen.
  • Die CAN-Schnittstelle der CPU 204 steht in Verbindung mit dem J1939-CAN-Transceiver 214. Der Transceiver 214 stellt eine Schnittstelle zwischen dem CAN-Controller in der CPU 204 und der J1939-Datenverbindung des Fahrzeugkommunikationsnetzes 108 bereit. Der Transceiver 214 ist kompatibel mit den Hardwareschnittstellenkonzepten nach SAE J1939 Teil 11 und Teil 15, die in der Fachwelt bekannt sind. Der Transceiver 214 umfasst außerdem eine Schutzschaltung, die durch bestimmte externe Fehlerzustände hervorgerufene dauerhafte Schäden am Adapter 200 verhindert. Bei anderen bevorzugten Ausführungsformen ist der CAN-Controller als von der CPU 204 gesonderte integrierte Schaltung (IC) ausgebildet. Bei dieser Ausführungsform ist die CAN-Controller-IC zwischen dem A/D-Bus oder einem seriellen Bus der CPU 204 und dem CAN-Transceiver 214 angeordnet. Bei noch einer weiteren bevorzugten Ausführungsform ist die Transceiverfunktionalität des CAN-Transceivers 214 in einer gesonderten CAN-Controller-IC integriert, wobei diese einzelne IC mit dem A/D-Bus oder einem seriellen Bus der CPU 204 gekoppelt ist.
  • Eine erste serielle Kommunikationsschnittstelle (Serial 1) der CPU 204 steht mit dem J1587-Transceiver 216 in Verbindung. Der Transceiver 216 ist eine RS-485- (bekannt auch als EIA-485) Transceiverschaltung, die konform mit dem SAE J1708-Hardwareschnittstellenstandard ist, wie in der Fachwelt bekannt ist. Der J1708-Standard basiert auf dem RS-485-Schnittstellenstandard. Weil sowohl der SAE J1587- als auch der SAE J1922-Standard auf der J1708-Schnittstelle basieren, können über den J1587-Transceiver 216 sowohl J1922- als auch J1587-Nachrichten empfangen und übermittelt werden.
  • Der Transceiver 216 stellt die Schnittstelle zwischen einer ersten seriellen Kommunikationsschnittstelle (im übrigen bekannt als universeller asynchroner Empfänger/Sender oder UART bekannt) in der CPU 204 und einer J1708/J1587- und/oder einer J1708/J1922-Datenverbindung des Fahrzeugkommunikationsnetzes 108 bereit. Ein Fachmann wird erkennen, dass der UART herkömmlicher Ausbildung sein kann oder alternativ eine Anzahl von diskreten I/O-Beinen aufweisen kann, die in einem sogenannten „Bit Bang"-Modus verwendet werden, wobei die I/O-Leitungen ein- und ausgeschaltet werden, um den seriellen Datenstrom eines konventionellen UART nachzubilden. In jedem Fall enthält der Transceiver 216 auch eine Schutzschaltung, die durch bestimmte externe Fehlerzustände hervorgerufene dauerhafte Schäden am Adapter 200 verhindert. Bei anderen bevorzugten Ausführungsformen kann der U-ART als gesonderte IC außerhalb der CPU 204 vorliegen, in welchem Fall der UART zwischen die CPU 204 und den J1587-Transceiver 216 geschaltet sein würde. Bei noch einer weiteren bevorzugten Ausführungsform ist die Transceiverfunktionalität des J1587-Transceivers 216 in eine gesonderte UART-IC integriert, wobei diese einzelne IC mit der CPU 204 gekoppelt ist.
  • Bei einer bevorzugten Ausführungsform steht eine zweite serielle Kommunikationsschnittstelle (Serial 2) der CPU 204 in Verbindung mit dem optionalen RS-232-Transceiver 218. Der optionale RS-232-Transceiver 218 stellt eine Schnittstelle zwischen einer zweiten seriellen Kommunikationsschnittstelle (im übrigen bekannt als universeller asynchroner Empfänger/Sender oder UART) in der CPU 204 und einem seriellen Port eines anderen Computersystems bereit, etwa einem PC oder einem PDA. Der Transceiver 218 enthält ebenfalls eine Schutzschaltung, die durch bestimmte äußere Fehlerzustände hervorgerufene dauerhafte Schäden am Adapter 200 verhindert. Bei anderen bevorzugten Ausführungsformen kann der UART als gesonderte IC außerhalb der CPU 204 vorliegen, in welchem Fall der UART zwischen die CPU 204 und den RS-232-Transceiver 218 geschaltet sein würde. Bei noch einer weiteren bevorzugten Ausführungsform ist die Transceiverfunktionalität des RS-232-Transceivers 218 in eine gesonderte UART-IC integriert, wobei diese einzelne IC mit der CPU 204 gekoppelt ist.
  • Bei einer bevorzugten Ausführungsform steht die Adress-/Datenbusschnittstelle (A/D-Bus) der CPU 204 in Verbindung mit dem optionalen ROM 222 über eine Adressierungssschnittstellenlogik (nicht gezeigt). Der ROM 222 nutzt einen ROM- oder EPROM-Speicher zur Speicherung von Software und weiteren Parametern. Der EPROM-Speicher kann eine Flash-EPROM-, eine EEPROM-, eine UV-EPROM-Schaltung oder irgendein anderer Typ eines löschbaren ROM sein.
  • Bei einer bevorzugten Ausführungsform steht die Adress-/Datenbusschnittstelle (A/D-Bus) über eine Adressierungsschnittstellenlogik (nicht gezeigt) in Verbindung mit dem optionalen zusätzlichen RAM 220. Der zusätzliche RAM 220 kann zur Ausführung von Software oder zum Speichern von Daten bei angelegter Energie verwendet werden.
  • Bei einer bevorzugten Ausführungsform steht die Adress-/Datenbusschnittstelle (A/D-Bus) der CPU 204 bei Bedarf in Verbindung mit der Schnittstellenlogik 206. Die Schnittstellenlogik 206 stellt die geeigneten Schnittstellen- und Zeiterfordernisse zwischen dem parallelen Adress-/Datenbus und/oder den Steuersignalen der CPU 204 und dem USB-Controller 202 bereit. Die Verwendung der Schnittstellenlogik zum Anschluss von Bausteinen an CPUs ist in der Fachwelt bekannt. Bei anderen bevorzugten Ausführungsformen muss die Schnittstellenlogik nicht in einer Schnittstelle zwischen dem parallelen Adress-/Datenbus und/oder den Steuersignalen der CPU 204 und dem USB-Controller 202 erforderlich sein. Bei noch weiteren bevorzugten Ausführungsformen kann die Schnittstelle zwischen der CPU 204 und dem USB-Controller 202 eine serielle Schnittstelle sein, etwa eine serielle Peripherieschnittstelle (SPI).
  • Bei einer bevorzugten Ausführungsform umfasst der USB-Adapter 200 eine Energieversorgungsschaltung (nicht gezeigt), die die optionale Flash-Speicher-Programmierspannung (Vpp), eine optionale 3,3 Volt-Energie sowie eine 5 Volt-Energie für alle internen Schaltungen bereitstellt. Diese Energieversorgungsschaltung kann die 5 Volt-Energie an den USB-Downstream-Vbus im Port 1 liefern. Darüber hinaus kann diese Energieversorgungsschaltung eine optionale externe Erhaltungsladespannung zum Laden wiederaufladbarer PDA-Batterien liefern. Die Energieversorgungsschaltung kann mit elektronischen Fahrzeugsystemen von 12 Volt, 24 Volt und zukünftigen 42 Volt kompatibel sein. Die Energie kann vom Fahrzeug über einen fahrzeugseitigen Datenverbindungsstecker, den Zigarettenanzünder des Fahrzeugs oder andere Mittel geliefert werden. Eine alternative Energiequelle könnte vom Vbus eines angeschlossenen USB-Host kommen. Der USB-Adapter 200 kann auch optionale interne Batterien enthalten, die Energie an den Adapter liefern, oder der Adapter kann Energie von einer externen oder internen Wechselstrom/Gleichstrom-Energieversorgung erhalten, sofern ein Wechselstrom verfügbar ist. Bei Verwendung interner oder externer Batterien ist bei einer beispielhaften Ausführungsform ein stromarmer „Schlaf"-Modus implementiert. Der stromarme „Schlaf"-Modus ist in Kraft, wenn für eine gegebene Zeitdauer keine Kommunikationsaktivität festgestellt wird, um zu verhindern, dass sich die Batterien entladen, wenn der Adapter nicht in Gebrauch ist.
  • Es wird nun auf die 3–10 verwiesen, die Beispiele von Algorithmen darstellen, welche von dem USB-Adapter 200 ausgeführt werden. Die acht Schnittstellen (J1939 zu USB, USB zu J 1939, J 1587 zu USB, USB zu J 1587, J 1939 zu RS-232, RS-232 zu J1939, J1587 zu 125–232 und RS-232 zu J1587) werden nachstehend einzeln erläutert. Ein Fachmann wird erkennen, dass die hier beschriebenen Algorithmen beispielhaft sind und dass andere Algorithmen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • Unter Zuwendung zu 3 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der Schnittstelle von J1939 zu USB darstellt. Der Algorithmus beginnt bei Schritt 302. In Schritt 304 gelangen Netznachrichten enthaltende serielle Informationen vom J1939-Teil des Fahrzeugkommunikationsnetzes 108 zunächst über Leitungen J1939+ und J1939– in den J1939-Transceiver 214. Der Transceiver 214 wandelt das Datensignal so um, wie es erforderlich ist, damit es von der CAN-Schnittstelle der CPU 204 gelesen werden kann. In Schritt 306 wird das Datensignal von einem der CAN-Schnittstelle der CPU 204 zugeordneten CAN-Controller empfangen. In Schritten 308–310 fragt die CPU 204 den CAN-Controller in einem kontinuierlichen Abfragezyklus ab. (Der vollständige Abfragezyklus umfasst die Abfrage auch aller anderen Schnittstellen). Während jedes Zyklus werden in Schritt 312 jegliche neuen Rohdaten gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des CAN-Controllers empfangen werden. Abfragesoftware sowie Unterbrechungsbehandlungsroutinen sind in der Fachwelt wohlbekannt, und ein Fachmann wird erkennen, dass beide Vorgehensweisen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • In Schritt 314 setzt die CPU 204 die Rohdaten zu Nachrichten zusammen, und in Schritt 316 ermittelt sie, ob eine Nachricht für den USB-Host 110 oder eines der USB-Geräte 112 bestimmt ist. Wenn die Nachricht nicht für einen USB-Host 110 oder eines der USB-Geräte 112 bestimmt ist, wird die Nachricht in Schritt 318 verworfen. Andernfalls formatiert die CPU 204 in Schritt 320 die Nachricht in einen oder mehrere geeignet adressierte USB-Rahmen um.
  • In Schritt 322 werden die USB-Rahmen von der A/D-Busschnittstelle der CPU 204 an den USB-Controller 202 gesendet, der sie in Schritt 324 und Schritt 326 oder Schritt 330 an den geeigneten Port (Port 1 für Geräte und Port 2 für einen Host) übermittelt. In Schritt 332 oder Schritt 328 werden die USB-Rahmen vom geeigneten Port des USB-Controllers 202 über die serielle USB-Verbindung nach Maßgabe der Adresse des jeweiligen USB-Rahmens zum USB-Host 110 oder zum USB-Gerät 112 gesendet.
  • Wenn der Controller einen On-The-Go-Port 3 umfasst, übermittelt der USB-Controller 202 die USB-Rahmen optional zum Port 3, soweit geeignet (nicht gezeigt). Die Rahmen werden dann vom Port 3 des USB-Controllers 202 über die serielle USB-Verbindung nach Maßgabe der Adresse des jeweiligen USB-Rahmens an den USB-Host 110 oder das USB-Gerät 112 gesendet. Bei Schritt 334 endet der Algorithmus und kehrt zum „Start"-Schritt 302 zurück.
  • Unter Zuwendung zu 4 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der Schnittstelle von USB zu J1939 darstellt. Der Algorithmus beginnt bei Schritt 402. In Schritt 404 gelangt ein USB-Datenrahmen von der seriellen USB-Verbindung entweder zum Port 1 oder zum Port 2 des USB-Controllers 202. Wenn der Controller einen On-The-Go-Port 3 umfasst, kann ein USB-Datenrahmen von der seriellen USB-Verbindung optional in den Port 3 des USB-Controllers gelangen (nicht gezeigt). In Schritten 406–408 fragt die CPU 204 den USB-Controller 202 in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 410 jegliche neue Datenrahmen gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des USB-Controllers 202 empfangen werden.
  • In Schritt 412 setzt die CPU 204 die Datenrahmen zu Nachrichten zusammen, und in Schritt 414 ermittelt sie, ob eine Nachricht an einen J1939-Knoten des Fahrzeugkommunikationsnetzes 108 adressiert ist. Falls nicht, wird die Nachricht in Schritt 416 verworfen. Andernfalls formatiert die CPU 204 die Nachricht in Schritt 418 zu einem oder mehreren geeignet adressierten J1939-Datenpaketen um. In Schritt 420 werden die J1939-Datenpakete an den CAN-Controller der CPU 204 gesendet, und in Schritt 422 werden die Datenpakete zu dem J1939-Transceiver gesendet. In Schritt 424 übermittelt der Transceiver 214 diese Datenpakete zum geeigneten Knoten des Fahrzeugkommunikationsnetzes 108 über die hiermit gekoppelten Netzleitungen J1939+ und J1939– nach Maßgabe der Adresse des Datenpakets. Bei Schritt 426 endet der Algorithmus und kehrt zum „Start"-Schritt 402 zurück.
  • Unter Zuwendung zu 5 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der Schnittstelle von J1587 zu USB darstellt. Der Algorithmus beginnt bei Schritt 502. In Schritt 504 gelangen Netznachrichten enthaltende serielle Informationen vom J1587-Teil des Fahrzeugkommunikationsnetzes 108 zunächst in den J1587-Transceiver 216 über Leitungen J1587+ und J1587–. Der Transceiver 216 wandelt das Datensignal so um, wie es erforderlich ist, damit es von dem der Serial 1-Schnittstelle der CPU 204 zugeordneten UART gelesen werden kann. In Schritt 506 wird das Datensignal seitens des der Serial 1-Schnittstelle der CPU 204 zugeordneten UART empfangen. In Schritten 508–510 fragt die CPU 204 den UART in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 512 jegliche neuen Rohdaten gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des UART empfangen werden.
  • In Schritt 514 setzt die CPU 204 die Rohdaten zu Nachrichten zusammen, und in Schritt 516 ermittelt sie, ob eine Nachricht für den USB-Host 110 oder eines der USB-Geräte 112 bestimmt ist. Falls nicht, wird in Schritt 518 die Nachricht verworfen. Andernfalls formatiert die CPU 204 die Nachricht in Schritt 520 in einen oder mehrere geeignet adressierte USB-Rahmen um. In Schritt 522 werden die USB-Rahmen von der A/D-Busschnittstelle der CPU 204 zum USB-Controller 202 gesendet, welcher sie in Schritt 524 und entweder Schritt 526 oder Schritt 530 zum geeigneten Port (Port 1 für Geräte und Port 2 für einen Host) übermittelt. In Schritt 528 oder Schritt 532 werden die USB-Rahmen nach Maßgabe der Adresse des USB-Datenrahmens vom geeigneten Port des USB-Controllers 202 über die serielle USB-Verbindung zum USB-Host 110 oder zum USB-Gerät 112 gesendet.
  • Wenn der Controller einen On-The-Go-Port 3 umfasst, übermittelt der USB-Controller 202 die USB-Rahmen optional zum Port 3, soweit geeignet (nicht gezeigt). Die Rahmen werden dann vom Port 3 des USB-Controllers 202 über die serielle USB-Verbindung nach Maßgabe der Adresse des jeweiligen USB-Rahmens zum USB-Host 110 oder zum USB-Gerät 112 gesendet. Bei Schritt 534 endet der Algorithmus und kehrt zum „Start"-Schritt 502 zurück.
  • Unter Zuwendung zu 6 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der Schnittstelle von USB zu J1587 darstellt. Der Algorithmus beginnt bei Schritt 602. In Schritt 604 gelangen serielle Informationen von der seriellen USB-Verbindung als USB-Datenrahmen zunächst entweder in den Port 1 oder in den Port 2 des USB-Controllers 202. Wenn der Controller einen On-The-Go-Port 3 umfasst, kann ein USB-Datenrahmen von der seriellen USB-Verbindung optional in den Port 3 des USB-Controllers 202 gelangen (nicht gezeigt). In Schritten 606–608 fragt die CPU 204 den USB-Controller 202 in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 610 jegliche neuen Datenrahmen gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des USB-Controllers 202 empfangen werden.
  • In Schritt 612 setzt die CPU 204 die Datenrahmen zu Nachrichten zusammen und ermittelt in Schritt 614, ob eine Nachricht an einen J1587-Knoten des Fahrzeugkommunikationsnetzes 108 adressiert ist. Falls nicht, wird die Nachricht in Schritt 616 verworfen. Andernfalls formatiert die CPU 204 die Nachricht in Schritt 618 zu einem oder mehreren geeignet adressierten J1587-Datenpaketen um. In Schritt 620 werden die J1587-Datenpakete zu dem der Serial 1-Schnittstelle der CPU 204 zugeordneten UART gesendet. In Schritt 622 werden die J1587-Datenpakete zum J1587-Transceiver gesendet. In Schritt 624 übermittelt der Transceiver 216 diese Datenpakete zum geeigneten Knoten des Fahrzeugkommunikationsnetzes 108 über die hiermit gekoppelten Leitungen J1587+ und J1587– nach Maßgabe der Adresse des Datenpakets. Bei Schritt 626 endet der Algorithmus und kehrt zu dem „Start"-Schritt 602 zurück.
  • Unter Zuwendung zu 7 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der optionalen Schnittstelle von J1939 zu RS-232 darstellt. Der Algorithmus beginnt bei Schritt 702. In Schritt 704 gelangen Netznachrichten enthaltende serielle Informationen vom J1939-Teil des Fahrzeugkommunikationsnetzes 108 zunächst in den J1939-Transceiver 214 über Leitungen J1939+ und J1939– desselben. Der Transceiver 214 wandelt das Datensignal so um, wie es erforderlich ist, damit es von der CAN-Schnittstelle der CPU 204 gelesen werden kann. In Schritt 706 wird das Datensignal von einem der CAN-Schnittstelle der CPU 204 zugeordneten CAN-Controller empfangen. In Schritten 708–710 fragt die CPU 204 den CAN-Controller in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 712 jegliche neuen Rohdaten gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des CAN-Controllers empfangen werden.
  • In Schritt 714 setzt die CPU 204 die Rohdaten zu Nachrichten zusammen und ermittelt in Schritt 716, ob eine Nachricht für ein mit dem RS-232-Transceiver 218 gekoppeltes serielles Gerät bestimmt ist. Falls nicht, wird die Nachricht in Schritt 718 verworfen. Andernfalls werden die Bytes der Nachricht in Schritt 720 zu dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART gesendet. In Schritt 722 formatiert der UART die Nachricht in einen seriellen Bitstrom um. In Schritt 724 wird der serielle Bitstrom von dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART zum RS-232-Transceiver 218 gesendet. In Schritt 726 übermittelt der RS-232-Transceiver 218 den seriellen Bitstrom über die TXD-Leitung des Transceivers 218 zu dem hiermit gekoppelten seriellen Gerät. Bei Schritt 728 endet der Algorithmus und kehrt zum „Start"-Schritt 702 zurück.
  • Unter Zuwendung zu 8 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der optionalen Schnittstelle von RS-232 zu J1939 darstellt. Der Algorithmus beginnt bei Schritt 802. In Schritt 804 gelangen serielle Informationen von dem mit dem RS-232-Transceiver 218 gekoppelten seriellen Gerät als serieller Bitstrom auf einer Leitung RXD in den Transceiver 218 und werden in Schritt 806 unmittelbar zu dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART weitergeleitet. Der UART wandelt den seriellen Bitstrom in Bytes um und speichert die Bytes in einem Puffer. In Schritten 808–810 fragt die CPU 204 den UART in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 812 jegliche neuen Bytes gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des UART empfangen werden.
  • In Schritt 814 setzt die CPU 204 die Bytes zu Nachrichten zusammen und ermittelt in Schritt 816, ob eine Nachricht an einen J1939-Knoten des Fahrzeugkommunikationsnetzes 108 adressiert ist. Falls nicht, wird in Schritt 818 die Nachricht verworfen. Andernfalls formatiert die CPU 204 in Schritt 820 die Nachricht zu einem oder mehreren geeignet adressierten J1939-Datenpaketen um. In Schritt 822 werden die J1939-Datenpakete zu dem CAN-Controller der CPU 204 gesendet. In Schritt 824 werden die J1939-Datenpakete zu dem J1939-Transceiver 214 gesendet. In Schritt 826 übermittelt der Transceiver 214 die Datenpakete nach Maßgabe der Adresse des Datenpakets zum geeigneten Knoten des Fahrzeugkommunikationsnetzes 108. Bei Schritt 828 endet der Algorithmus und kehrt zum „Start"-Schritt 802 zurück.
  • Unter Zuwendung zu 9 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der optionalen Schnittstelle von J1587 zu RS-232 darstellt. Der Algorithmus beginnt bei Schritt 902. In Schritt 904 gelangen Netznachrichten enthaltende serielle Informationen vom J1587-Teil des Fahrzeugkommunikationsnetzes 108 zunächst in den J1587-Transceiver 216 über Leitungen J1587+ und J1587– desselben. Der Transceiver 216 wandelt das Datensignal so um, wie es erforderlich ist, damit es von dem der Serial 1-Schnittstelle der CPU 204 zugeordneten UART gelesen werden kann. In Schritt 906 wird das Datensignal seitens des der Serial 1-Schnittstelle der CPU 204 zugeordneten UART empfangen. In Schritten 908–910 fragt die CPU 204 den UART in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 912 jegliche neuen Rohdaten gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des UART empfangen werden.
  • In Schritt 914 setzt die CPU 204 die Rohdaten zu Nachrichten zusammen und ermittelt in Schritt 916, ob eine Nachricht für ein mit dem RS-232-Transceiver 218 gekoppeltes serielles Gerät bestimmt ist. Falls nicht, wird die Nachricht in Schritt 918 verworfen. Andernfalls werden in Schritt 920 die Bytes der Nachricht zu dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART gesendet. In Schritt 922 formatiert der UART die Nachricht in einen seriellen Bitstrom um. In Schritt 924 wird der serielle Bitstrom von dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART zum RS-232-Transceiver 218 gesendet. In Schritt 926 überträgt der Transceiver 218 den seriellen Bitstrom über die TXD-Leitung des Transceivers 218 zu dem hiermit gekoppelten seriellen Gerät. Bei Schritt 928 endet der Algorithmus und kehrt zum „Start"-Schritt 902 zurück.
  • Unter Zuwendung zu 10 ist ein Ablaufdiagramm gezeigt, das eine bevorzugte Ausführungsform eines Algorithmus zur Implementierung der optionalen Schnittstelle von RS-232 zu J1587 darstellt. Der Algorithmus beginnt bei Schritt 1002. In Schritt 1004 gelangen serielle Informationen von dem mit dem RS-232-Transceiver 218 gekoppelten seriellen Gerät als serieller Bitstrom in den Transceiver 218 und werden in Schritt 1006 unmittelbar zu dem der Serial 2-Schnittstelle der CPU 204 zugeordneten UART weitergeleitet. Der UART wandelt den seriellen Bitstrom in Bytes um und speichert die Bytes in einem Puffer. In Schritten 1008–1010 fragt die CPU 204 den UART in einem kontinuierlichen Abfragezyklus ab. Während jedes Zyklus werden in Schritt 1012 jegliche neuen Bytes gelesen und in einem der CPU 204 zugeordneten RAM gespeichert. Alternativ kann die CPU 204 auf eine Unterbrechung ansprechen, die erzeugt wird, wenn Daten seitens des UART empfangen werden.
  • In Schritt 1014 setzt die CPU 204 die Bytes zu Nachrichten zusammen und ermittelt in Schritt 1016, ob eine Nachricht an einen J1587-Knoten des Fahrzeugkommunikationsnetzes 108 adressiert ist. Falls nicht, wird in Schritt 1018 die Nachricht verworfen. Andernfalls formatiert die CPU 204 die Nachricht in Schritt 1020 zu einem oder mehreren geeignet adressierten J1587-Datenpaketen um. In Schritt 1022 werden die J1587-Datenpakete zu dem der Serial 1-Schnittstelle der CPU 204 zugeordneten UART gesendet. In Schritt 1024 werden die J1587-Datenpakete zum J1587-Transceiver 216 gesendet. In Schritt 1026 übermittelt der Transceiver 216 die Datenpakete zum geeigneten Knoten des Fahrzeugkommunikationsnetzes 108 über die hiermit gekoppelten Leitungen J1587+ und J1587– nach Maßgabe der Adresse des Datenpakets. In Schritt 1028 endet der Algorithmus und kehrt zum „Start"-Schritt 1002 zurück.
  • Auch andere Ausführungsformen der vorliegenden Erfindung können implementiert werden, um ohne vom Umfang der beanspruchten Erfindung abzuweichen. Beispielsweise kann es bei einer illustrativen Ausführungsform erwünscht sein, den USB-Adapter 200 mit Fähigkeiten zum Herunterladen der aktualisierten Kalibrierungssoftware von einem entfernten Computer auf einen fahrzeugseitigen Subsystemcomputer auszustatten. Als weiteres Beispiel erörtert die Offenbarung vorrangig Motorsteuercomputer. Der USB-Adapter 200 kann jedoch bei anderen beispielhaften Ausführungsformen dazu verwendet werden, ferne Computer mit anderen Fahrzeugsubsystemen zu verbinden, etwa Anwendungen, die Getriebe betreffen, Antiblockiersystemen, Fahrzeugmanagementcomputern und dergleichen.
  • Bei der vorstehenden Offenbarung ist anzumerken, das PCs im allgemeinen Fahrzeugdiagnosesoftware ausführen, während PDAs im allgemeinen Servicewerkzeugsoftware ausführen. Dies ist jedoch nicht notwendigerweise der Fall und nichts in der Offenbarung sollte so gelesen werden, dass es die Software beschränkt, die von einem mit einem erfindungsgemäßen Fahrzeugkommunikationsnetz gekoppelten fernen Computer ausgeführt werden kann. Darüber hinaus kann nahezu jeder Computer mit den erforderlichen Kommunikationsfähigkeiten über den USB-Adapter 200 mit dem Fahrzeugkommunikationsnetz 108 gekoppelt sein und nichts in der Offenbarung ist in anderer Richtung zu verstehen.
  • Bezugnehmend nunmehr auf 11 ist eine Blockdarstellung einer weiteren Ausführungsform eines Kommunikationsnetzes mit einer Kommunikationsbrücke 200' gezeigt, die für einen Informationsaustausch zwischen einem oder mehreren Fahrzeugkommunikationsnetzen 1081–108N und einem Fernsystem 225 sorgt, wobei N eine positive ganze Zahl ist. Das eine oder die mehreren Kommunikationsnetze 1081–108N werden von einem Kraftfahrzeug 105 mitgeführt, das ein Fahrzeugsteuersystem 100 umfasst, wie zuvor beschrieben. Das Fahrzeugsteuersystem 100 kann eine beliebige Anzahl von Steuercomputern umfassen, die jeweils so betreibbar sind, dass sie eine oder mehrere Funktionen steuern, die das Fahrzeug 105 und/oder den von diesem getragenen Motor betreffen, wobei jeder aus der Anzahl der Steuercomputer betriebsmäßig mit einem oder mehreren der Fahrzeugkommunikationsnetze 1081–108N verbunden sein kann. Wie in 11 dargestellt, kann das Fahrzeugsteuersystem beispielsweise zumindest einen Kraftstoffsystemsteuercomputer 102, einen Getriebesteuercomputer 104 sowie einen Datenprotokolliersteuercomputer 106 umfassen, wie vorstehend mit Bezug auf 1 beschrieben.
  • Bei dem gezeigten Beispiel umfasst das Fahrzeug 105 zwei Fahrzeugkommunikationsnetze, weswegen N zwei ist. Das Fahrzeugkommunikationsnetz 1081 ist eine J1708-Hardwarekommunikationsstruktur gemäß der Society of Automotive Engineers (SAE), die eine bestimmte Ausführung einer allgemeinen RS-485-Hardwarestruktur ist, welche eine nach einem etablierten SAE J1587-Kommunikationsprotokoll konfigurierte Kommunikation unterstützt, wie sie in der Fachwelt bekannt ist und zumindest teilweise vorstehend beschrieben wurde. Das Fahrzeugkommunikationsnetz 1082 dagegen ist eine SAE J1939-Hardwarekommunikationsstruktur, die eine Kommunikation unterstützt, welche nach einem etablierten SAE J1939-Kommunikationsprotokoll konfiguriert ist, wie es in der Fachwelt bekannt ist und zumindest teilweise vorstehend beschrieben wurde. Der Kraftstoffsystemsteuercomputer 102, der in der Motorsteuerungsindustrie üblicherweise als elektronisches oder Motorsteuermodul (ECM) bezeichnet werden kann, und der Datenprotokolliersteuercomputer 106 sind bei diesem Beispiel beide betriebsmäßig in Kommunikationsverbindung mit jedem der SAE J1708- und SAE J1939-Kommunikationsnetze. Der Getriebesteuercomputer 104 dagegen steht betriebsmäßig lediglich mit dem SAE J1939-Kommunikationsnetz in Kommunikationsverbindung. Ein Fachmann wird andere Verbindungsanordnungen der Steuercomputer 102, 104 und 106 bezüglich der SAE J1708- und SAE J1939-Kommunikationsnetze erkennen und auch erkennen, dass das Fahrzeug 105 einen oder mehrere alternative oder zusätzliche Steuercomputer mitführen kann, die betriebsmäßig in Kommunikationsverbindung mit einem oder beiden der SAE J1587- und/oder SAE J1939-Kommunikationsnetze stehen können. Darüber hinaus ist beabsichtigt, dass das Kraftfahrzeug 105 alternativ oder zusätzlich andere bekannte Fahrzeugkommunikationsnetze aufweisen kann und dass einer oder mehrere der von dem Kraftfahrzeug 105 mitgeführten Steuercomputer betriebsmäßig in Kommunikationsverbindung mit einem oder mehreren solcher alternativer oder zusätzlicher Fahrzeugkommunikationsnetze stehen können. Derartige alternative Verbindungen und/oder alternative oder zusätzliche Steuercomputer und/oder alternative oder zusätzliche Fahrzeugkommunikationsnetze fallen beabsichtigtermaßen in den Umfang der hieran angehängten Ansprüche.
  • Das Kommunikationsbrückensystem 200' ist konform mit RP-1210, wie vorstehend beschrieben. Es ist zur Verbindung mit dem einen oder den mehreren von dem Kraftfahrzeug 105 mitgeführten Fahrzeugkommunikationsnetzen 1081 und 108N über entsprechende Signalwege 1201–120N ausgelegt und zur Verbindung mit einem computerbasierten Fernsystem oder einer Ferneinheit 225 über einen oder mehrere einer Anzahl M von Signalwegen 2151–215M ausgelegt, wobei M irgendeine ganze Zahl sein kann. Das computerbasierte Fernsystem oder die Ferneinheit 225 kann irgendein computerbasiertes System, eine Einheit oder ein Gerät sein, das bzw. die zur externen Kommunikation mittels eines oder mehrerer bekannter Kommunikationsprotokolle ausgelegt ist, wobei diesbezüglich der eine oder die mehreren Kommunikationswege 2151–215M entsprechend eine oder mehrere geeignet konfigurierte Hardware- oder drahtlose Kommunikationsstrukturen enthalten, die zur Kommunikation nach dem einen oder den mehreren Kommunikationsprotokollen ausgelegt sind. Beispiele des computerbasierten Fernsystems oder der Ferneinheit 225 umfassen jegliche bekannten Personalcomputer (PC), handtragbaren persönlichen digitalen Assistenten (PDA), sogenannten Taschen-PC oder dergleichen, sind jedoch nicht hierauf beschränkt. Beispiele von Kommunikationsprotokollen, die von derartigen computerbasierten Fernsystemen oder -einheiten 225 verwendet werden, umfassen RS-232, einen universellen seriellen Bus (USB), eine drahtlose Kommunikation wie etwa eine nach den 802.11-Standards oder Bluetooth konfigurierte oder dergleichen, sind aber nicht hierauf beschränkt. Das computerbasierte System oder die Einheit 225 kann zur externen Kommunikation mittels eines oder mehrerer derartiger Kommunikationsprotokolle ausgelegt sein, wobei die Wahl einer oder mehrerer Hardware- oder drahtloser Verbindungen (eine oder mehrere von 2151–215M ) zwischen dem System oder der Einheit 225 und dem Kommunikationsbrückensystem 200' hierdurch festgelegt wird.
  • Bezugnehmend nunmehr auf 12 ist eine beispielhafte Ausführungsform des Kommunikationsbrückensystems 200' der 11 gezeigt. Das in 12 dargestellte Kommunikationsbrückensystem 200' ist zur Verbindung mit dem SAE J1708-Kommunikationsnetz und dem SAE J1939-Kommunikationsnetz des Kraftfahrzeugs 105, mit einem RS-232-Port des computerbasierten Fernsystems oder der Ferneinheit 225 und optional mit einem USB-Port des computerbasierten Fernsystems oder der Ferneinheit 225 ausgelegt, wie in 12 gestrichelt dargestellt. Bei dieser Ausführungsform ist das Kommunikationsbrückensystem 200' zur Kommunikation mit dem Fahrzeugkommunikationssystem 100 gleichzeitig über die SAE J1587- und J1939-Kommunikationsnetze und zur Kommunikation mit dem computerbasierten Fernsystem 225 über eine RS-232- und/oder USB-Verbindung hierzu ausgelegt.
  • Das in 12 Kommunikationsbrückensystem 200' ist in einigen Aspekten ähnlich zu dem vorstehend mit Bezug auf 2 dargestellten und beschriebenen Kommunikationsadapter, weswegen gleiche Bezugszahlen zur Identifizierung gleicher Komponenten verwendet werden. Ein wesentlicher Unterschied zwischen dem Kommunikationsadapter 200 und dem Kommunikationsbrückensystem 200' der 12 ist jedoch, dass das Kommunikationsbrückensystem 200' der 12 von einem digitalen Signalprozessor (DSP) 224 statt einem Mikroprozessor gesteuert wird. Der DSP 224 führt den Firmware-Code aus, der benötigt wird, um alle Operationen und Funktionen des Kommunikationsbrückensystems 200' zu bewirken. Enthalten in der DSP-Schaltung 224 sind ein zentraler Prozessor und ein nichtflüchtiger Speicher, ein flüchtiger Speicher (RAM), ein Kristall-/Oszillator-Eingang, ein paralleler Adress-/Datenbus, ein CAN-Controller, serielle Kommunikationscontroller, ein Analog/Digital-Wandler sowie digitale Allzweck-Eingänge/Ausgänge, wie in näherer Einzelheit nachstehend beschrieben. Neben der Verarbeitung von Daten von den verschiedenen Fahrzeugkommunikationsnetzen steuert der DSP 224 den Zustand der Ausgangssignale, um den Ein/Aus-Status von Statusanzeigern zu ändern, und misst Eingangssignale, die die Spannungspegel von verschiedenen interessierenden Energieversorgungsspannungen und die Diagnosezustände der Anzeigerausgangstreiber angeben. Das System 200' umfasst ferner eine erste Kristall/Oszillator-Schaltung 208, die dazu ausgelegt ist, ein erstes Taktsignal zu erzeugen und dieses Taktsignal an einen Takteingang XTAL des DSP 224 zu liefern. Die Kristall/Oszillator-Schaltung 208 kann dazu ausgelegt sein, den DSP 224 in einer in der Fachwelt wohlbekannten Weise mit einem Taktsignal einer beliebigen gewünschten Frequenz zu versorgen.
  • Bei einer beispielhaften Ausführungsform ist der DSP 224 ein digitaler 16 Bit-Signalprozessor DSP56F807 von Motorola, wenngleich berücksichtigt ist, dass andere bekannte digitale Signalprozessoren verwendet werden können. Der DSP56F807 ist ein Mitglied der auf dem DSP56800-Kern basierenden Familie von digitalen Signalprozessoren von Motorola und vereinigt auf einem einzigen Chip die Verarbeitungskraft eines DSP und die Funktionalität eines Mikrocontrollers mit einem flexiblen Satz von Peripheriekomponenten. Der DSP56F807-Prozessorkern basiert auf einer Harvard-Architektur mit drei parallel arbeitenden Ausführungseinheiten, wodurch die Ausführung von bis zu sechs Operationen pro Befehlszyklus ermöglicht wird. Somit kann beispielsweise mit lediglich zwei der parallelen Ausführungseinheiten ein Programmbefehl durch den Programmcontroller des DSP56F807 geholt werden, während von seiner Adresserzeugungseinheit (AGU) zwei Adressen für den nächsten Befehl erzeugt werden und in seiner arithmetischen logischen Dateneinheit (ALU) eine mathematische Operation durchgeführt wird. Die Verarbeitungsgeschwindigkeit, die von den parallelen Befehlsausführungsfähigkeiten des DSP 224 bereitgestellt wird, erlaubt es, pro Befehlszyklus mehrere mathematische Operationen in Echtzeit abzuarbeiten und Datennachrichten mit mehreren Rahmen fehler- und ausfallssicher umzuwandeln und zu übertragen. Die Kristall/Oszillator-Schaltung 208 ist bei dieser Ausführungsform des DSP 224 dazu ausgelegt, ein 8 MHz-Taktsignal an den XTAL-Eingang des DSP 224 zu liefern, wobei der DSP 224 dahingehend betreibbar ist, das Taktsignal zu multiplizieren und zu teilen, wie es erforderlich ist, um geeignete interne Taktsignale bereitzustellen.
  • Der DSP 224 umfasst einen internen Programm- und Daten-RAM (nicht gezeigt) und kann einen internen Flash-Speicher 226 aufweisen, wie gestrichelt in 12 gezeigt. Es kann auch erwünscht sein, dass in dem System 200' ein zusätzlicher RAM außerhalb des DSP 224 enthalten ist, wobei bei solchen Ausführungsformen der DSP 224 entsprechend in der Lage ist, einen derartigen externen Speicher zu unterstützen. Der DSP56F807 beispielsweise umfasst 2K × 16 Bit-Worte an Programm-RAM, 8K × 16 Bit-Worte an Daten-RAM, 60K × 16 Bit-Worte an Programm-Flash, 8K × 16 Bit-Worte an Daten-Flash und 2K × 16 Bit-Worte an Boot-Flash-Speicher, wobei der Flash-Speicher über den USB-Controller 202' programmierbar ist, wie nachstehend in näherer Einzelheit beschrieben, und jeweils 64K × 16 Bit-Worte an externem Programm- und Datenspeicher unterstützt. Der DSP56F807 kann bis zu 40 Millionen Befehle pro Sekunde (MIPS) bei einer Kernfrequenz von 80 MHz abarbeiten. Weitere Details bezüglich der technischen Fähigkeiten und Merkmale des DSP56F807 sind im technischen Datenhandbuch des DSP56F807, Überarbeitung 8.0 11/2002, niedergelegt, das von Motorola, Inc. erhältlich ist und dessen Inhalt hiermit durch Verweis einbezogen wird.
  • Das Kommunikationsbrückensystem 200' weist eine Energiequellenwählschaltung 230 bekannter Konstruktion auf, die so betreibbar ist, dass auf Grundlage der Auswahl eines aus einer Anzahl von Quellenspannungseingängen zu dieser eine Eingangsspannung VI zu einer Energieversorgung 234 geliefert wird, die ebenfalls bekannter Konstruktion ist. Bei der in 12 dargestellten Ausführungsform weist die Energiequellenwählschaltung 230 einen ersten Quellenspannungseingang auf, der eine extern erzeugte Spannung VE erhält. Die externe Spannung VE kann von einer geeigneten Gleichspannungsquelle einschließlich beispielsweise der Fahrzeugbatterie oder der Fahrzeugbatterien (z.B. über eines der Fahrzeugkommunikationsnetze 1081–108N , über einen bekannten Zigarettenanzünderadapter oder dergleichen), einer anderen Hilfsbatterie oder einem Hilfsbatteriepaket, einer herkömmlichen einsteckbaren Wechselstrom/Gleichstrom-Energieversorgung oder dergleichen stammen, ist aber hierauf nicht beschränkt. Bei Ausführungsformen, wo VE die einzig verfügbare Quellenspannung zum System 200' ist, kann die Energiequellenwählschaltung 230 weggelassen sein und VE direkt als Eingangsspannung VI zur Energieversorgung 234 geliefert werden.
  • Das System 200' kann optional eine gestrichelt in 12 gezeigte interne Batterieversorgung 232 aufweisen, die eine Batteriespannung VB an die Energiequellenwählschaltung 230 liefert. Die interne Batterieversorgung 232 kann eine oder mehrere wiederaufladbare oder nicht wiederaufladbare Batterien oder Batteriepakete herkömmlicher Ausbildung enthalten. Bei Ausführungsformen des Systems 200' mit einem USB-Host/Gerät-Controller/Transceiver 202', wie gestrichelt in 12 gezeigt, wird ein derartiges Gerät typischerweise einen Spannungsbus- (VBUS) Port aufweisen, der zur Verbindung mit einem entsprechenden VBUS-Port des Fernsystems oder der Ferneinheit 225 ausgelegt ist. Bei solchen Ausführungsformen kann die VBUS-Spannung von dem Fernsystem und der Ferneinheit 225 als weiteren Quellenspannungseingang zur Energiequellenwählschaltung 230 geliefert werden, wie gestrichelt in 12 gezeigt. Wenngleich in den Zeichnungen nicht speziell gezeigt, kann alternativ die Energieversorgung 234 so ausgelegt sein kann, dass die VBUS-Spannung sowohl an den USB-Host/Gerät-Controller/Transceiver 202' als auch an das Fernsystem oder die Ferneinheit 225 geliefert wird. In jedem Fall wird ein Fachmann weitere bekannte Gleichspannungsquellen erkennen, die verwendet werden können, um zusätzliche Quellenspannungseingänge zur Energiequellenwählschaltung 230 des Systems 200' vorzusehen, wobei alle solchen weiteren bekannten Gleichspannungsquellen beabsichtigtermaßen in den Umfang der hieran angehängten Ansprüche fallen. Die Energiequellenwählschaltung 230 kann ferner einen manuell betätigten Schalter (nicht gezeigt) aufweisen, der es erlaubt, aus der Anzahl von Quellenspannungseingängen einen geeigneten als die Eingangsspannung VI für die Energieversorgung 234 zu wählen.
  • Die Energieversorgung 234 ist eine herkömmliche Energieversorgungsschaltung, die dazu betreibbar ist, mindestens eine auf der Eingangsspannung VI basierende erste Versorgungsspannung VS1 zu liefern, wobei VS1 als Energieversorgungsspannung für einige der in dem Kommunikationsbrückensystem 200' enthaltenen Schaltungen dient, wie in 12 dargestellt. Bei einer Ausführungsform ist die Energieversorgung 234 dazu betreibbar, VS1 mit einem Nennpegel von 5,0 Volt basierend auf einer Eingangsspannung VI zu erzeugen, die zwischen Nennspannungspegeln von 12,0–42,0 Volt liegen kann, wenngleich zu verstehen ist, dass die Energieversorgungsschaltung 234 alternativ so ausgelegt sein kann, dass sie VS1 mit irgendeinem gewünschten Spannungspegel auf Basis irgendeines gewünschten Eingangsspannungsbereichs erzeugt. Bei der in 12 dargestellten Ausführungsform erzeugt die Energieversorgung 234 ferner eine zweite Versorgungsspannung VS2, die ebenfalls auf VI basiert und als niedrigere Energieversorgungsspannung für einige der in dem Kommunikationsbrückensystem 200' enthaltenen verbleibenden Schaltungen dient, wie 12 dargestellt. Bei einer Ausführungsform beträgt VS2 3,3 Volt, wenngleich andere Niederspannungswerte vorstellbar sind. Optional kann, wie gestrichelt in 12 gezeigt, die Energieversorgung 234 ferner eine Programmierspannung VP erzeugen, die als Programmierspannung zur Programmierung des Flash-Speichers 226 an den DSP 224 geliefert wird, wie 12 dargestellt. Bei einer Ausführungsform beträgt VP 12,0 Volt, wenngleich andere Niederspannungswerte vorstellbar sind.
  • Das System 200' kann außerdem optional eine herkömmliche Ladeschaltung 236 für externe Batterien aufweisen, die von der Energieversorgung 234 eine Ladespannung VC erhält und die Ladespannung VC an einen Port EDP für externe Geräte liefert. Bei einer Ausführungsform enthält die Ladeschaltung 236 für externe Batterien eine rücksetzbare Sicherung oder einen Schaltungsunterbrecher 238, die bzw. der dazu betreibbar ist, Schäden an der Energieversorgung 234 zu verhindern, die aus externen Fehlerzuständen resultieren. Die Batterieladeschaltung 236 kann einen Freigabeeingang E ausweisen, der mit einem Freigabebatterieladeausgang EBC des DSP 224 verbunden ist, wobei der DSP 224 bei dieser Ausführungsform dazu betreibbar ist, über den EBC-Ausgang den Betrieb der Ladeschaltung 236 für externe Batterien freizugeben und zu sperren. Die Energieversorgung 234 und die Batterieladeschaltung 236 können dazu ausgelegt sein, eine Ladespannung VC bereitzustellen, die zum Laden einer oder mehrerer externer Batterien geeignet ist, etwa solcher, wie sie dem Fernsystem oder der Ferneinheit 225 zugeordnet sein können. Bei einer Ausführungsform des Systems 200' beispielsweise sind die Energieversorgung 234 und die Batterieladeschaltung 236 so ausgelegt, dass sie eine Ladespannung VC liefern, die zum Laden einer oder mehrerer einem handtragbaren PDA zugeordneter Batterien geeignet ist.
  • Bei der in 12 dargestellten Ausführungsform weist der DSP 224 eine serielle Kommunikationsschnittstelle (SCI) mit einem RS232 genannten Eingabe/Ausgabe-Port auf, welcher betriebsmäßig mit einem RS-232-Transceiver 218 verbunden ist. Der RS-232-Transceiver 218 ist dazu ausgebildet, als Kommunikationsschnittstelle zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225 zu dienen, und ist dementsprechend zur elektrischen Verbindung mit einem RS-232-Kommunikationsport des Fernsystems oder der Ferneinheit 225 über einen entsprechend konfigurierten der Signalwege 2151–215M ausgelegt. So verschaltet ist der DSP 224 dazu betreibbar, mittels des RS-232-Kommunikationsprotokolls mit einem oder mehreren Fernsystemen oder -einheiten 225 zu kommunizieren. Es versteht sich, dass der RS-232-Transceiver alternativ zugunsten einer anderen zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225 vorgesehenen Kommunikati onsanordnung weggelassen sein kann, z.B. einer parallelen Kommunikationsverbindung, einer USB-Verbindung, einer drahtlosen Kommunikationsverbindung oder dergleichen, oder alternativ in einem derartigen System als zusätzliche oder optionale Kommunikationsschnittstelle zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225 enthalten sein kann. In jedem Fall ist der RS-232-Transceiver 218 identisch zu dem vorstehend mit Bezug auf 2 beschriebenen herkömmlichen Transceiver 218, nämlich insoweit, als er einen Datenempfangseingang RXD und einen Datensendeausgang TXD aufweist. Außerdem weist der Transceiver 218 einen herkömmlichen „Ready-to-Send"-Eingang RTX sowie einen herkömmlichen „Clear-to-Send"-Ausgang CTS auf, deren Zweck nachstehend mit Bezug auf 14 erläutert wird. Die TXD- und CTS-Ausgänge sowie die RXD- und RTS-Eingänge wie auch ein Masseanschluss des Transceivers 218 sind in 12 als mit einem ersten Verbinder C1 elektrisch verbunden gezeigt, wobei C1 irgendein bekannter elektrischer Verbinder sein kann. Bei einer beispielhaften Ausführungsform ist C1 ein herkömmliches D-Subminiaturverbinder-Buchsenteil mit neun Anschlüssen und der in Tabelle 1 dargestellten Anschlussbelegung.
  • Tabelle 1
    Figure 00490001
  • Der DSP 224 umfasst ferner eine weitere serielle Kommunikationsschnittstelle (SCI) mit einem J1587 genannten Eingabe/Ausgabe-Port, der betriebsmäßig mit einem J1708-RS-485-Transceiver 216 verbunden ist, wobei der J1708/RS-485-Transceiver 216 dazu ausgelegt ist, als Kommunikationsschnittstelle zwischen dem DSP 224 und dem in 11 dargestellten SAE J1708-Fahrzeugkommunikationsnetz 1081 zu dienen. Der J1708/RS-485-Transceiver 216 ist identisch zu dem vorstehend mit Bezug auf 2 beschriebenen herkömmlichen J1587-Transceiver 216 und weist Dateneingabe/-ausgabe-Ports J1708+ und J1708– auf, welche zur Verbindung mit dem J1708-Fahrzeugkommunikationsnetz 1081 ausgelegt sind. So verschaltet ist der DSP 224 dazu betreibbar, mit Hilfe des SAE J1587-Kommunikationsprotokolls mit einem oder mehreren Steuercomputern zu kommunizieren, die in Kommunikation mit dem J1708-Fahrzeugkommunikationsnetz stehen. Die Ports J1708+ und J1708– des Transceivers 216 sind in 12 als mit einem zweiten Verbinder C2 elektrisch verbunden gezeigt, wobei C2 irgendein bekannter elektrischer Verbinder sein kann.
  • Der DSP 224 umfasst ferner einen Controller Area Network- (CAN) Controller mit einem CAN genannten Eingabe/Ausgabe-Port, welcher betriebsmäßig mit einem CAN-Transceiver 214 verbunden ist, wobei der CAN-Transceiver 214 dazu ausgelegt ist, als Kommunikationsschnittstelle zwischen dem DSP 224 und dem in 11 dargestellten SAE J1939-Fahrzeugkommunikationsnetz 108N zu dienen. Der CAN-Transceiver 214 ist identisch zu dem vorstehend mit Bezug auf 2 beschriebenen herkömmlichen CAN-Transceiver 214 und weist Dateneingabe/-ausgabe-Ports J1939+ und J1939– sowie einen Abschirmanschluss J1939S auf, die zur Verbindung mit dem J1939-Fahrzeugkommunikationsnetz 108N ausgelegt sind. So verschaltet ist der DSP 224 dazu betreibbar, mit Hilfe des SAE J1939-Kommunikationsprotokolls mit einem oder mehreren Steuercomputern zu kommunizieren, die in Kommunikation mit dem J1939-Fahrzeugkommunikationsnetz stehen. Die Ports J1939+, J1939– und J1939S des Transceivers 214 sind in 12 als mit dem Verbinder C2 elektrisch verbunden gezeigt, wobei C2 irgendein bekannter elektrischer Verbinder sein kann. Bei einer beispielhaften Ausführungsform ist C2 ein herkömmlicher D-Subminiaturstecker mit 25 Beinen, dessen Beinbelegung in Tabelle 2 dargestellt ist.
  • Tabelle 2
    Figure 00500001
  • Wenngleich in 12 der J1708/RS-485-Transceiver 216 und der CAN-Transceiver 214 so dargestellt sind, dass sie beide mit einem einzigen Verbinder, nämlich C2, verbunden sind, versteht es sich, dass alternativ jeder Transceiver mit einem eigens zugewiesenen Verbinder verbunden sein kann, der zur Verbindung mit einem entsprechenden der Fahrzeugkommunikationsnetze 1081–108N ausgelegt ist.
  • Bei der in 12 dargestellten Ausführungsform ist das Kommunikationsbrückensystem 200' so gezeigt, dass es optional einen USB-Host/Gerät-Controller/Transceiver 202' und/oder eine zusätzliche Hilfsspeichereinheit 244 aufweist, die über eine Verbindungslogikschaltung bzw. Glue-Logic-Schaltung 206' mit einem Adress- und Datenbusport ADBUS gekoppelt sind. Es versteht sich, dass der USB-Controller/Transceiver 202' als einzige Kommunikationsschnittstelle zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225 vorgesehen sein kann, in welchem Fall der RS-232-Transceiver 218 weggelassen werden kann, oder alternativ zusätzlich zu dem RS-232-Transceiver 218 vorgesehen sein kann, in welchem Fall eine Kommunikation mit einem oder mehreren Fernsystemen oder -einheiten 225 entweder gesondert oder gleichzeitig über den RS-232-Transceiver 218 und/oder den USB-Controller/Transceiver 202' erfolgen kann.
  • Der USB-Host/Gerät-Controller/Transceiver 202' ist in vielerlei Hinsicht identisch zu dem mit Bezug auf 2 dargestellten und beschriebenen USB-Controller 202', mit der Ausnahme, dass der USB-Controller/Transceiver 202' lediglich einen einzigen Kommunikationsport aufweist, der in bekannter Weise als Hostport, Geräteport- oder On-The-Go-Host- oder -Geräteport konfiguriert werden kann. Es versteht sich jedoch, dass der USB-Controller/Transceiver 202' alternativ eine beliebige Anzahl gewünschter Kommunikationsports aufweisen kann. Beispielsweise kann der in 12 dargestellte USB-Controller/Transceiver 202' alternativ als der in 2 dargestellte USB-Controller 202 implementiert werden kann.
  • In jedem Fall weist der DSP 224 einen Adress- und Datenbusport mit den erforderlichen Steuersignalen auf, nämlich ADBUS, der betriebsmäßig mit dem USB-Controller/Transceiver 224 über die Verbindungslogikschaltung 206' verbunden ist, welche identisch zu der mit Bezug auf 2 dargestellten und erläuterten Schnittstellenlogikschaltung 206 sein kann, da diese Schaltung 206 die Schnittstelle zwischen dem DSP 224 und dem USB-Controller/Transceiver 202' betrifft. Bei Ausführungsformen des Systems 200', die den USB-Controller/Transceiver 202' enthalten, ist dieser dazu ausgelegt, als Kommunikationsschnittstelle zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225 zu dienen, und ist entsprechend zur elektrischen Verbindung mit einem entsprechenden USB-Kommunikationsport des Fernsystems oder der Ferneinheit 225 über einen entsprechend konfigurierten der Signalwege 2151–215M ausgelegt. So verschaltet ist der DSP 224 dazu betreibbar, mit Hilfe des USB-Kommunikationsprotokolls mit einem oder mehreren Fernsystemen oder Ferneinheiten 225 zu kommunizieren. Bei der in 12 dargestellten Ausführungsform weist der USB-Controller/Transceiver 202' eine Anzahl von zusätzlichen Eingängen und Ausgängen auf, die mit einem USB-Steuerport, nämlich USB, des DSP 224 gekoppelt sind, über den der DSP 224 bestimmte Portkonfigurations- und Datentransferfunktionen steuern kann, die typischerweise mit dem Betrieb der in 12 dargestellten Ausführungsform des USB-Controllers/Transceivers 202' verbunden sind. Der USB-Steuerport USB des DSP 224 wird nachstehend mit Bezug auf 14 näher erläutert.
  • Bei einigen Ausführungsformen des Systems 200' kann der USB-Controller/Transceiver 202' eine Taktquelle mit einer Taktfrequenz erfordern, die sich von derjenigen unterscheidet und/oder nicht ohne weiteres von derjenigen herleitbar ist, welcher von der Kristall/Oszillator-Schaltung 208 bereitgestellt wird. Bei solchen Ausführungsformen umfasst das System 200 eine zweite Kristall/Oszillator-Schaltung 246 herkömmlicher Konstruktion, die ein zweites Taktsignal an einen Takteingang XTAL des USB-Controllers/Transceivers 202' liefert. Bei einer Ausführungsform beispielsweise ist die zweite Kristall/Oszillator-Schaltung 246 dazu ausgelegt, ein 12 MHz-Taktsignal an den XTAL-Eingang des USB-Controllers/Transceivers 202' zu liefern, wenngleich es sich versteht, dass die zweite Kristall/Oszillator-Schaltung 246 alternativ dazu ausgelegt sein kann, den USB-Controller/Transceiver 202' mit einem Taktsignal einer beliebigen gewünschten Frequenz zu versorgen.
  • Die Anschlüsse für VBUS, D+, D–, ID und Masse zum USB-Controller/Transceiver 202' sind in 12 als mit einem dritten Verbinder C3 elektrisch verbunden gezeigt, wobei C3 ein beliebiger bekannter elektrischer Verbinder sein kann. Bei einer beispielhaften Ausführungsform ist C3 ein herkömmlicher Mini-AB-Verbinder mit der in 3 dargestellten Beinbelegung.
  • Tabelle 3
    Figure 00520001
  • Bei der in 12 dargestellten Ausführungsform ist das Kommunikationsbrückensystem 200' so gezeigt, dass es optional eine zusätzliche Hilfsspeichereinheit 244 um fasst, welche über die Verbindungslogikschaltung 206' mit dem Adress- und Datenbusport ADBUS gekoppelt ist. Die Hilfsspeichereinheit 244 kann eine herkömmliche statische oder dynamische Speicherschaltung einer gewünschten Größe umfassen, die zur Ergänzung der Programm- und/oder Datenspeicherkapazität des DSP 224 verwendet werden kann. Bei einer beispielhaften Ausführungsform des Systems 200' ist die Hilfsspeichereinheit 244 als SRAM mit einer Wortgröße von 32K implementiert. Bei Ausführungsformen des Systems 200', die die Hilfsspeichereinheit 244 enthalten, umfasst die Verbindungslogikschaltung 206' herkömmliche Logikschaltungsmittel, die erforderlich sind, um geeignete Chipwähl- und dergleichen Funktionen vorzusehen, die typischerweise mit dem Betrieb einer Speicherschaltung verbunden sind, wobei derartige herkömmliche Schaltungsmittel, die einen Teil der Verbindungslogikschaltung 206' bilden, generell einem Fachmann vertraut sein werden. Bei der in 12 dargestellten Ausführungsform umfasst die Hilfsspeichereinheit 244 eine Anzahl zusätzlicher Eingänge, die mit einem Speicherport MEM des DSP 224 gekoppelt sind, über den der DSP 224 bestimmte Lese/Schreib-Freigabe/Sperr- und Speicherbytewählfunktionen steuern kann, die typischerweise mit dem Betrieb einer Speicherschaltung und/oder USB-Controllerschaltung verbunden sind. Der Speicherport MEM des DSP 224 wird nachstehend mit Bezug auf 14 näher erläutert.
  • Das System 200' weist ferner eine Anzeigeschaltung 212' sowie eine zugeordnete Anzeigetreiberschaltung 210' auf, welche von einem I/O-Port des DSP 224 gesteuert wird, wie in 12 gezeigt. Die Anzeigeschaltung 212' kann im allgemeinen eine beliebige Anzahl von Sichtanzeigern umfassen, die betriebsmäßig mit einer herkömmlichen Treiberschaltung 210' gekoppelt sind und durch diese gesteuert werden, welche von dem DSP 224 gesteuert wird. Eine Ausführungsform der Schaltungen 212' und 210' kann demgemäß unter Verwendung der LED- und LED-Treiberschaltungen 212 bzw. 210 implementiert sein, die zuvor mit Bezug auf 2 dargestellt und erläutert wurden, wenngleich andere Implementierungen der Schaltungen 210' und 212' vorstellbar sind. Der DSP 224 umfasst außerdem einen Analog/Digital-Spannungsüberwachungsport ADC, der dazu betreibbar ist, die Betriebsspannungen der ein oder mehreren von der Schaltung 210' gebildeten Anzeigetreiber zu überwachen, und außerdem dazu betreibbar ist, andere Betriebsspannungen zu überwachen, die mit dem System 200' verbunden sind, wie nachstehend mit Bezug auf 13 näher erläutert.
  • Bezugnehmend nunmehr auf 13 ist eine Blockdarstellung eines Teils des Kommunikationsbrückensystems 200' gezeigt, die eine Ausführungsform der Anzeigeschaltung 212', der Anzeigetreiberschaltung 210' und der Versorgungs-/Betriebsspannungsüberwachungsanordnung darstellt. Die Anzeigetreiberschaltung 210' ist so gezeigt, dass sie vier und optional fünf Treibertransistoren 2501–2505 aufweist, die jeweils eine mit einem entsprechenden pulsbreitenmodulierten Ausgang PWM0–PWM5 des DSP 224 verbundene Basis, einen mit Masse verbundenen Emitter sowie einen an die Kathode eines entsprechenden von fünf in der Anzeigeschaltung 212' enthaltenen LEDs 2521–2525 angeschlossenen Kollektor aufweisen. Die Anoden der LEDs 2521–2525 sind alle an die Versorgungsspannung VS1 angeschlossen. Bei der dargestellten Ausführungsform sind die Treibertransistoren bipolare NPN-Transistoren, wenngleich andere herkömmliche Treibertransistoren alternativ verwendet werden können. Beispiele solcher anderer Treibertransistoren umfassen Metall-Oxid-Halbleiter- (MOS) Transistoren, bipolare Transistoren mit isoliertem Gate (IGBTs), Feldeffekttransistoren (FETs) oder dergleichen, sind aber nicht hierauf beschränkt. Ein Fachmann wird erkennen, dass die in 13 gezeigte Ausführungsform lediglich veranschaulichend ist und dass herkömmliche passive Unterstützungskomponenten wie Kondensatoren und Widerstände aus Gründen der Einfachheit nicht gezeigt sind und dass andere bekannte Treiber/Anzeigekonfigurationen und -bauelemente ersatzweise verwendet werden können, ohne vom Umfang der Erfindung abzuweichen. Beispielsweise können statt der LEDs andere steuerbare Anzeiger verwendet werden, wobei Beispiele Glühlampen, Flüssigkristallanzeigen, fluoreszierende Vakuumanzeigen, Anzeigen mit Kathodenstrahlröhren oder dergleichen umfassen, jedoch nicht hierauf beschränkt sind. Während die Anzeigetreiberschaltung 210' so dargestellt ist, dass sie in einer niederpegeligen Treiberkonfiguration implementiert ist, kann als weiteres Beispiel die Schaltung 210' alternativ in einer hochpegeligen Treiberkonfiguration implementiert sein, in welchem Fall die Versorgungsspannung VS1 an die Schaltung 210' angeschlossen ist, wie gestrichelt in 12 dargestellt, oder es kann alternativ die Schaltung 210' mit einer bekannten Brückenkonfiguration von zwei oder mehr Transistoren implementiert sein.
  • Bei der dargestellten Ausführungsform sind die Kollektoren der Treibertransistoren 2501–2505 jeweils mit einem entsprechenden Analog/Digital-Eingang A1–A5 des DSP 224 verbunden, wobei der DSP 224 dazu betreibbar ist, die Kollektorspannungen der Treibertransistoren 2501–2505 zu überwachen, um hierdurch den Ein/Aus- und/oder Fehlerstatus jeder der LEDs 2521–2525 zu überwachen. Der DSP 224 weist drei zusätzliche Analog/Digital-Eingänge A0, A6 und A7 auf, welche Spannungen VPS, VBUS bzw. VP erhalten, wobei VPS den in 12 dargestellten Spannungen VE, VS1 oder VS2 entsprechen kann. Alternativ oder zusätzlich kann der DSP 224 die Batteriespannung VB und die Ladespannung VC einzeln oder zusammen überwachen, wie in 12 gestrichelt gezeigt. Wenngleich in den Zeichnungen nicht speziell dar gestellt, können alternativ oder zusätzlich eine oder mehrere weitere Betriebsspannungen, die mit dem System 200' verbunden sind, von dem DSP 224 überwacht werden.
  • Die LEDs 2521–2525 sind vorgesehen, um eine Anzeige des betriebsmäßigen Status der externen Spannung VE sowie eine Anzeige des betriebsmäßigen Status jeder der Kommunikationsschnittstellen zu liefern. Bei einer Ausführungsform beispielsweise ist die LED 2521 der Statusanzeiger für VE, die LED 2522 ist der Statusanzeiger für die J1708/R-485-Kommunikationsschittstelle 216 zum DSP 224 (anschließbar an das SAE J1708-Fahrzeugkommunikationsnetz), die LED 2523 ist der Statusanzeiger für die CAN-Kommunikationsschnittstelle 214 zum DSP 224 (anschließbar an das SAE J1939-Fahrzeugkommunikationsnetz), die LED 2524 ist der Statusanzeiger für die RS-232-Kommunikationsschnittstelle 218 zum DSP 224 (anschließbar an den RS-232-Kommunikationsport eines Fernsystems oder einer Ferneinheit 225) und die LED 2525 ist ein optionaler Statusanzeiger für die optionale USB-Schnittstelle 202' zum DSP 224 (anschließbar an den USB-Kommunikationsport eines Fernsystems oder einer Ferneinheit 225).
  • Der DSP 224 ist dazu ausgelegt, die Anzeiger 2521–2525 in einer Weise zu steuern, die einen Hinweis auf den betriebsmäßigen Status der externen Spannung VE und der verschiedenen Kommunikationsschnittstellen sowie einen Hinweis auf hiermit verbundene Fehler/Ausfall-Zustände liefert. Bei einer Ausführungsform beispielsweise spricht der DSP 224 auf die externe Quellenspannung VE am Eingang AO an, um die LED 2521 in einem „Ein"-Zustand zu halten, wenn VE in einem akzeptablen Spannungsbereich liegt, die LED 2521 in einem „Aus"-Zustand zu halten, wenn VE unter einer Schwellenspannung liegt, die kleiner als der akzeptable Bereich ist (z.B. nahe Massepotential), und die LED 2521 mit einer im Voraus festgelegten Rate (z.B. 1 Hz) periodisch zu aktivieren, wenn VE außerhalb des akzeptablen Bereichs, aber oberhalb der Schwellenspannung liegt. Hinsichtlich der Anzeiger 2522–2525 ist der DSP 224 dazu betreibbar, eine Anzeige von Betriebs- und Fehler/Ausfall-Zuständen zu liefern, die mit jeder der Kommunikationsschnittstellen 214, 216, 218 und 202' verbunden sind, indem er eine entsprechende der LEDs 2522–2525 mit einer ersten vorbestimmten Rate (z.B. 1 Hz) periodisch aktiviert, wenn die betreffende Kommunikationsschnittstelle 214, 216, 218 und 202' als seitens eines entsprechenden der Fahrzeugkommunikationsnetze oder des Fernsystems nicht beantwortet festgestellt wird, eine entsprechende der LEDs 2522–2525 mit einer zweiten vorbestimmten Rate (z.B. 10 Hz) periodisch aktiviert, wenn die entsprechende Kommunikationsschnittstelle 214, 216, 218 und 202' als seitens eines entsprechenden der Fahrzeug kommunikationsnetze oder des Fernsystems beantwortet festgestellt wird und Daten sendet und empfängt, und eine entsprechende der LEDs 2522–2525 in einem „Aus"-Zustand hält, wenn die entsprechende Kommunikationsschnittstelle 214, 216, 218 und 202' keine Daten sendet oder empfängt. Einem Fachmann werden weitere Anzeigesteuerstrategien in den Sinn kommen, wobei derartige weitere Anzeigesteuerstrategien beabsichtigtermaßen in den Umfang der hieran angefügten Ansprüche fallen.
  • Bezugnehmend nunmehr auf 14 ist eine Blockdarstellung eines anderen Teils der Kommunikationsbrücke der 12 gezeigt, die eine Ausführungsform der Eingabe/Ausgabe-Verbindungen zwischen dem DSP 224 und den verschiedenen Kommunikationstransceivern 214, 216, 218 und 202' darstellt. Bei der dargestellten Ausführungsform weist der RS232-Port des DSP 224 einen Datenempfangseingang RS232RX zum Empfangen von Daten von einem Datenempfangsausgang RX des RS-232-Transceivers 218 sowie einen Datensendeausgang RS232TX zum Senden von Daten zu einem Datensendeeingang TX des RS-232-Transceivers 218 auf. Der RS232-Port des DSP 224 umfasst ferner einen Clear-to-Send-Ausgang RS232CTS, welcher mit einem Clear-to-Send-Eingang CTS des RS-232-Transceivers 218 verbunden ist, sowie einen Ready-to-Send-Eingang RS232RTS, welcher mit einem Ready-to-Send-Ausgang RTS des RS-232-Transceivers verbunden ist.
  • Wenn im Betrieb der DSP 224 Daten hat, die er über den RS232-Port zu einem Fernsystem oder einer Ferneinheit 225 senden will, sendet er die Daten über seinen RS232TX-Ausgang zu dem TX-Eingang des RS-232-Transceivers 218. Der RS-232-Transceiver sendet dann die vom DSP 224 erhaltenen Daten, die nach dem RS-232-Kommunikationsprotokoll konfiguriert sind, über einen der Signalwege 2151–215M zu einem mit seinem Datenempfangseingang RXD verbundenen RS-232-Port des Fernsystems oder der Ferneinheit 225. Wenn das Fernsystem oder die Ferneinheit 225 Daten hat, die es bzw. sie zum DSP 224 senden will, sendet es bzw. sie ein geeignetes Signal mit Hilfe des Ready-to-Send-Merkmals des RS-232-Transceivers 218 zum Ready-to-Send-Eingang RS232RTS des DSP 224, wodurch dem DSP 224 signalisiert wird, dass das Fernsystem oder die Ferneinheit 225 bereit zum Senden von RS-232-Daten ist. Der DSP 224 signalisiert seinerseits, wenn er bereit zum Empfang der Daten ist, indem er ein geeignetes Signal zu seinem Clear-to-Send-Ausgang CTS schickt. Das CTS-Merkmal des RS-232-Transceivers 218 sendet das CTS-Signal zum Fernsystem oder zur Ferneinheit 225, und das Fernsystem oder die Ferneinheit 225 bestätigt das CTS-Signal und schickt anschließend die Daten, die nach dem RS-232-Kommunikationsprotokoll konfiguriert sind, zum Empfangseingang RXD des RS- 232-Transceivers 218. Der RS-232-Transceiver 218 übermittelt dann die Daten zum RS232RTS-Eingang des DSP 224 über seinen Datensendeausgang RX.
  • Bei der in 14 dargestellten Ausführungsform umfasst der J1587-Port des DSP 224 einen Datenempfangseingang J1587RX zum Empfang von Daten von einem Datenempfangsausgang RX des J1708/RS-485-Transceivers 216 sowie einen Datensendeausgang J1587TX zum Senden von Daten zu einem Datensendeeingang TX des J1708/RS-485-Transceivers 216. Wenn im Betrieb der DSP 224 Daten hat, die er zu einem oder mehreren der mit dem SAE J1708-Fahrzeugkommunikationsnetz 1081 gekoppelten Steuercomputer senden will, sendet er die Daten über den J1587TX-Ausgang zum TX-Eingang des J1708/RS-485-Transceivers 216. Der J1708/RS-485-Transceiver sendet dann die vom DSP 224 erhaltenen Daten, die nach dem SAE J1587 Kommunikationsprotokoll konfiguriert sind, über die I/Os J1708+ und J1708– zum J1708-Fahrzeugkommunikationsnetz 1081 zum Empfang durch den einen oder die mehreren hiermit gekoppelten Steuercomputer. Wenn einer oder mehrere der mit dem SAE J1708-Fahrzeugkommunikationsnetz gekoppelten Steuercomputer Daten haben, die sie zum DSP 224 senden wollen, senden sie die nach dem SAE J1587-Kommunikationsprotokoll konfigurierten Daten zu den I/Os J1708+ und J1708– des J1708/RS-485-Transceivers 216 über das hiermit gekoppelte J1708-Fahrzeugkommunikationsnetz 1081 . Der J1708/RS-485-Transceiver 216 sendet seinerseits die von dem einen oder den mehreren Steuercomputern erhaltenen Daten über den Datenempfangsausgang RX des J1708/RS-485-Transceivers 216 zum Datenempfangseingang J1587RX des DSP 224.
  • Bei der in 14 dargestellten Ausführungsform weist der CAN-Port des DSP 224 einen Datenempfangseingang CANRX zum Empfang von Daten von einem Datenempfangsausgang RX des CAN-Transceivers 214 sowie einen Datensendeausgang CANTX zum Senden von Daten zu einem Datensendeeingang TX des CAN-Transceivers 216 auf. Zusätzlich weist der CAN-Port des DSP 224 einen mit einem Freigabeeingang E des CAN-Transceivers 214 verbundenen CAN-Freigabeausgang CANE sowie einen mit einem Unterbrechungsausgang IRQ des CAN-Transceivers 216 verbundenen CAN-Bereitschaftseingang CANS auf.
  • Wenn im Betrieb der DSP 224 zum Empfang von Daten von einem oder mehreren der mit dem SAE J1939-Fahrzeugkommunikationsnetz 108N gekoppelten Steuercomputer bereit ist oder Daten zu diesem bzw. diesen zu schicken hat, überwacht er zunächst seinen Bereitschaftseingang CANS. Falls der Zustand des von dem CAN-Transceiver 214 an dessen Unterbrechungsausgang IRQ erzeugten Unterbrechungs signals anzeigt, dass der Transceiver 214 bereit ist, aus dem Bereitschaftsmodus herausgeholt zu werden, erzeugt der DSP 224 ein Signal an seinem Freigabeausgang CANE, das den CAN-Transceiver 214 aus dem Bereitschaftsmodus herausholt. Der DSP 224 sendet dann die Daten über den CANTX-Ausgang zum TX-Eingang des CAN-Transceivers 214. Der CAN-Transceiver 214 sendet dann die vom DSP 224 erhaltenen Daten, die nach dem SAE J1939-Kommunikationsprotokoll konfiguriert sind, über die I/Os J1939+ und J1939– zu dem J1939-Fahrzeugkommunikationsnetz 108N zum Empfang durch den einen oder die mehreren hiermit gekoppelten Steuercomputer. Wenn einer oder mehrere der mit dem SAE J1939-Fahrzeugkommunikationsnetz gekoppelten Steuercomputer Daten haben, die sie zum DSP 224 senden wollen, senden sie die nach dem SAE J1939-Kommunikationsprotokoll konfigurierten Daten zu den I/Os J1939+ und J1939– des CAN-Transceivers 214 über das hiermit gekoppelte J1939-Fahrzeugkommunikationsnetz 108N . Der CAN-Transceiver 214 sendet dann die von dem einen oder den mehreren Steuercomputern erhaltenen Daten über den Datenempfangsausgang RX des CAN-Transceivers 214 zum Datenempfangseingang CANRX des DSP 224.
  • Bei dem mit Bezug auf 12 dargestellten und beschriebenen Kommunikationsbrückensystem 200' wurden der Hilfsspeicher 244 und/oder der USB-Controller/Transceiver 202' als optional bei dieser Ausführungsform bezeichnet, weswegen diese Bauelemente ebenso wie die unterstützenden Schaltungsmittel und die Schnittstelle dieser Komponenten zum DSP 224 in 14 gestrichelt gezeichnet sind. Bei der in 14 dargestellten Ausführungsform umfasst der Adress- und Datenbusport ABUS des DSP 224 16 Adress-I/Os und 16 Daten-I/Os A0–A15 bzw. D0–D15, die mit entsprechenden Adress- und Daten-I/Os A0–A15 und D0–D15 der Verbindungslogikschaltung 206' verbunden sind. Auch ein Programmspeicherwähl- (PMS) und ein Datenspeicherwähl- (DMS) Ausgang des MEM-Ports sind mit einem entsprechenden Programmspeicherfreigabe- (PME) bzw. einem Datenspeicherfreigabe- (DME) Eingang der Verbindungslogikschaltung 206' verbunden. Der DSP 224 ist dazu betreibbar, über diese Adress-, Daten- und Steuerleitungen mit dem USB-Controller/Transceiver 202' sowie der Hilfsspeichereinheit 244 zu kommunizieren und den Datenfluss zu diesen und von diesen zu transportieren und zu steuern, wie oben beschrieben.
  • Wie zuvor mit Bezug auf 12 beschrieben, weist der DSP 224 einen Ausgabeport MEM auf, um den Hilfsspeicher 244 mit Lese/Schreib-Freigabe/Sperr- sowie Speicherbytewählsignalen zu versorgen. Beispielsweise weist der MEM-Port des DSP 224 einen Schreibfreigabeausgang WE sowie einen Lesefreigabeausgang RE auf, die mit einem entsprechenden Schreibfreigabeeingang WE bzw. Lesefreigabeeingang RE der Hilfsspeichereinheit 244 und des USB-Controllers/Transceivers 202' verbunden sind. Der DSP 224 ist dazu betreibbar, mittels geeigneter am WE- und RE-Ausgang erzeugter Signale die Hilfsspeichereinheit 244 und/oder den USB-Controller/Transceiver 202' selektiv freizugeben, um Daten zu dieser bzw. diesem zu schreiben und Daten von dieser bzw. diesem zu lesen. Bei Ausführungsformen schließlich, bei denen die Hilfsspeichereinheit 244 als SRAM vorgesehen ist, umfasst der MEM-Port des DSP 224 einen SRAM-Zugriffsfreigabeausgang SLE für das untere Byte sowie einen SRAM-Zugriffsfreigabeausgang SUE für das obere Byte, die mit einem entsprechenden SLE- und SUE-Eingang der Hilfsspeichereinheit 244 verbunden sind. Über geeignete an dem SLE- und dem SUE-Ausgang erzeugte Signale kann der DSP 224 wahlweise den Zugriff auf untere und obere Bytes des SRAM-Speichers freigeben.
  • Wie ebenfalls zuvor mit Bezug auf 12 erläutert, umfasst der DSP 224 einen USB-Steuerport USB zum Steuern bestimmter Portkonfigurations- und Datentransferfunktionen, die mit dem USB-Controller/Transceiver 202' verbunden sind. Beispielsweise weist der USB-Steuerport des DSP 224 einen ersten und einen zweiten Unterbrechungseingang IRQA bzw. IRQB auf, die mit einem entsprechenden Host- und Gerät-Unterbrechungsausgang IRQH bzw. IRQD des USB-Controllers/Transceivers 202' verbunden sind. Der DSP 224 steuert außerdem den Datenfluss zwischen sich und dem USB-Controller/Transceiver 202' über den Lese- und den Schreibfreigabeausgang RE bzw. WE des MEM-Ports, wie vorstehend beschrieben. Der USB-Steuerport des DSP 224 weist ferner einen Rückstellausgang R sowie einen On-The-Go-Freigabeausgang OTGE auf, die mit einem entsprechenden On-The-Go-Rückstelleingang OTGR bzw. einem entsprechenden On-The-Go-Freigabeeingang OTGE des USB-Controllers/Transceivers 202' verbunden sind. Schließlich weist der USB-Steuerport des DSP 224 einen Hoststeueraussetzungsausgang SHC sowie einen Gerätesteueraussetzungsausgang SDC auf, die mit einem entsprechenden SHC-Eingang bzw. SDC-Eingang des USB-Controllers/Transceivers 202' verbunden sind.
  • Die Kommunikation zwischen dem DSP 224 und einem Fernsystem oder einer Ferneinheit 225 über den USB-Controller/Transceiver 202' kann erfolgen, während der USB-Controller/Transceiver entweder als USB-Host oder als USB-Gerät dient, wobei sein USB-Kommunikationsport als standardmäßiger USB-Hostport, als standardmäßiger USB-Geräteport oder als On-The-Go-USB-Port mit sowohl Host- als auch Gerätefähigkeiten konfiguriert ist. Der USB-Steuerport des DSP 224 und die entsprechenden I/Os des USB-Controllers/Transceivers 202' steuern in ähnlicher Weise wie der vorstehend beschriebene CAN-Controller den zeitlichen Ablauf des Datentransfers zwischen dem DSP 224 und dem Fernsystem oder der Ferneinheit 225, wohingegen der eigentliche Datentransfer zwischen dem DSP und dem USB-Controller/Transceiver 202' über den Adress- und Datenbusport ADBUS und den einen oder die mehreren Signalwege 245 abgewickelt wird, die den USB-Controller/Transceiver 202' mit der Verbindungslogikschaltung 206' koppeln.
  • Wenn im Betrieb der DSP 224 Daten hat, die er über einen der Signalwege 2151–215M an ein Fernsystem oder eine Ferneinheit 225 senden will, konfiguriert er zunächst über Adress-/Datenbus- (ADBUS) Schreibtransaktionen geeignet den USB-Controller/Transceiver 202' und überwacht dann seine Unterbrechungseingänge IRQA und IRQB auf Ereignisse, die Datenkommunikationsaktivitäten des USB-Controllers/Transceivers beinhalten. Wenn der USB-Controller/Transceiver 202' als Host konfiguriert ist und wenn der USB-Kommunikationsport des USB-Controllers/Transceivers 202' als standardmäßiger USB-Hostport zu konfigurieren ist, erzeugt der DSP 224 dann, wenn der Zustand des vom IRQH-Ausgang des USB-Controllers/Transceivers 202' erzeugten Unterbrechungssignals anzeigt, dass der USB-Controller/Transceiver 202' bereit ist, Daten oder Statusinformationen, die Kommunikationsereignisse betreffen, zum DSP 224 zu senden, geeignete Adress-/Datenbus- (ADBUS) sowie Steuersignale, um die Informationen aufzunehmen. Der DSP 224 erzeugt an seinen SHC-, SDC- und OTGE-Ausgängen geeignete Signale, um den Betrieb des USB-Gerätecontrollers auszusetzen, den OTG-Controller zu deaktivieren und ihn in einem gesperrten Zustand zu halten und den Betrieb des USB-Hostcontrollers freizugeben. Wenn der DSP 224 eine Rückstellbedingung durchläuft, wie sie etwa durch einen Abfall der Versorgungsspannung oder ein Watchdog-Auszeitereignis hervorgerufen wird, wird sein Rückstellausgangssignal R aktiv und stellt den USB-Controller/Transceiver 202' in dessen vorkonfigurierten Zustand zurück. Wenn jedoch der USB-Kommunikationsport des USB-Controllers/Transceivers 202' als On-The-Go-Port zu konfigurieren ist, erzeugt der DSP 224 stattdessen geeignete Signale an seinen SHC-, SDC- und OTGE-Ausgängen, um den Betrieb der USB-Host- und Gerätecontroller auszusetzen und den Betrieb des USB-On-The-Go-Controllers als Hostport freizugeben.
  • Wenn dagegen der USB-Controller/Transceiver 202' als Gerät konfiguriert ist und wenn der USB-Kommunikationsport des USB-Controllers/Transceivers 202' als standardmäßiger USB-Geräteport zu konfigurieren ist, so erzeugt der DSP 224 dann, wenn der Zustand des vom IRQD-Ausgang des USB-Controllers/Transceivers 202' erzeugten Unterbrechungssignals anzeigt, dass der USB-Controller/Transceiver 202' bereit ist, Daten oder Statusinformationen, die Kommunikationsereignisse betreffen, zum DSP 224 zu senden, geeignete Adress-/Datenbus- (ADBUS) und Steuersignale, um die Informationen aufzunehmen. Der DSP 224 erzeugt geeignete Signale an seinen SHC-, SDC- und OTGE-Ausgängen, um den Betrieb des USB-Hostcontrollers auszusetzen, den OTG-Controller zu deaktivieren und ihn in einem gesperrten Zustand zu halten und den Betrieb des USB-Gerätecontrollers freizugeben. Wenn der DSP 224 eine Rückstellbedingung durchläuft, wie sie etwa durch einen Abfall der Versorgungsspannung oder ein Watchdog-Auszeitereignis hervorgerufen wird, wird sein Rückstellausgangssignal R aktiv und stellt den USB-Controller/Transceiver 202' in dessen vorkonfigurierten Zustand zurück. Wenn jedoch der USB-Kommunikationsport des USB-Controllers/Transceivers 202' als On-The-Go-Port zu konfigurieren ist, erzeugt der DSP 224 stattdessen geeignete Signale an seinen SHC-, SDC- und OTGE-Ausgängen, um den Betrieb der USB-Host- und Gerätecontroller auszusetzen und den Betrieb des USB-On-The-Go-Controllers als Geräteport freizugeben.
  • Sobald das Fernsystem oder die Ferneinheit 225 dem DSP 224 über den USB-Controller/Transceiver 202' signalisiert hat, dass es bzw. sie zum Empfang von Daten bereit ist, und der USB-Controller/Transceiver 202' ordnungsgemäß konfiguriert ist, wie soeben beschrieben, sendet der DSP 224 die eigentlichen Daten über die Verbindungslogikschaltung 206' zum USB-Controller/Transceiver 202' über den Adress- und Datenbusport ADBUS und den einen oder die mehreren Signalwege 245 zusammen mit den erforderlichen Schreib- und Wählsteuersignalen. Danach sendet der USB-Controller/Transceiver 202' die vom DSP 224 erhaltenen Daten – konfiguriert nach dem USB-Kommunikationsprotokoll – zum USB-Port des Fernsystems oder der Ferneinheit 225 über die I/Os D+ und D–, die mit einem der hieran angeschlossenen Signalwege 2151–215M verbunden sind.
  • Wenn ein Fernsystem oder eine Ferneinheit 225 Daten hat, die über einen der Signalwege 2151–215M an den DSP 224 gesendet werden sollen, sendet es bzw. sie die Daten – konfiguriert nach dem USB-Kommunikationsprotokoll – zu den I/Os D+ und D– des USB-Controllers/Transceivers 202' über einen der hieran angeschlossenen Signalwege 2151–215M . Nach einer weiteren USB-Controller/Transceiver-Unterbrechungssequenz, wie soeben beschrieben, übermittelt der USB-Controller/Transceiver 224 dann die von dem Fernsystem oder der Ferneinheit 225 erhaltenen Daten über die Verbindungslogikschaltung 206' zum DSP 224 über den einen oder die mehreren Signalwege 245 und den Adress- und Datenbusport ADBUS zusammen mit den erforderlichen Lese- und Wählsteuersignalen.
  • Bei einer Ausführungsform ist das hier soweit mit Bezug auf die 11–14 dargestellte und beschriebene Kommunikationsbrückensystem 200' ferner zum automati schen Rückstellen ausgelegt, wenn der DSP 224 kodierte Befehle nicht mehr ordnungsgemäß ausführt, und zum Energiesparen bei Erkennung von Perioden der Inaktivität. Bei dieser Ausführungsform ist der DSP 224 beispielsweise dazu ausgelegt, eine das ordnungsgemäße Arbeiten (Operating Properly; OP) überwachende Watchdog-Zeitgeberfunktion aufzuweisen, die dazu betreibbar ist, den DSP 224 rückzustellen, derart, dass der DSP 224 jedes Mal eine Rückstellsequenz ausführt, wenn ein Watchdog-Zeitgeber im DSP 224 vor einer im Voraus festgelegten Auszeitperiode von z.B. 200 ms nicht ordnungsgemäß beschrieben wird. Der Watchdog-Zeitgeber wird freigegeben, wenn sich der DSP 224 im Wartemodus befindet.
  • Wenn für eine im Voraus festgelegte Zeitdauer von z.B. 30 Sekunden keine RS-232- oder USB-Kommunikation detektiert wird, kann der DSP 224 in einen Wartemodus eintreten. Der DSP 224 bleibt in dem Wartemodus, bis eine durch USB- oder RS-232-Kommunikation erhaltene Unterbrechung festgestellt wird. Wird für eine im Voraus festgelegte Zeitdauer von z.B. 30 Sekunden keine USB-Kommunikation erfasst, wird der USB-OTG-Controller in einen Energiesparmodus versetzt, in dem er bleibt, bis eine neue USB-Kommunikation erfasst wird oder ein Zugriff auf ein USB-Controllerregister erfolgt. In ähnlicher Weise ist der DSP 224 dazu betreibbar, den RS-232-Transceiver 218 in einen inaktiven Stoppmodus zu versetzen, in dem dieser bleibt, bis eine durch RS-232-Kommunikation erhaltene Unterbrechung festgestellt wird, nachdem für eine im Voraus festgelegte Zeitdauer von z.B. 30 Sekunden keine RS-232-Kommunikation erfasst wurde. Gleichfalls ist der DSP 224 dazu betreibbar, den J1587-Port in einen inaktiven Stoppmodus zu versetzen, in dem dieser bleibt, bis eine durch J1708-Kommunikation erhaltene Unterbrechung festgestellt wird, nachdem für eine im Voraus festgelegte Zeitdauer von z.B. 30 Sekunden keine J1708-Kommunikation erfasst wurde. Außerdem ist der DSP 224 dazu betreibbar, seine CAN-Controllerschaltung in einen Energieabschalt-Stoppmodus zu versetzen, bis eine neue Kommunikation empfangen wird, nachdem für eine im Voraus festgelegte Zeitdauer von z.B. 30 Sekunden keine J1939-Kommunikation erfasst wurde.
  • Die Sendeausgänge des CAN-Transceivers 214 und des J1708/RS-485-Transceivers 216 bleiben in einem rezessiven Zustand, wenn sie nicht kommunizieren. Befindet sich der DSP in einem normalen Betriebsmodus, werden der CAN-Transceiver 214 und die CAN-Controllerschaltung des DSP 224 in einen normalen Arbeitsmodus aktiviert, wenn seitens des CAN-Transceivers 214 eine J1939-Kommunikation erfasst wird.
  • Wenn die niedrige Versorgungsspannung VS2 unter eine Schwellenspannung von z.B. 2,7 Volt fällt, wobei VS2 nominell 3,3 Volt beträgt, wird im DSP 224 eine für eine niedrige Spannung repräsentative Unterbrechung erzeugt, sodass sich der DSP 224 für das Abschalten vorbereitet.
  • Das soeben beschriebene Kommunikationsbrückensystem 200' ist voll konform zu dem RP-1210A-Standard für PC/Datenverbindung-Schnittenstellen für Lastkraftwagen, d.h. für CAN/J1939-, J1708/J1587-, RS-232- und USB-Kommunikationsschnittstellen. Es ist in der Lage, mit mehreren von dem Kraftfahrzeug 100 mitgeführten Steuercomputern über eines oder mehrere der Fahrzeugkommunikationsnetze 1081–108N zu kommunizieren. Es ist außerdem in der Lage, eine Kommunikation zwischen einem oder mehreren der von dem Kraftfahrzeug 100 mitgeführten Steuercomputer und einem Fernsystem oder einer Ferneinheit 225 über eine USB-Kommunikationsverbindung oder eine RS-232-Verbindung mit einem oder mehreren anderen Kommunikationsbrückensystemen 200' durchzuführen, die gleichzeitig eine Kommunikation zwischen einem oder mehreren anderen Steuercomputern, die von einem oder mehreren anderen Fahrzeugen mitgeführt werden, und dem Fernsystem durchführen.
  • Der von dem DSP 224 getragene Flash-Speicher ist umprogrammierbar als eine für sich stehende Funktion und ist außerhalb des Systems 200' entweder durch den RS-232-Transceiver 218 oder den USB-Controller/Transceiver 202' bei Ausführungsformen des Systems 200', die den USB-Controller/Transceiver 202' enthalten, umprogrammierbar.
  • Wie vorstehend beschrieben, kann der DSP 224 mit einem digitalen DSP56F807-Signalprozessor realisiert werden. Der DSP56F807 ist als integrierte Schaltung mit einem Gehäuse mit 160 Beinen erhältlich, wobei die folgende Tabelle 4 eine I/O-Konfiguration des DSP56F807 wiedergibt, wie sie sich auf das vorstehend gezeigte und beschriebene System 200' bezieht. Wo zweckmäßig; sind die Namen der I/O-Ports oder Beine des DSP56F807 in Tabelle 4 durch Klammerausdrücke in Beziehung zu ihren entsprechenden Ports oder I/Os gebracht, die in Zusammenhang mit den 12–14 dargestellt und erläutert wurden.
  • Tabelle 4
    Figure 00640001
  • Figure 00650001
  • Figure 00660001
  • Figure 00670001
  • Figure 00680001
  • Figure 00690001
  • Figure 00700001
  • Bezugnehmend nunmehr auf 15 ist ein Ablaufdiagramm gezeigt, das eine Ausführungsform eines Prozesses oder Algorithmus zur Informationsübertragung von einem oder beiden der J1708- und J1939-Fahrzeugkommunikationsnetze (entweder unabhängig oder gleichzeitig) zu einem zur Kommunikation nach dem RS-232-Kommunikationsprotokoll ausgelegten Fernsystem oder einer Ferneinheit 225 über das Kommunikationsbrückensystem 200' der 11- 14 darstellt. Der Algorithmus beginnt bei Schritt 1102, und bei Schritt 1104 werden serielle Informationen, die von einem oder mehreren von dem Fahrzeug 100 mitgeführten Steuercomputern erzeugt werden, seitens des Kommunikationsbrückensystems 200' über eines oder beide der zwei Fahrzeugkommunikationsnetze empfangen, die vorstehend mit Bezug auf die 12–14 beschrieben wurden. Das erste Fahrzeugkommunikationsnetz ist das SAE J1708-Fahrzeugkommunikationsnetz 1081 , das zur Kommunikation nach dem SAE J1587-Kommunikationsprotokoll ausgelegt ist und über die Kommunikationsverbindung 1201 mit dem J1708/RS-485-Transceiver 216 gekoppelt ist. Bei Schritt 1104 können die empfangenen seriellen Informationen serielle Informationen umfassen, die vom Fahrzeugkommunikationsnetz 1081 geführt und an den I/Os J1708+ und J1708– des J1708/RS-485-Transceivers 216 empfangen wurden. Das zweite Fahr zeugkommunikationsnetz ist das SAE J1939-Fahrzeugkommunikationsnetz 108N , das zur Kommunikation nach dem SAE J1939-Kommunikationsprotokoll ausgelegt ist und über die Kommunikationsverbindung 120N mit dem CAN-Transceiver 214 gekoppelt ist. Bei Schritt 1104 können die empfangenen seriellen Informationen serielle Informationen umfassen, die vom Fahrzeugkommunikationsnetz 108N geführt und an den I/Os J1939+ und J1939– des CAN-Transceivers 214 empfangen wurden. In jedem Fall wandelt der J1708/RS-485-Transceiver 216 alle seriellen Daten, die an ihn geliefert wurden, so um, wie es für eine Verarbeitung durch die serielle Kommunikationsschnittstelle (SCI) J1587 des DSP 224 erforderlich ist, und der CAN-Transceiver 214 wandelt alle seriellen Daten, die an ihn geliefert werden, so um, wie es erforderlich ist für eine Verarbeitung durch die CAN-Controllerschnittstelle CAN des DSP 224. Danach werden bei Schritt 1106 die umgewandelten seriellen Daten seitens einer oder beider der J1587 SCI und der CAN-Controllerschnittstelle CAN des DSP 224 empfangen.
  • Nach dem Schritt 1106 geht der Prozess weiter zu Schritten 1108–1110, wo der DSP 224 die J1587 SCI und/oder seinen CAN-Controller nach neuen Daten in einem kontinuierlichen Abfragezyklus abfragt. (Der vollständige Abfragezyklus umfasst das Abfragen auch aller anderen Schnittstellen). Während jedes Zyklus werden jegliche neuen Rohdaten bei Schritt 1112 gelesen und in einem Datenspeicher gespeichert, der entweder dem DSP 224, der Hilfsspeichereinheit 244 oder einem anderen externen Speicher zugeordnet sein kann. Hinsichtlich seines CAN-Controllers kann der DSP 224 alternativ warten und so, wie soeben beschrieben, bei Schritt 1112 auf eine Unterbrechung ansprechen, die von dem CAN-Controller im DSP 224 erzeugt wird, wenn Daten seitens desselben empfangen werden. In jedem Fall sind sowohl Abfragesoftware als auch Unterbrechungsbehandlungsroutinen in der Fachwelt wohlbekannt, und ein Fachmann wird erkennen, dass beide Vorgehensweisen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • Anschließend setzt bei Schritt 1114 der DSP 224 jegliche vom J1708/RS-485-Transceiver 216 und/oder vom CAN-Transceiver 214 empfangenen Rohdaten zu Nachrichten zusammen, wobei der DSP 224 bei Schritt 1116 ermittelt, ob irgendwelche dieser Nachrichten zur Übertragung zu einem Fernsystem oder einer Ferneinheit 225 über eine RS-232-Kommunikatonsverbindung bestimmt sind. Falls nicht, werden die Nachrichten bei Schritt 1118 verworfen. Bei Ausführungsformen des Systems 200', die den USB-Controller/Transceiver 202' enthalten, kann ein zusätzlicher Entscheidungsschritt zwischen die Schritte 1116 und 1118 eingefügt sein, bei dem der DSP 224 eine Feststellung macht, ob irgendwelche der Nachrichten, die nicht zur RS- 232-Übertragung bestimmt sind, stattdessen zur Übertragung über eine USB-Kommunikationsverbindung zu einem Fernsystem oder einer Ferneinheit 225 bestimmt sind. Falls nicht, kann der Prozess dann weitergehen zu Schritt 1118, wo die Nachrichten verworfen werden. Falls jedoch Nachrichten zur USB-Übertragung zu einem Fernsystem oder einer Ferneinheit 225 bestimmt sind, kann der Prozess weitergehen zu einem USB-Datenübertragungsprozess, von dem eine beispielhafte Ausführungsform nachfolgend in näherer Einzelheit mit Bezug auf 17 erläutert wird.
  • Im Anschluss an Schritt 1116 rückt der Prozess vor zu Schritt 1120, wo der DSP 224 die zusammengesetzten Nachrichten an seine RS232 SCI sendet. Danach formatiert die RS232 SCI bei Schritt 1122 die zusammengesetzten Nachrichten zu einem seriellen Bitstrom nach dem RS-232-Kommunikationsprotokoll um. Daraufhin sendet bei Schritt 1124 der DSP 224 die zusammengesetzten und umformatierten Nachrichten zum RS-232-Transceiver 218, wie zuvor mit Bezug auf 14 beschrieben, und nach dem Schritt 1124 geht der Prozess weiter zu Schritt 1126, wo der RS-232-Transceiver 218 die zusammengesetzten, nach dem RS-232-Kommunikationsprotokoll umformatierten Nachrichten über einen geeigneten der Kommunikationswege 2151–215M an eine mit dem RS-232-Transceiver 218 gekoppelte RS-232-Kommunikationsschnittstelle des Fernsystems oder der Ferneinheit 225 übermittelt. Nach dem Schritt 1126 oder dem Schritt 1118 endet der Prozess bei Schritt 1128 und kehrt zum „Start"-Schritt 1102 zurück.
  • Bezugnehmend nunmehr auf 16 ist ein Ablaufdiagramm gezeigt, das eine Ausführungsform eines Prozesses oder Algorithmus zur Informationsübertragung von dem Fernsystem oder der Ferneinheit 225, das bzw. die zur Kommunikation nach dem RS-232-Kommunikationsprotokoll konfiguriert ist, über das Kommunikationsbrückensystem 200' der 11–14 zu dem J1708- oder J1939-Fahrzeugkommunikationsnetz darstellt. Der Prozess beginnt bei Schritt 1152, und bei Schritt 1154 werden serielle Informationen, die von dem Fernsystem oder der Ferneinheit 225 gesendet wurden und nach dem RS-232-Kommunikationsprotokoll konfiguriert sind, über einen geeigneten der Kommunikationswege 2151–215M seitens des RS-232-Transceivers 218 empfangen, der mit dem Fernsystem oder der Ferneinheit 225 gekoppelt ist. Danach liefert bei Schritt 1156 der RS-232-Transceiver die seriellen Informationen zur RS232 SCI des DSP 224. Nach Schritt 1156 geht der Prozess weiter zu Schritten 1158–1160, wo der DSP 224 die RS232 SCI in einem kontinuierlichen Abfragezyklus nach neuen Daten abfragt. Während jedes Zyklus werden bei Schritt 1162 jegliche neuen Rohdaten gelesen und in einem Datenspeicher gespeichert, welcher entweder dem DSP 224, der Hilfsspeichereinheit 244 oder einem anderen externen Speicher zugeordnet sein kann. Alternativ kann der DSP 224 warten und so, wie soeben beschrieben, bei Schritt 1162 auf eine Unterbrechung ansprechen, die seitens der RS-232 SCI im DSP 224 erzeugt wird, wenn Daten von derselben empfangen werden. In jedem Fall sind sowohl Abfragesoftware als auch Unterbrechungsbehandlungsroutinen in der Fachwelt wohlbekannt, und ein Fachmann wird erkennen, dass beide Vorgehensweisen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • Anschließend setzt der DSP 224 bei Schritt 1164 alle vom RS-232-Transceiver 218 erhaltenen Rohdaten zu Nachrichten zusammen, wobei der DSP 224 bei Schritt 1166 ermittelt, ob irgendwelche der Nachrichten zur Übertragung zum J1708-Fahrzeugkommunikationsnetz oder zum J1939-Fahrzeugkommunikationsnetz bestimmt sind. Nachrichten, die für kein Fahrzeugkommunikationsnetz bestimmt sind, werden bei Schritt 1168 verworfen. Für Nachrichten, die entweder für das J1708- oder das J1939-Fahrzeugkommunikationsnetz bestimmt sind, ist der DSP 224 dazu betreibbar, nach dem Schritt 1166 solche Nachrichten bei Schritt 1170 zu geeigneten Datenpaketen mit Adressen umzuformen. Nachrichten, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 nach dem SAE J1587-Kommunikationsprotokoll umformatiert, und Nachrichten, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 nach dem SAE J1939-Kommunikationsprotokoll umformatiert.
  • Im Anschluss an den Schritt 1170 geht der Prozess weiter zu Schritt 1172, wo der DSP 224 die umformatierten Datenpakete zu einem geeigneten Schnittstellenport sendet. Solche Pakete, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zu dessen J1587 SCI gesendet, und solche Pakete, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zu dessen CAN-Controller gesendet. Danach sendet der DSP 224 bei Schritt 1174 die umformatierten Datenpakete zu einem geeigneten Transceiver zur Übertragung zu einem entsprechenden der Fahrzeugkommunikationsnetze. Solche Pakete, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zum J1708/RS-485-Transceiver 216 gesendet, und solche Pakete, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zum CAN-Transceiver 214 gesendet. Die Transceiver 216 und/oder 214 sind dazu betreibbar, nach dem Schritt 1176 die zu ihnen vom DSP 224 gelieferten Daten zu einem oder mehreren der vom Fahrzeug 100 mitgeführten und mit einem oder beiden der Fahrzeugkommunikationsnetze gekoppelten Steuercomputer zu übertragen. Beispielsweise ist der J1708/RS-485-Transceiver 216 über die Kommunikationsverbindung 1201 mit dem J1708-Fahrzeugkommunikationsnetz 1081 gekoppelt, wobei der J1708/RS-485-Transceiver dazu betreibbar ist, bei Schritt 1176 die ihm vom DSP 224 zugeführten Daten, die zur Kommunikation nach dem SAE J1587-Kommunikationsprotokoll konfiguriert sind, zu einem oder mehreren mit dem J1708-Fahrzeugkommunikationsnetz 1081 gekoppelten fahrzeuginternen Steuercomputern zu übermitteln. In gleicher Weise ist der CAN-Transceiver 214 über die Kommunikationsverbindung 120N mit dem J1939-Fahrzeugkommunikationsnetz 108N gekoppelt, wobei der CAN-Transceiver 214 dazu betreibbar ist, bei Schritt 1176 die ihm vom DSP 224 zugeführten Daten, die zur Kommunikation nach dem SAE J1939-Kommunikationsprotokoll konfiguriert sind, zu einem oder mehreren mit dem J1939-Fahrzeugkommunikationsnetz 108N gekoppelten fahrzeuginternen Steuercomputern zu übermitteln. Der Prozess geht vom Schritt 1176 oder vom Schritt 1168 weiter zu Schritt 1178, wo der Prozess endet und dann zum „Start"-Schritt 1152 zurückkehrt.
  • Bezugnehmend nunmehr auf 17 ist ein Ablaufdiagramm gezeigt, das eine Ausführungsform eines Prozesses oder Algorithmus zur Informationsübertragung von einem oder beiden der J1708- und J1939-Fahrzeugkommunikationsnetze (entweder unabhängig oder gleichzeitig) über das Kommunikationsbrückensystem 200' der 11–14 zu einem zur Kommunikation nach dem USB-Kommunikationsprotokoll konfigurierten Fernsystem oder einer Ferneinheit 225 darstellt. Der Algorithmus beginnt bei Schritt 1202, und bei Schritt 1204 werden serielle Informationen, die von einem oder mehreren von dem Fahrzeug 100 mitgeführten Steuercomputern erzeugt werden, seitens des Kommunikationsbrückensystems 200' über eines oder beide der zwei vorstehend mit Bezug auf die 12–14 beschriebenen Fahrzeugkommunikationsnetze empfangen. Das erste Fahrzeugkommunikationsnetz ist das SAE J1708-Fahrzeugkommunikationsnetz 1081 , das zur Kommunikation nach dem SAE J1587-Fahrzeugkommunikationsprotokoll ausgelegt und über die Kommunikationsverbindung 1201 mit dem J1708/RS-485-Transceiver 16 gekoppelt ist. Bei Schritt 1204 können die empfangenen seriellen Informationen serielle Informationen umfassen, die vom Fahrzeugkommunikationsnetz 1081 geführt und an den I/Os J1708+ und J1708– des J1708/RS-485-Transceivers 216 empfangen werden. Das zweite Fahrzeugkommunikationsnetz ist das SAE J1939-Fahrzeugkommunikationsnetz 108N , das zur Kommunikation nach dem SAE J1939-Fahrzeugkommunikationsprotokoll ausgelegt ist und über die Fahrzeugkommunikationsverbindung 120N mit dem CAN-Transceiver 214 gekoppelt ist. Bei Schritt 1204 können die empfangenen seriellen Informationen serielle Informationen umfassen, die vom Fahrzeugkommunikationsnetz 108N geführt und an den I/Os J1939+ und J1939– des CAN-Transceivers 214 empfangen werden. In jedem Fall wandelt der J1708/RS-485-Transceiver 216 alle ihm zugeführten seriellen Daten so um, wie es erforderlich für eine Verarbeitung durch die serielle Kommunikationsschnittstelle (SCI) J1587 des DSP 224 ist, und der CAN-Transceiver 214 wandelt alle ihm zugeführten seriellen Daten so um, wie es erforderlich für eine Verarbeitung durch die CAN-Controllerschnittstelle CAN des DSP 224 ist. Danach werden bei Schritt 1206 die umgewandelten seriellen Daten seitens einer oder beider der J1587 SCI und der CAN-Controllerschnittstelle CAN des DSP 224 empfangen.
  • Nach dem Schritt 1206 geht der Prozess weiter zu Schritten 1208–1210, wo der DSP 224 die J1587 SCI und/oder seinen CAN-Controller in einem kontinuierlichen Abfragezyklus nach neuen Daten abfragt. (Der vollständige Abfragezyklus umfasst das Abfragen auch aller anderen Schnittstellen). Während jedes Zyklus werden bei Schritt 1212 jegliche neuen Rohdaten gelesen und in einem Datenspeicher gespeichert, welcher entweder dem DSP 224, der Hilfsspeichereinheit 244 oder einem anderen externen Speicher zugeordnet sein kann. Hinsichtlich seines CAN-Controllers kann der DSP 224 alternativ warten und so, wie soeben beschrieben, bei Schritt 1212 auf eine Unterbrechung ansprechen, die von dem CAN-Controller im DSP 224 erzeugt wird, wenn seitens desselben Daten empfangen werden. In jedem Fall sind Abfragesoftware und Unterbrechungsbehandlungsroutinen in der Fachwelt wohlbekannt, und ein Fachmann wird erkennen, dass beide Vorgehensweisen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • Anschließend setzt bei Schritt 1214 der DSP 224 alle vom J1708/RS-485-Transceiver 216 und/oder vom CAN-Transceiver 214 erhaltenen Rohdaten zu Nachrichten zusammen, wobei der DSP bei Schritt 1216 ermittelt, ob irgendwelche dieser Nachrichten zur Übertragung zu einem Fernsystem oder einer Ferneinheit 225 über eine USB-Kommunikationsverbindung bestimmt sind. Falls nicht, werden die Nachrichten bei Schritt 1218 verworfen. Bei Ausführungsformen des Systems 200', die sowohl den USB-Controller/Transceiver 202' als auch einen RS-232-Transceiver 218 aufweisen, kann ein zusätzlicher Entscheidungsschritt zwischen den Schritten 1216 und 1218 eingefügt sein, bei dem der DSP 224 eine Feststellung macht, ob irgendeine der nicht zur USB-Übertragung bestimmten Nachrichten stattdessen zur Übertragung über eine RS-232-Kommunikationsverbindung zu einem Fernsystem oder zu einer Ferneinheit 225 bestimmt ist. Falls nicht, geht der Prozess dann weiter zu Schritt 1218, wo alle Nachrichten verworfen werden. Falls jedoch irgendwelche Nachrichten zur RS-232-Übertragung zu einem Fernsystem oder einer Ferneinheit 225 bestimmt sind, rückt der Prozess vor zu einem RS-232-Datenübertragungsprozess, von dem eine beispielhafte Ausführungsform vorstehend mit Bezug auf 15 erläutert wurde.
  • Im Anschluss an den Schritt 1216 geht der Prozess weiter zu Schritt 1220, wo der DSP 224 die zusammengesetzten Nachrichten in Datenrahmen umformatiert, die zur Kommunikation nach dem USB-Kommunikationsprotokoll ausgelegt sind, und anschließend sendet der DSP 224 bei Schritt 1222 die zusammengesetzten Nachrichten über seinen ADBUS I/O-Port in der vorstehend beschriebenen Weise zum USB-Controller/Transceiver 202'. Danach ermittelt der USB-Controller/Transceiver 202' bei Schritt 1224, ob die Rahmen als USB-Hostdatenrahmen oder USB-Gerätedatenrahmen konfiguriert sind. Wenn sie UBS-Hostrahmen sind, geht der Prozess vom Schritt 1224 zu Schritt 1226, wo der USB-Controller 202' in Kooperation mit dem DSP 224 dessen USB-Kommunikationsport als Geräteport konfiguriert. Alternativ kann der USB-Controller 202' in Kooperation mit dem DSP 224 bei Schritt 1226 seinen USB-Kommunikationsport als On-The-Go- (OTG) Port mit USB-Gerätefähigkeiten konfigurieren, wie oben beschrieben. Falls bei Schritt 1224 die USB-Datenrahmen vom USB-Controller/Transceiver 202' als USB-Gerätedatenrahmen festgestellt werden, geht der Prozess vom Schritt 1224 weiter zu Schritt 1228, wo der USB-Controller 202' in Kooperation mit dem DSP 224 seinen USB-Kommunikationsport als Hostport konfiguriert. Alternativ kann der USB-Controller 202' in Kooperation mit dem DSP 224 bei Schritt 1228 seinen USB-Kommunikationsport als On-The-Go- (OTG) Port mit beschränkten USB-Hostfähigkeiten konfigurieren, wie oben beschrieben.
  • In jedem Fall rückt der Prozess entweder von Schritt 1226 oder 1228 vor zu Schritt 1230, wo der USB-Controller/Transceiver 202' die nach dem USB-Kommunikationsprotokoll umformatierten Datenrahmen zu einer USB-Kommunikationsschnittstelle des Fernsystems oder der Ferneinheit 225 übermittelt, das bzw. die über einen geeigneten der Kommunikationswege 2151–215M mit dem USB-Controller/Transceiver 202' gekoppelt ist. Im Anschluss an den Schritt 1230 endet der Prozess bei Schritt 1232 und kehrt zum „Start"-Schritt 1202 zurück.
  • Bezugnehmend nunmehr auf 18 ist ein Ablaufdiagramm gezeigt, das eine Ausführungsform eines Prozesses oder Algorithmus zur Informationsübertragung von dem Fernsystem oder der Ferneinheit 225, das bzw. die zur Kommunikation nach dem USB-Kommunikationsprotokoll ausgelegt ist, über das Kommunikationsbrückensystem 200' der 11- 14 zum J1708- oder J1939-Fahrzeugkommunikationsnetz darstellt. Der Prozess beginnt bei Schritt 1252, und bei Schritt 1254 werden serielle Informationen in Form von Datenrahmen, die vom Fernsystem oder der Ferneinheit 225 gesendet werden und nach dem USB-Kommunikationsprotokoll konfiguriert sind, seitens des USB-Controllers/Transceivers 202' empfangen, der über einen geeigneten der Kommunikationswege 2151–215M mit dem Fernsystem oder der Ferneinheit 225 gekoppelt ist. Anschließend fragt bei Schritten 1256–1258 der DSP 224 den USB-Controller/Transceiver 202' in einem kontinuierlichen Abfragezyklus nach neuen Daten ab. Während jedes Zyklus werden bei Schritt 1260 jegliche neuen Rohdaten gelesen und in einem Datenspeicher gespeichert, der dem DSP 224, der Hilfsspeichereinheit 244 oder einem anderen externen Speicher zugeordnet sein kann. Alternativ kann der DSP 224 warten und so, wie soeben beschrieben, bei Schritt 1260 auf eine Unterbrechung ansprechen, die von dem USB-Controller/Transceiver 202' erzeugt wird, wenn Daten seitens desselben empfangen werden. In jedem Fall sind sowohl Abfragesoftware als auch Unterbrechungsbehandlungsroutinen in der Fachwelt wohlbekannt, und ein Fachmann wird erkennen, dass beide Vorgehensweisen implementiert werden können, ohne vom Umfang der Erfindung abzuweichen.
  • Anschließend setzt der DSP 224 bei Schritt 1262 alle vom USB-Controller/Transceiver 202' erhaltenen Datenrahmen zu Nachrichten zusammen, wobei der DSP 224 bei Schritt 1264 ermittelt, ob irgendwelche der Nachrichten zur Übertragung entweder zum J1708-Fahrzeugkommunikationsnetz oder zum J1939-Fahrzeugkommunikationsnetz bestimmt sind. Nachrichten, die für kein Fahrzeugkommunikationsnetz bestimmt sind, werden bei Schritt 1266 verworfen. Anschließend an den Schritt 1264 ist der DSP 224 dazu ausgebildet, für jede Nachricht, die für das J1708- oder das J1939-Fahrzeugkommunikationsnetz bestimmt ist, diese Nachrichten bei Schritt 1268 in geeignete Datenpakete mit Adressen umzuformatieren. Nachrichten, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 nach dem SAE J1587-Kommunikationsprotokoll umformatiert, und solche Nachrichten, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 nach dem SAE J1939-Kommunikationsprotokoll umformatiert.
  • Nach dem Schritt 1268 geht der Prozess weiter zu Schritt 1270, wo der DSP 224 die umformatierten Datenpakete zu einem geeigneten Schnittstellenport sendet. Solche Pakete, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zu dessen J1587 SCI gesendet, und jene Pakete, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zu dessen CAN-Controller gesendet. Anschließend sendet der DSP 224 bei Schritt 1272 die umformatierten Datenpakete zu einem geeigneten Transceiver zur Übertragung zu einem entsprechenden der Fahrzeugkommunikationsnetze. Jene Pakete, die für das J1708-Fahrzeugkommunikationsnetz bestimmt sind, werden vom DSP 224 zum J1708/RS-485-Transceiver 216 gesendet, während diejenigen Pakete, die für das J1939-Fahrzeugkommunikationsnetz bestimmt sind, vom DSP 224 zum CAN-Transceiver 214 gesendet werden. Daraufhin sind die Transceiver 216 und/oder 214 bei Schritt 1274 dazu betreibbar, die zu ihnen vom DSP 224 gelieferten Daten zu einem oder mehreren der Steuercomputer zu liefern, die vom Fahrzeug 100 mitgeführt werden und mit einem oder beiden der Fahrzeugkommunikationsnetze gekoppelt sind. Beispielsweise ist der J1708/RS-485-Transceiver 216 über die Kommunikationsverbindung 1201 mit dem J1708-Fahrzeugkommunikationsnetz 1081 gekoppelt, wobei der J1708/RS-485-Transceiver 216 bei Schritt 1274 dazu betreibbar ist, die ihm vom DSP 224 zugeführten Daten, welche Daten zur Kommunikation nach dem SAE J1587-Kommunikatinsprotokoll konfiguriert sind, zu einem oder mehreren mit dem J1708-Fahrzeugkommunikationsnetz 1081 gekoppelten fahrzeuginternen Steuercomputern zu übermitteln. In ähnlicher Weise ist der CAN-Transceiver 214 über die Kommunikationsverbindung 120N mit dem J1939-Fahrzeugkommunikationsnetz 108N gekoppelt, wobei der CAN-Transceiver 214 dazu betreibbar ist, bei Schritt 1274 die ihm vom DSP 224 zugeführten Daten, welche Daten zur Kommunikation nach dem SAE J1939-Kommunikationsprotokoll konfiguriert sind, zu einem oder mehreren mit dem J1939-Fahrzeugkommunikationsnetz 108N gekoppelten fahrzeuginternen Steuercomputern zu übermitteln. Der Prozess geht vom Schritt 1274 oder vom Schritt 1266 weiter zu Schritt 1276, wo der Prozess endet und dann zum „Start"-Schritt zurückkehrt.
  • Die hier beschriebenen illustrativen Ausführungsformen sind beispielhaft und sollen die beanspruchte Erfindung in keiner Weise beschränken. Wenngleich bestimmte Anwendungen als besonders geeignet zur Verwendung mit der vorliegenden Erfindung beschrieben wurden, wird sie als nützlich auch bei anderen Anwendungen angesehen. Tatsächlich gibt es – wenn überhaupt – nur wenige Brennkraftmaschinenanwendungen, bei denen die vorliegende Erfindung nicht irgendeinen Vorteil bieten würde. Hersteller von Motoren und Motorcontrollern können die Wahl treffen, die vorliegende Erfindung in allen Motoren ungeachtet der Anwendung einzubauen.
  • Zusammenfassung
  • Eine Kommunikationsbrücke zwischen einem von einem Fahrzeug mitgeführten und zur Kommunikation nach einem ersten Protokoll ausgelegten Kommunikationsnetz und einem zur Kommunikation nach einem zweiten Protokoll ausgelegten Fernsystem umfasst eine zur Kopplung mit dem Kommunikationsnetz ausgelegte erste Schnittstelle, eine zur Kopplung mit dem Fernsystem ausgelegte zweite Schnittstelle sowie einen digitalen Signalprozessor (DSP), welcher zur Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist. Der DSP empfängt Informationen über die erste Schnittstelle von dem Kommunikationsnetz, wandelt diese Informationen auf das zweite Protokoll um und überträgt die auf das zweite Protokoll umgewandelten Informationen über die zweite Schnittstelle zu dem Fernsystem. Ferner empfängt der DSP Informationen über die zweite Schnittstelle von dem Fernsystem, wandelt diese Informationen auf das erste Protokoll um und überträgt die auf das erste Protokoll umgewandelten Informationen über die erste Schnittstelle zu dem Kommunikationsnetz.
    (11)

Claims (163)

  1. Adapter zum Ermöglichen einer Kommunikation zwischen einem mit einem Fahrzeugkommunikationsnetz gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem Fahrzeugkommunikationsnetz ausgelegt ist, und – eine zweite Schnittstelle, welche Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist, wobei der Fahrzeugsteuercomputer und der entfernte Computer über das Fahrzeugkommunikationsnetz und die erste und die zweite Schnittstelle kommunizieren.
  2. Adapter nach Anspruch 1, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem Controller für den universellen seriellen Bus gekoppelt ist.
  3. Adapter nach Anspruch 2, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  4. Adapter nach Anspruch 2, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  5. Adapter nach Anspruch 1, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  6. Adapter nach Anspruch 5, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  7. Adapter nach Anspruch 5, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  8. Adapter nach Anspruch 1, wobei der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt ist, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  9. Adapter nach Anspruch 8, wobei mindestens einer der Mehrzahl von entfernten Computern Fahrzeugdiagnose- oder Servicewerkzeugsoftware umfasst.
  10. Adapter nach Anspruch 1, wobei das Fahrzeugkommunikationsnetz ein J1939-Netzsegment umfasst und wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1939-Netzsegment gekoppelt ist.
  11. Adapter nach Anspruch 10, wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  12. Adapter nach Anspruch 11, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist und wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  13. Adapter nach Anspruch 11, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist und wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  14. Adapter nach Anspruch 1, wobei das Fahrzeugkommunikationsnetz ein J1587-Netzsegment umfasst und wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1587-Netzsegment gekoppelt ist.
  15. Adapter nach Anspruch 14, wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  16. Adapter nach Anspruch 15, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist und wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  17. Adapter nach Anspruch 15, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist und wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  18. Adapter nach Anspruch 1, wobei der Adapter ferner eine dritte Schnittstelle umfasst, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  19. Adapter nach Anspruch 18, wobei der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  20. Adapter nach Anspruch 19, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  21. Adapter nach Anspruch 19, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  22. Adapter nach Anspruch 18, wobei der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  23. Adapter nach Anspruch 22, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  24. Adapter nach Anspruch 22, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  25. Adapter nach Anspruch 1, wobei der Controller für den universellen seriellen Bus ferner einen USB-On-The-Go-Port umfasst.
  26. Adapter nach Anspruch 25, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  27. Adapter nach Anspruch 25, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  28. Adapter zum Ermöglichen einer Kommunikation zwischen einem mit einem J1939-Netz eines Fahrzeugs gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem J1939-Netz ausgelegt ist, und – eine zweite Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist, wobei der Fahrzeugsteuercomputer und der entfernte Computer über das J1939-Netz und die erste und die zweite Schnittstelle kommunizieren.
  29. Adapter nach Anspruch 28, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  30. Adapter nach Anspruch 28, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  31. Adapter nach Anspruch 28, wobei der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt ist, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  32. Adapter nach Anspruch 28, wobei der Adapter ferner eine dritte Schnittstelle umfasst, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  33. Adapter nach Anspruch 28, wobei der Controller für den universellen seriellen Bus fernen einen USB-On-The-Go-Port umfasst.
  34. Adapter nach Anspruch 33, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  35. Adapter nach Anspruch 33, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  36. Adapter zum Ermöglichen einer Kommunikation zwischen einem mit einem J1587-Netz eines Fahrzeugs gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem J1587-Netz ausgelegt ist, und – eine zweite Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Host ausgelegt ist, wobei der Fahrzeugsteuercomputer und der entfernte Computer über das J1587-Netz und die erste und die zweite Schnittstelle kommunizieren.
  37. Adapter nach Anspruch 36, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  38. Adapter nach Anspruch 36, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  39. Adapter nach Anspruch 36, wobei der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt ist, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  40. Adapter nach Anspruch 36, wobei der Adapter ferner eine dritte Schnittstelle umfasst, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  41. Adapter nach Anspruch 36, wobei der Controller für den universellen seriellen Bus ferner einen USB-On-The-Go-Port umfasst.
  42. Adapter nach Anspruch 41, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  43. Adapter nach Anspruch 41, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  44. Adapter zum Ermöglichen einer Kommunikation zwischen Steuercomputern eines Fahrzeugs und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1939-Netzsegment des Fahrzeugs ausgelegt ist, und – eine zweite Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1587-Netzsegement des Fahrzeugs ausgelegt ist, und – eine dritte Schnittstelle, welche einen Controller für einen universellen seriellen Bus (USB) mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die dritte Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist, wobei jeder Steuercomputer des Fahrzeugs und der entfernte Computer über das J1939-Netz und die erste sowie die dritte Schnittstelle oder über das J1587-Netz und die zweite sowie die dritte Schnittstelle kommunizieren.
  45. Adapter nach Anspruch 44, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-Hostport des Controllers für den universellen seriellen Bus gekoppelt ist.
  46. Adapter nach Anspruch 44, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-Geräteport des Controllers für den universellen seriellen Bus gekoppelt ist.
  47. Adapter nach Anspruch 44, wobei der USB-Hostport des Controllers für den universellen seriellen Bus zur Kopplung mit einer Mehrzahl von entfernten Computern ausgelegt ist, wobei jeder der Mehrzahl von entfernten Computern einen USB-Geräteport aufweist.
  48. Adapter nach Anspruch 44, wobei der Controller für den universellen seriellen Bus ferner einen USB-On-The-Go-Port umfasst.
  49. Adapter nach Anspruch 48, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  50. Adapter nach Anspruch 48, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Controllers für den universellen seriellen Bus gekoppelt ist.
  51. Verfahren zum Ermöglichen einer Kommunikation zwischen einem betriebsmäßig mit einem Kommunikationsnetz eines Fahrzeugs gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei das Verfahren umfasst: – Empfangen von Daten über eine erste Schnittstelle, wobei die erste Schnittstelle betriebsmäßig mit dem Kommunikationsnetz des Fahrzeugs gekoppelt ist, – Übertragen der Daten über eine zweite Schnittstelle, wobei die zweite Schnittstelle einen Controller für einen universellen seriellen Bus mit einem USB-Geräteport und einem USB-Hostport umfasst, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit einem Computer über den USB-Geräteport und den USB-Hostport ausgelegt ist, wobei die ersten Daten von dem Fahrzeugsteuercomputer übertragen werden und wobei die ersten Daten seitens des entfernten Computers empfangen werden.
  52. Verfahren nach Anspruch 51, wobei die Daten eine Netznachricht sind, wobei die Netznachricht eine Zieladresse umfasst.
  53. Verfahren nach Anspruch 52, wobei der Übertragungsschritt das Ermitteln umfasst, ob die Netznachricht für die zweite Schnittstelle bestimmt ist, sowie das Übertragen der Netznachricht über die zweite Schnittstelle nur dann, wenn die Netznachricht für die zweite Schnittstelle bestimmt ist.
  54. Verfahren nach Anspruch 53, wobei das Ermitteln, ob die Netznachricht für die zweite Schnittstelle bestimmt ist, das Lesen der Adresse sowie das Vergleichen derselben mit einer existierenden Adresse umfasst.
  55. Verfahren nach Anspruch 52, wobei der Übertragungsschritt das Übertragen der Netznachricht über die zweite Schnittstelle ungeachtet der Zieladresse der Netznachricht umfasst.
  56. Adapter zum Ermöglichen einer Kommunikation zwischen einem betriebsmäßig mit einem Fahrzeugkommunikationsnetz gekoppelten Fahrzeugsteuercomputer und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit dem Fahrzeugkommunikationsnetz ausgelegt ist, und – eine zweite Schnittstelle mit einem USB-On-The-Go-Port, wobei die zweite Schnittstelle zur betriebsmäßigen Kopplung mit dem entfernten Computer über den USB-On-The-Go-Port ausgelegt ist, wobei der Fahrzeugsteuercomputer und der entfernte Computer über das Fahrzeugkommunikationsnetz und die erste und die zweite Schnittstelle kommunizieren.
  57. Adapter nach Anspruch 56, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  58. Adapter nach Anspruch 57, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  59. Adapter nach Anspruch 57, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  60. Adapter nach Anspruch 56, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  61. Adapter nach Anspruch 60, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  62. Adapter nach Anspruch 60, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  63. Adapter nach Anspruch 56, wobei das Fahrzeugkommunikationsnetz ein J1939-Netzsegment umfasst und wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1939-Netzsegment gekoppelt ist.
  64. Adapter nach Anspruch 63, wobei über das J1939-Netzsegment kommunizierte Nachrichten über die zweite Schnittstelle verfügbar gemacht werden.
  65. Adapter nach Anspruch 64, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist und wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  66. Adapter nach Anspruch 64, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist und wobei Nachrichten, die über das J1939-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  67. Adapter nach Anspruch 56, wobei das Fahrzeugkommunikationsnetz ein J1587-Netzsegment umfasst und wobei die erste Schnittstelle des Adapters betriebsmäßig mit dem J1587-Netzsegment gekoppelt ist.
  68. Adapter nach Anspruch 67, wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, über die zweite Schnittstelle verfügbar gemacht werden.
  69. Adapter nach Anspruch 68, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist, wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist und wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem persönlichen digitalen Assistenten übermittelt werden.
  70. Adapter nach Anspruch 68, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist, wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist und wobei Nachrichten, die über das J1587-Netzsegment kommuniziert werden, ferner zu dem Personalcomputer übermittelt werden.
  71. Adapter nach Anspruch 56, wobei der Adapter ferner eine dritte Schnittstelle umfasst, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die dritte Schnittstelle einen seriellen RS-232-Port umfasst.
  72. Adapter nach Anspruch 71, wobei der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  73. Adapter nach Anspruch 72, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  74. Adapter nach Anspruch 72, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  75. Adapter nach Anspruch 71, wobei der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  76. Adapter nach Anspruch 75, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  77. Adapter nach Anspruch 75, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  78. Adapter zum Ermöglichen einer Kommunikation zwischen Steuercomputern eines Fahrzeugs und einem entfernten Computer, wobei der Adapter umfasst: – eine erste Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1939-Netzsegment des Fahrzeugs ausgelegt ist, – eine zweite Schnittstelle, welche zur betriebsmäßigen Kopplung mit einem J1587-Netzsegment des Fahrzeugs ausgelegt ist, und – eine dritte Schnittstelle mit einem USB-On-The-Go-Port, wobei die dritte Schnittstelle zur betriebsmäßigen Kopplung mit dem Computer über den USB-On-The-Go-Port ausgelegt ist, wobei jeder Steuercomputer des Fahrzeugs und der entfernte Computer über das J1939-Netz und die erste sowie die dritte Schnittstelle oder über das J1587-Netz und die zweite sowie die dritte Schnittstelle kommunizieren.
  79. Adapter nach Anspruch 78, wobei der entfernte Computer ein persönlicher digitaler Assistent oder ein Personalcomputer mit einem USB-On-The-Go-Port ist und wobei der USB-On-The-Go-Port des entfernten Computers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  80. Adapter nach Anspruch 79, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  81. Adapter nach Anspruch 79, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  82. Adapter nach Anspruch 78, wobei der entfernte Computer ein persönlicher digitaler Assistent mit einem USB-Geräteport ist und wobei der USB-Geräteport des persönlichen digitalen Assistenten betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  83. Adapter nach Anspruch 82, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  84. Adapter nach Anspruch 82, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  85. Adapter nach Anspruch 78, wobei der entfernte Computer ein Personalcomputer mit einem USB-Hostport ist und wobei der USB-Hostport des Personalcomputers betriebsmäßig mit dem USB-On-The-Go-Port des Adapters gekoppelt ist.
  86. Adapter nach Anspruch 85, wobei der entfernte Computer Servicewerkzeugsoftware umfasst.
  87. Adapter nach Anspruch 85, wobei der entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  88. Adapter nach Anspruch 78, wobei der Adapter ferner eine vierte Schnittstelle umfasst, welche zur betriebsmäßigen Kopplung mit einem zweiten entfernten Computer ausgelegt ist, wobei die vierte Schnittstelle einen seriellen RS-232-Port umfasst.
  89. Adapter nach Anspruch 88, wobei der zweite entfernte Computer ein persönlicher digitaler Assistent mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des persönlichen digitalen Assistenten betriebsmäßig mit dem seriellen RS-232-Port des Adapters gekoppelt ist.
  90. Adapter nach Anspruch 89, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  91. Adapter nach Anspruch 89, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  92. Adapter nach Anspruch 88, wobei der zweite entfernte Computer ein Personalcomputer mit einem seriellen RS-232-Port ist und wobei der serielle RS-232-Port des Personalcomputers betriebsmäßig mit dem seriellen RS-232-Port des. Adapters gekoppelt ist.
  93. Adapter nach Anspruch 92, wobei der zweite entfernte Computer Servicewerkzeugsoftware umfasst.
  94. Adapter nach Anspruch 92, wobei der zweite entfernte Computer Fahrzeugdiagnosesoftware umfasst.
  95. Adapter nach Anspruch 88, wobei der entfernte Computer der zweite entfernte Computer ist.
  96. Kommunikationsbrücke zwischen einem von einem Kraftfahrzeug mitgeführten und zur Kommunikation nach einem ersten Protokoll ausgelegten Kommunikationsnetz und einem zur Kommunikation nach einem zweiten Protokoll ausgelegten Fernsystem, wobei die Kommunikationsbrücke umfasst: – eine erste Schnittstelle, welche zur Kopplung mit dem Kommunikationsnetz ausgelegt ist, – eine zweite Schnittstelle, welcher zur Kopplung mit dem Fernsystem ausgelegt ist, und – einen digitalen Signalprozessor (DSP), welcher zur Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist, wobei der DSP von dem Kommunikationsnetz über die erste Schnittstelle nach dem ersten Protokoll konfigurierte Informationen erhält, die von dem Kommunikationsnetz erhaltenen und nach dem ersten Protokoll konfigurierten Informationen auf das zweite Protokoll umwandelt und die auf das zweite Protokoll umgewandelten Informationen über die zweite Schnittstelle zu dem Fernsystem überträgt, wobei der DSP von dem Fernsystem über die zweite Schnittstelle nach dem zweiten Protokoll konfigurierte Informationen erhält, die von dem Fernsystem erhaltenen und nach dem zweiten Protokoll konfigurierten Informationen auf das erste Protokoll umwandelt und die auf das erste Protokoll umgewandelten Informationen über die erste Schnitttstelle zu dem Kommunikationsnetz überträgt.
  97. Kommunikationsbrücke nach Anspruch 96, ferner umfassend einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem Kommunikationsnetz stehenden Steuercomputer, wobei der Steuercomputer die nach dem ersten Protokoll konfigurierten Informationen zu dem Kommunikationsnetz liefert.
  98. Kommunikationsbrücke nach Anspruch 96, wobei das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) ist und wobei das erste Protokoll ein SAE J1587-Kommunikationsprotokoll ist, das für die Kommunikation über das SAE J1708-Hardwarenetz ausgelegt ist.
  99. Kommunikationsbrücke nach Anspruch 98, wobei die erste Schnittstelle ein erster Transceiver ist, der zur Kopplung mit dem SAE J1708-Hardwarennetz ausgelegt ist, wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1587-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE-J1708-Hardwarenetz zu übertragen und von diesem zu empfangen.
  100. Kommunikationsbrücke nach Anspruch 99, ferner umfassend einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem SAE J1708-Hardwarenetz stehenden Steuercomputer, wobei der Steuercomputer die nach dem SAE J1587-Protokoll konfigurierten Informationen zu dem SAE J1708-Hardwarenetz liefert.
  101. Kommunikationsbrücke nach Anspruch 100, wobei das zweite Protokoll ein RS-232-Kommunikationsprotokoll ist.
  102. Kommunikationsbrücke nach Anspruch 101, wobei die zweite Schnittstelle ein zweiter Transceiver ist, der zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist, wobei der zweite Transceiver dazu betreibbar ist, die nach dem RS-232-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  103. Kommunikationsbrücke nach Anspruch 102, wobei das Fernsystem ein Personalcomputer ist.
  104. Kommunikationsbrücke nach Anspruch 102, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  105. Kommunikationsbrücke nach Anspruch 100, wobei das zweite Protokoll ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) ist.
  106. Kommunikationsbrücke nach Anspruch 105, wobei die zweite Schnittstelle ein USB-Controller mit einem ersten USB-Schnittstellenport ist, welcher zur Kopplung mit einem zweiten USB-Schnittstellenport des Fernsystems ausgelegt ist, wobei der USB- Controller dazu betreibbar ist, die nach dem USB-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  107. Kommunikationsbrücke nach Anspruch 106, wobei das Fernsystem ein Personalcomputer ist.
  108. Kommunikationsbrücke nach Anspruch 106, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  109. Kommunikationsbrücke nach Anspruch 106, wobei das Fernsystem als USB-Gerät konfiguriert ist und wobei der erste USB-Schnittstellenport als USB-Hostport konfiguriert ist.
  110. Kommunikationsbrücke nach Anspruch 106, wobei der erste USB-Schnittstellenport als On-The-Go-USB-Port konfiguriert ist, der als Host-USB-Port betreibbar ist.
  111. Kommunikationsbrücke nach Anspruch 106, wobei das Fernsystem als USB-Host konfiguriert ist und wobei der erste USB-Schnittstellenport als USB-Geräteport konfiguriert ist.
  112. Kommunikationsbrücke nach Anspruch 106, wobei der erste USB-Schnittstellenport als On-The-Go-USB-Port konfiguriert ist, welcher als Geräte-USB-Port betreibbar ist.
  113. Kommunikationsbrücke nach Anspruch 96, wobei das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz ein J1939-Hardwarenetz der Society of Automotive Engineers (SAE) ist und wobei das erste Protokoll ein SAE J1939-Kommunikationsprotokoll ist, das für die Kommunikation über das SAE J1939-Hardwarenetz ausgelegt ist.
  114. Kommunikationsbrücke nach Anspruch 113, wobei die erste Schnittstelle ein erster Transceiver ist, welcher zur Kopplung mit dem SAE-J1939-Hardwarenetz ausgelegt ist, wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1939-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1939-Hardwarenetz zu übertragen und von diesem zu empfangen.
  115. Kommunikationsbrücke nach Anspruch 114, ferner umfassend einen von dem Kraftfahrzeug mitgeführten und in Kommunikation mit dem SAE J1939-Hardwarnetz stehenden Steuercomputer, wobei der Steuercomputer die nach dem SAE-J1939-Protokoll konfigurierten Informationen zu dem SAE-J1939-Hardwarenetz liefert.
  116. Kommunikationsbrücke nach Anspruch 115, wobei das zweite Protokoll ein RS-232-Kommunikationsprotokoll ist.
  117. Kommunikationsbrücke nach Anspruch 116, wobei die zweite Schnittstelle ein zweiter Transceiver ist, der zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist, wobei der zweite Transceiver dazu betreibbar ist, die nach dem RS-232-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  118. Kommunikationsbrücke nach Anspruch 117, wobei das Fernsystem ein Personalcomputer ist.
  119. Kommunikationsbrücke nach Anspruch 117, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  120. Kommunikationsbrücke nach Anspruch 115, wobei das zweite Protokoll ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) ist.
  121. Kommunikationsbrücke nach Anspruch 120, wobei die zweite Schnittstelle ein USB-Controller mit einem ersten USB-Schnittstellenport ist, welcher zur Kopplung mit einem zweiten USB-Schnittstellenport des Fernsystems ausgelegt ist, wobei der USB-Controller dazu betreibbar ist, die nach dem USB- Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  122. Kommunikationsbrücke nach Anspruch 121, wobei das Fernsystem ein Personalcomputer ist.
  123. Kommunikationsbrücke nach Anspruch 121, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  124. Kommunikationsbrücke nach Anspruch 121, wobei das Fernsystem als USB-Gerät konfiguriert ist und wobei der erste USB-Schnittstellenport als USB-Hostport konfiguriert ist.
  125. Kommunikationsbrücke nach Anspruch 121, wobei der erste USB-Schnittstellenport als On-The-Go-USB-Port konfiguriert ist, welcher als Host-USB-Port betreibbar ist.
  126. Kommunikationsbrücke nach Anspruch 121, wobei das Fernsystem als USB-Host konfiguriert ist und wobei der erste USB-Schnittstellenport als USB-Geräteport konfiguriert ist.
  127. Kommunikationsbrücke nach Anspruch 121, wobei der erste USB-Schnittstellenport als On-The-Go-USB-Port konfiguriert ist, welcher als Geräte-USB-Port betreibbar ist.
  128. Kommunikationsbrücke zwischen einem von einem Kraftfahrzeug mitgeführten und zur Kommunikation nach einem ersten Protokoll ausgelegten Kommunikationsnetz und einem zur Kommunikation nach einem zweiten Protokoll ausgelegten Fernsystem, wobei die Kommunikationsbrücke umfasst: – einen ersten Transceiver, welcher zur Kopplung mit dem Kommunikationsnetz ausgelegt ist, – einen zweiten Transceiver, welcher zur Kopplung mit dem Fernsystem ausgelegt ist, und – einen digitalen Signalprozessor (DSP), welcher zur Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist, wobei der DSP einen mit dem ersten Transceiver verbundenen ersten Kommunikationsport und einen mit dem zweiten Transceiver verbundenen zweiten Kommunikationsport umfasst, wobei der DSP dazu ausgelegt ist, nach dem ersten Protokoll konfigurierte Informationen über den ersten Kommunikationsport zu dem ersten Transceiver zu übertragen und von diesem zu empfangen und nach dem zweiten Protokoll konfigurierte Informationen über den zweiten Kommunikationsport zu dem zweiten Transceiver zu übertragen und von diesem zu empfangen, wobei der DSP die Kommunikation zwischen dem Kommunikationsnetz und dem Fernsystem durch Umwandeln der Informationen zwischen dem ersten und dem zweiten Protokoll besorgt.
  129. Kommunikationsbrücke nach Anspruch 128, ferner umfassend eine Energieversorgung, welche dazu ausgelegt ist, eine erste Versorgungsspannung an den ersten Transceiver zu liefern.
  130. Kommunikationsbrücke nach Anspruch 129, ferner umfassend eine Energiequellenwählschaltung, welche eine oder mehrere Quellenspannungen erhält und der Energieversorgung selektiv eine der einen oder mehreren Quellenspannungen als Eingangsspannung zuführt, wobei die Energieversorgung die erste Versorgungsspannung als Funktion der Eingangsspannung erzeugt.
  131. Kommunikationsbrücke nach Anspruch 130, wobei die Energieversorgung ferner dazu ausgelegt ist, eine zweite Versorgungsspannung als Funktion der Eingangsspannung an den DSP und den zweiten Transceiver zu liefern, wobei die zweite Versorgungsspannung kleiner als die erste Versorgungsspannung ist.
  132. Kommunikationsbrücke nach Anspruch 130, wobei der DSP einen programmierbaren Flash-Speicher umfasst und wobei die Energieversorgung ferner dazu ausgelegt ist, eine Flash-Speicher-Programmierspannung als Funktion der Eingangsspannung an den DSP zu liefern.
  133. Kommunikationsbrücke nach Anspruch 130, wobei die eine oder mehreren Quellenspannungen eine der Kommunikationsbrücke mittels einer externen Spannungsquelle zugeführte Gleichspannung umfassen.
  134. Kommunikationsbrücke nach Anspruch 130, ferner umfassend mindestens eine Batterie, welche eine Batteriespannung liefert, wobei die eine oder mehreren Quellenspannungen die von der Batterie gelieferte Batteriespannung umfassen.
  135. Kommunikationsbrücke nach Anspruch 130, wobei der zweite Transceiver eine Controller- und Transceiverschaltung für einen universellen seriellen Bus (USB) ist, welche einen ersten USB-Port aufweist, der zur Kopplung mit einem zweiten USB-Port des Fernsystems ausgelegt ist, wobei der erste USB-Port einen Spannungsbus(VBUS) Eingang umfasst, welcher zum Empfang einer Gleichspannung ausgelegt ist, die von dem Fernsystem an einem entsprechenden VBUS-Ausgang des zweiten USB-Ports geliefert wird, und wobei die eine oder mehreren Quellenspannungen, die an den VBUS-Eingang des ersten USB-Ports empfangene Gleichspannung umfassen.
  136. Kommunikationsbrücke nach Anspruch 129, wobei der DSP einen Spannungsmesseingang umfasst, welcher die an dem VBUS-Eingang des ersten USB-Ports empfangene Gleichspannung überwacht, wobei der DSP die an dem VBUS-Eingang des ersten USB-Ports empfangene Gleichspannung misst und einen resultierenden Messspannungswert mittels einer Diagnosenachricht, die von der USB-Controller- und Transceiverschaltung übermittelt wird, an das Fernsystem liefert.
  137. Kommunikationsbrücke nach Anspruch 129, ferner umfassend eine Ladeschaltung zum Laden externer Batterien, wobei die Ladeschaltung eine von der Energieversorgung erzeugte Ladespannung erhält und die Ladespannung nach außerhalb der Kommunikationsbrücke liefert.
  138. Kommunikationsbrücke nach Anspruch 137, wobei das Fernsystem ein persönliches digitales Assistenz- (PDA) Gerät ist und wobei die von der Ladeschaltung zum Laden externer Batterien erzeugte Ladespannung an den PDA geliefert wird, um eine oder mehrere von diesem mitgeführte Batterien zu laden.
  139. Kommunikationsbrücke nach Anspruch 138, wobei der DSP einen Spannungsmesseingang umfasst, welcher die von der Energieversorgung erzeugte Ladespannung überwacht, wobei der DSP die Ladespannung misst und einen resultierenden Messspannungswert mittels einer Diagnosenachricht, die von dem zweiten Transceiver übermittelt wird, an den PDA liefert.
  140. Kommunikationsbrücke nach Anspruch 133, wobei der DSP einen Spannungsmesseingang umfasst, welcher die von der externen Spannungsquelle gelieferte Gleichspannung überwacht.
  141. Kommunikationsbrücke nach Anspruch 140, ferner umfassend einen Energieversorgungsstatusanzeiger sowie eine Treiberschaltung, welche einen mit einem Steuerausgang des DSP verbundenen Steuereingang und einen mit dem Energieversorgungsstatusanzeiger verbundenen Treiberausgang aufweiset, wobei der DSP dazu betreibbar ist, den Energieversorgungsstatusanzeiger über die Treiberschaltung zu steuern, um eine Sichtanzeige des gemessenen Werts der Gleichspannung zu liefern.
  142. Kommunikationsbrücke nach Anspruch 141, wobei der Energieversorgungsstatusanzeiger eine lichtemittierende Energieversorgungsstatusdiode (LED) ist, wobei der DSP die Energieversorgungsstatus-LED über die Treiberschaltung derart steuert, dass die Energieversorgungsstatus-LED leuchtet, wenn der gemessene Wert der Gleichspannung innerhalb eines vorbestimmten Spannungsbereichs liegt, und in einen ausgeschalteten Zustand eingestellt ist, wenn der gemessene Wert der Gleichspannung unter einem Schwellenspannungswert liegt, der kleiner als der vorbestimmte Spannungsbereich ist.
  143. Kommunikationsbrücke nach Anspruch 142, wobei der DSP ferner dazu betreibbar ist, die Energieversorgungsstatus-LED über die Treiberschaltung derart zu steuern, dass die Energieversorgungs-LED mit einer vorbestimmten Wechselrate ein- und ausgeschaltet wird, wenn der gemessene Wert der Gleichspannung außerhalb des vorbestimmten Spannungsbereichs liegt.
  144. Kommunikationsbrücke nach Anspruch 128, ferner umfassend einen Statusanzeiger sowie eine Treiberschaltung, welche einen mit einem Steuerausgang des DSP verbundenen Steuereingang und einen mit dem Statusanzeiger verbundenen Treiberausgang aufweist, wobei der DSP dazu betreibbar ist, den Statusanzeiger über die Treiberschaltung zu steuern, um eine Sichtanzeige des Status des Informationstransfers zwischen dem Kommunikationsnetz und dem Fernsystem zu liefern.
  145. Kommunikationsbrücke nach Anspruch 144, wobei das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) ist und das erste Protokoll ein für die Kommunikation über das SAE J1708-Hardwarenetz ausgelegtes SAE J1587-Kommunikationsprotokoll ist und wobei der erste Transceiver dazu betreibbar ist, die nach dem SAE J1587-Kommunikatonsprotokoll konfigurierten Informationen zu dem SAE J1708-Hardwarenetz zu übertragen und von diesem zu empfangen.
  146. Kommunikationsbrücke nach Anspruch 145, wobei der Statusanzeiger eine lichtemittierende J1587/J1708-Kommunikationsstatusdiode (LED) ist, wobei der DSP die J1587/J1708-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn das J1708-Hardwarenetz nicht anspricht und der DSP Daten über den ersten Transceiver übermittelt, die J1587/J1708-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn das J1708-Hardwarenetz anspricht und der DSP über den ersten Transceiver Informationen zu dem J1708-Hardwarenetz überträgt und von diesem empfängt, und die J1587/J1708-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den ersten Transceiver zu dem J1708-Hardwarenetz überträgt noch Informationen von diesem empfängt.
  147. Kommunikationsbrücke nach Anspruch 144, wobei das von dem Kraftfahrzeug mitgeführte Kommunikationsnetz ein J1939-Hardwarenetz der Society of Automotive Engineers (SAE) ist und das erste Protokoll ein für die Kommunikation über das SAE J1939-Hardwarenetz ausgelegtes SAE J1939-Kommunikationsprotokoll ist und wobei der erste Transceiver ein Controller Area Network- (CAN) Transceiver ist, welcher dazu betreibbar ist, die nach dem SAE J1939-Kommunikationsprotokoll konfigurierten Informationen zu dem SAE J1939-Hardwarenetz zu übertragen und von diesem zu empfangen.
  148. Kommunikationsbrücke nach Anspruch 147, wobei der Statusanzeiger eine lichtemittierende J1939-Kommunikationsstatusdiode (LED) ist, wobei der DSP die J1939-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn das J1939-Hardwarenetz nicht anspricht und der DSP Daten über den ersten Transceiver überträgt, die J1939-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn das J1939-Hardwarenetz anspricht und der DSP Informationen über den CAN-Transceiver zu dem J1939-Hardwarenetz überträgt und von diesem empfängt, und die J1939-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den CAN-Transceiver zu dem J1939-Hardwarenetz überträgt noch Informationen von diesem erhält.
  149. Kommunikationsbrücke nach Anspruch 144, wobei das zweite Protokoll ein RS-232-Kommunikationsprotokoll ist und wobei der zweite Transceiver zur Kopplung mit einem RS-232-Kommunikationsport des Fernsystems ausgelegt ist, wobei der zweite Transceiver dazu betreibbar ist, nach dem RS-232-Kommunikationsprotokoll konfigurierte Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  150. Kommunikationsbrücke nach Anspruch 149, wobei der Statusanzeiger eine lichtemittierende RS-232-Kommunikationsstatusdiode (LED) ist, wobei der DSP die RS-232-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn der zweite RS-232-Kommunikationsport des Fernsystems nicht anspricht und der DSP Daten über den zweiten Transceiver überträgt, die RS-232-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, die schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn der zweite RS-232-Kommunikationsport anspricht und der DSP Informationen über den zweiten Transceiver zu dem Fernsystem überträgt und Informationen von diesem empfängt, und die RS-232-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über den zweiten Transceiver zu dem Fernsystem überträgt noch Informationen von diesem empfängt.
  151. Kommunikationsbrücke nach Anspruch 149, wobei das Fernsystem ein Personalcomputer ist.
  152. Kommunikationsbrücke nach Anspruch 149, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  153. Kommunikationsbrücke nach Anspruch 144, wobei das zweite Protokoll ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) ist, wobei der zweite Transceiver eine USB-Controller- und Transceiverschaltung ist, welche einen ersten USB-Port aufweist, der zur Kopplung mit einem zweiten USB-Port des Fernsystems ausgelegt ist, wobei die USB-Controller- und Transceiverschaltung dazu betreibbar ist, die nach dem USB-Kommunikationsprotokoll konfigurierten Informationen zu dem Fernsystem zu übertragen und von diesem zu empfangen.
  154. Kommunikationsbrücke nach Anspruch 153, wobei der Statusanzeiger eine lichtemittierende USB-Kommunikationsstatusdiode (LED) ist, wobei der DSP die USB-Kommunikationsstatus-LED mit einer ersten vorbestimmten Wechselrate ein- und ausschaltet, wenn der zweite USB-Port des Fernsystems nicht anspricht und der DSP Daten über die USB-Controller- und Transceiverschaltung überträgt, die USB-Kommunikationsstatus-LED mit einer zweiten vorbestimmten Wechselrate, welche schneller als die erste Wechselrate ist, ein- und ausschaltet, wenn der zweite USB-Port des Fernsystems anspricht und der DSP Informationen über die USB-Controller- und Transceiverschaltung zu dem Fernsystem überträgt und Informationen von diesem empfängt, und die USB-Kommunikationsstatus-LED in einem ausgeschalteten Zustand hält, wenn der DSP weder Informationen über die USB-Controller- und Transceiverschaltung zu dem Fernsystem überträgt noch Informationen von diesem empfängt.
  155. Kommunikationsbrücke nach Anspruch 153, wobei das Fernsystem ein Personalcomputer ist.
  156. Kommunikationsbrücke nach Anspruch 153, wobei das Fernsystem ein handtragbares persönliches digitales Assistenzgerät ist.
  157. Verfahren zum Übermitteln von Informationen zwischen mindestens einem von einem Kraftfahrzeug mitgeführten Kommunikationsnetz und einem Fernsystem, wobei das mindestens eine Kommunikationsnetz zur Kommunikation nach einem ersten Protokoll ausgelegt ist und das Fernsystem zur Kommunikation nach einem dritten Protokoll ausgelegt ist, wobei das Verfahren die Schritte umfasst: – Empfangen eines nach dem ersten Protokoll konfigurierten ersten Datensatzes von dem mindestens einen Kommunikationsnetz über eine mit dem mindestens einen Kommunikationsnetz gekoppelte erste Schnittstelle, – Liefern des über die erste Schnittstelle empfangenen ersten Datensatzes an einen digitalen Signalprozessor (DSP), welcher zu Abarbeitung mehrerer Operationen pro Befehlszyklus ausgelegt ist, – Umwandeln des ersten Datensatzes mit Hilfe des DSP von dem ersten Protokoll auf das zweite Protokoll, – Liefern des nach dem zweiten Protokoll konfigurierten ersten Datensatzes von dem DSP zu einer mit einem Fernsystem gekoppelten zweiten Schnittstelle und – Übertragen des nach dem zweiten Protokoll konfigurierten ersten Datensatzes über die zweite Schnittstelle zu dem Fernsystem.
  158. Verfahren nach Anspruch 157, ferner umfassend die Schritte: – Empfangen eines nach dem zweiten Protokoll konfigurierten zweiten Datensatzes von dem Fernsystem über die zweite Schnittstelle, – Liefern des über die zweite Schnittstelle empfangenen zweiten Datensatzes zu dem digitalen Signalprozessor (DSP), – Umwandeln des zweiten Datensatzes mit Hilfe des DSP von dem zweiten Protokoll auf das erste Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, – Liefern des nach dem ersten Protokoll konfigurierten zweiten Datensatzes von dem DSP zu der ersten Schnittstelle und – Übertragen des nach dem ersten Protokoll konfigurierten zweiten Datensatzes über die erste Schnittstelle zu dem mindestens einen Kommunikationsnetz.
  159. Verfahren nach Anspruch 158, wobei das das mindestens eine Kommunikationsnetz mitführende Fahrzeug ein weiteres Kommunikationsnetz umfasst, welches zur Kommunikation nach einem dritten Protokoll ausgelegt ist, wobei das Verfahren ferner die Schritte umfasst: – Empfangen eines nach dem dritten Protokoll konfigurierten dritten Datensatzes von dem weiteren Kommunikationsnetz über eine mit dem weiteren Kommunikationsnetz gekoppelte dritte Schnittstelle, – Liefern des über die dritte Schnittstelle empfangenen dritten Datensatzes zu dem digitalen Signalprozessor (DSP), – Umwandeln des dritten Datensatzes mit Hilfe des DSP von dem dritten Protokoll auf das zweite Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, – Liefern des nach dem zweiten Protokoll konfigurierten dritten Datensatzes von dem DSP zu der zweiten Schnittstelle und – Übertragen des nach dem zweiten Protokoll konfigurierten dritten Datensatzes über die zweite Schnittstelle zu dem Fernsystem.
  160. Verfahren nach Anspruch 159, ferner umfassend die Schritte: – Empfangen eines nach dem zweiten Protokoll konfigurierten vierten Datensatzes über die zweite Schnittstelle von dem Fernsystem, – Liefern des über die zweite Schnittstelle empfangenen vierten Datensatzes zu dem digitalen Signalprozessor (DSP), – Umwandeln des vierten Datensatzes mit Hilfe des DSP von dem zweiten Protokoll auf das dritte Protokoll gemäß einer Anzahl von Einzeltaktzyklus-DSP-Befehlen, – Liefern des nach dem dritten Protokoll konfigurierten Datensatzes von dem DSP zu der dritten Schnittstelle und – Übertragen des nach dem dritten Protokoll konfigurierten vierten Datensatzes über die dritte Schnittstelle zu dem weiteren Kommunikationsnetz.
  161. Verfahren nach Anspruch 160, wobei das mindestens eine Kommunikationsnetz ein J1708-Hardwarenetz der Society of Automotive Engineers (SAE) ist und das erste Protokoll ein für die Kommunikation über das J1708-Hardwarenetz ausgelegtes SAE J1587-Kommunikationsprotokoll ist und wobei das weitere Kommunikationsnetz ein SAE J1939-Hardwarenetz ist und das dritte Protokoll ein für die Kommunikation über das J1939-Hardwarenetz ausgelegtes SAE J1939-Kommunikationsprotokoll ist.
  162. Verfahren nach Anspruch 161, wobei das zweite Protokoll ein RS-232-Kommunikationsprotokoll ist.
  163. Verfahren nach Anspruch 161, wobei das zweite Protokoll ein Kommunikationsprotokoll für einen universellen seriellen Bus (USB) ist.
DE10392279.2T 2002-02-25 2003-02-10 Kommunikationsbrücke zwischen einem Fahrzeuginformationsnetz und einem Fernsystem Expired - Lifetime DE10392279B4 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US10/082,196 US7778750B2 (en) 2002-02-25 2002-02-25 Vehicle communications network adapter
US10/082,196 2002-02-25
US10/360,162 US20030167345A1 (en) 2002-02-25 2003-02-06 Communications bridge between a vehicle information network and a remote system
US10/360,162 2003-02-06
PCT/US2003/004002 WO2003073725A2 (en) 2002-02-25 2003-02-10 Communications bridge between a vehicle information network and a remote system

Publications (2)

Publication Number Publication Date
DE10392279T5 true DE10392279T5 (de) 2005-05-25
DE10392279B4 DE10392279B4 (de) 2020-08-06

Family

ID=27767332

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10392279.2T Expired - Lifetime DE10392279B4 (de) 2002-02-25 2003-02-10 Kommunikationsbrücke zwischen einem Fahrzeuginformationsnetz und einem Fernsystem

Country Status (5)

Country Link
US (1) US20030167345A1 (de)
JP (2) JP2006507703A (de)
DE (1) DE10392279B4 (de)
GB (1) GB2400777B (de)
WO (1) WO2003073725A2 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006013945A1 (de) * 2006-03-27 2007-10-04 Vector Informatik Gmbh Ankopplungsvorrichtung mit einem Prüfschnittstellen-Controller zur Ankopplung eines Diagnosegeräts sowie Verfahren und Diagnosemodul hierzu
DE102006059109A1 (de) * 2006-12-08 2008-06-12 Siemens Ag Anordnungen, Verfahren und Vorrichtungen zur Übertragung von Daten zwischen einer Steuer-Einrichtung und einem elektrischen Gerät
DE102018220038A1 (de) * 2018-11-22 2020-05-28 Continental Automotive Gmbh Reduktion eines Spannungsversatzes zwischen Masseanschlüssen in einem Fahrzeug
DE102021130368A1 (de) 2021-11-19 2023-05-25 Lenze Se Automatisierungstechnische Anordnung und Verfahren zur Inbetriebnahme, Prüfung, Überwachung und/oder Wartung eines Automatisierungsgeräts

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8090598B2 (en) 1996-01-29 2012-01-03 Progressive Casualty Insurance Company Monitoring system for determining and communicating a cost of insurance
US8140358B1 (en) 1996-01-29 2012-03-20 Progressive Casualty Insurance Company Vehicle monitoring system
US20040034460A1 (en) * 2002-08-13 2004-02-19 Folkerts Charles Henry Powertrain control system
US20040048583A1 (en) * 2002-08-21 2004-03-11 Everett Gregory J. Wireless control system for multiple networks
US7441108B2 (en) * 2002-11-19 2008-10-21 Ken Scott Fisher Portable memory drive with portable applications and cross-computer system management application
US20040142722A1 (en) * 2003-01-10 2004-07-22 Everett Gregory J. Databus communicator within a telemetry system
US7543080B2 (en) * 2003-03-28 2009-06-02 Peter Arthur Schade Dual port USB interface
US6927547B2 (en) * 2003-06-10 2005-08-09 Lutron Electronics Co., Inc. System bridge and timeclock for RF controlled lighting systems
US20050075768A1 (en) * 2003-10-02 2005-04-07 Snap-On Technologies, Inc. Autologic, L.L.C. Multipurpose multifunction interface device for automotive diagnostics
US7913242B2 (en) * 2003-11-04 2011-03-22 Gm Global Technology Operations, Inc. Low cost, open approach for vehicle software installation/updating and on-board diagnostics
US7656867B2 (en) * 2003-11-25 2010-02-02 Marcon International, Inc. Serial bus identification circuit for a computer chip enclosed in a stainless steel can
ITMI20032565A1 (it) * 2003-12-22 2005-06-23 Calzoni Srl Dispositivo ottico indicatore dell'angolo di planata per velivoli
US7584029B2 (en) * 2003-12-31 2009-09-01 Teradyne, Inc. Telematics-based vehicle data acquisition architecture
US20050151422A1 (en) * 2004-01-08 2005-07-14 Gilmour Daniel A. Universal serial bus connector in a vehicle
US7131595B2 (en) * 2004-01-20 2006-11-07 Standard Microsystems Corporation Automatic drive icon assignment by media type in single slot USB card readers
US7159766B2 (en) * 2004-01-20 2007-01-09 Standard Microsystems Corporation Peripheral device feature allowing processors to enter a low power state
US7086583B2 (en) * 2004-01-20 2006-08-08 Standard Microsystems Corporation Systems and methods for power reduction in systems having removable media devices
DE102004005680A1 (de) * 2004-02-05 2005-08-25 Bayerische Motoren Werke Ag Vorrichtung und Verfahren zur Ansteuerung von Steuergeräten in einem Bordnetz eines Kraftfahrzeuges
US7334041B2 (en) * 2004-02-26 2008-02-19 Teradyne, Inc. Vehicle communications interface
US7221255B2 (en) * 2004-03-02 2007-05-22 Honeywell International Inc. Embedded automotive latch communications protocol
JP2006020038A (ja) * 2004-07-01 2006-01-19 Denso Corp 物理量センサ装置およびその検査装置
GB0416586D0 (en) * 2004-07-24 2004-08-25 Powerdesk Internat Ltd A worktop and furniture incorporating a worktop
US20060271255A1 (en) * 2004-12-30 2006-11-30 Teradyne, Inc. System and method for vehicle diagnostics and prognostics
US8462858B2 (en) * 2005-02-18 2013-06-11 Texas Instruments Incorporated Wireless communications with transceiver-integrated frequency shift control and power control
US7740516B2 (en) * 2005-02-24 2010-06-22 Castle Creations, Inc Electronic speed control programming
US7623953B2 (en) * 2005-06-08 2009-11-24 Caterpillar Inc. Integrated regeneration and engine controls
DE102005042493A1 (de) 2005-09-07 2007-03-08 Robert Bosch Gmbh Steuergerät mit Rechengerät und Peripheriebaustein, die über einen seriellen Mehrdrahtbus miteinander in Verbindung stehen
US7346368B2 (en) * 2005-10-04 2008-03-18 Research In Motion Limited Method and mobile device for operating in different data transfer modes
US7719436B2 (en) * 2005-10-19 2010-05-18 Schweitzer Engineering Laboratories, Inc. System, a tool and a method for communicating with a faulted circuit indicator using a display
US7382272B2 (en) * 2005-10-19 2008-06-03 Schweitzer Engineering Laboratories, Inc. System, a tool and method for communicating with a faulted circuit indicator using a remote display
US8266348B2 (en) * 2005-11-08 2012-09-11 American Power Conversion Corporation System and method of communicating with portable devices
CN101213505B (zh) * 2005-12-09 2012-05-23 汤姆森特许公司 手持无线图形输入设备和无线遥控设备
US7433990B2 (en) 2006-01-24 2008-10-07 Standard Microsystems Corporation Transferring system information via universal serial bus (USB)
US8386116B2 (en) * 2006-10-26 2013-02-26 Service Solutions U.S., Llc Universal serial bus memory device for use in a vehicle diagnostic device
US7701080B2 (en) * 2007-02-13 2010-04-20 Ford Global Technologies, Llc USB for vehicle application
US9830637B2 (en) * 2007-02-23 2017-11-28 Epona Llc System and method for processing vehicle transactions
US20080203146A1 (en) * 2007-02-23 2008-08-28 Newfuel Acquisition Corp. System and Method for Controlling Service Systems
US9792632B2 (en) * 2007-02-23 2017-10-17 Epona Llc System and method for processing vehicle transactions
US9715683B2 (en) 2007-02-23 2017-07-25 Epona Llc System and method for controlling service systems
US20080265838A1 (en) * 2007-04-24 2008-10-30 Saurabh Garg Battery charging using a USB-ID pin of a USB interface
US8036613B2 (en) * 2007-05-07 2011-10-11 Infineon Technologies Ag Communication system and method for operating a communication system
US7725129B2 (en) * 2007-05-16 2010-05-25 Oliver David Grunhold Cell phone based vehicle control system
US7684904B2 (en) * 2007-06-27 2010-03-23 Arinc Incorporated Systems and methods for communication, navigation, surveillance and sensor system integration in a vehicle
FR2920373B1 (fr) * 2007-08-31 2009-10-30 Renault Sas Dispositif d'adaptation d'un systeme multimedia dans un vehicule
US8185759B1 (en) 2008-11-06 2012-05-22 Smsc Holdings S.A.R.L. Methods and systems for interfacing bus powered devices with host devices providing limited power levels
US7996577B2 (en) * 2008-11-12 2011-08-09 Cisco Technology, Inc. Automatically switching console connection
US7882297B2 (en) 2009-02-20 2011-02-01 Standard Microsystems Corporation Serial bus hub with low power devices
US8102867B2 (en) * 2009-05-07 2012-01-24 Ours Technology Inc. Bridges and computing devices with bridges
US20100299464A1 (en) * 2009-05-22 2010-11-25 Paccar Inc Vehicle having usb network
US9916625B2 (en) 2012-02-02 2018-03-13 Progressive Casualty Insurance Company Mobile insurance platform system
US20110055292A1 (en) * 2009-09-03 2011-03-03 Dinu Petre Madau System and method for standardizing vehicle network data across vehicle product lines
US8291266B2 (en) * 2009-09-15 2012-10-16 International Business Machines Corporation Server network diagnostic system
JP5451327B2 (ja) * 2009-11-16 2014-03-26 富士通コンポーネント株式会社 電源制御装置
US8874475B2 (en) * 2010-02-26 2014-10-28 Epona Llc Method and system for managing and monitoring fuel transactions
US20110279111A1 (en) * 2010-05-11 2011-11-17 Jacoby Jr James Leon Electronic probe housing and electronic governor for steam turbine
US9830571B2 (en) 2010-09-23 2017-11-28 Epona Llc System and method for coordinating transport of cargo
US8688313B2 (en) * 2010-12-23 2014-04-01 Aes Technologies, Llc. Remote vehicle programming system and method
US8676439B2 (en) * 2011-04-05 2014-03-18 Sung Jung Minute Industry Co., Ltd. Information processing adapter for on-board diagnostics
US8954920B2 (en) * 2011-04-21 2015-02-10 Haik Biglari Apparatus for developing embedded software and a process for making the same
EP2757742B1 (de) * 2011-09-12 2018-07-25 Toyota Jidosha Kabushiki Kaisha Gatewayvorrichtung in einem fahrzeug und kommunikationssystem für einen fahrzeug
EP4459928A2 (de) 2012-03-29 2024-11-06 Arilou Information Security Technologies Ltd. Schutz eines elektronischen fahrzeugsystems
US9231789B2 (en) 2012-05-04 2016-01-05 Infineon Technologies Ag Transmitter circuit and method for operating thereof
US10340864B2 (en) * 2012-05-04 2019-07-02 Infineon Technologies Ag Transmitter circuit and method for controlling operation thereof
US9116787B1 (en) * 2012-06-27 2015-08-25 Marden Industries, Inc. Electronic control system for mobile heavy equipment machinery
EP2713560B1 (de) * 2012-07-16 2015-03-04 ELMOS Semiconductor AG Verfahren zum Betreiben eines Transceivers eines an einen Datenbus angeschlossenen Bus-Teilnehmers
JP5165164B1 (ja) * 2012-08-10 2013-03-21 パナソニック株式会社 電動車両
EP2763032B1 (de) * 2013-01-31 2016-12-28 Sensirion AG Tragbare elektronische Vorrichtung mit integriertem chemischem Sensor und Verfahren zum Betrieb davon
EP3008402B1 (de) 2013-06-10 2018-08-01 Thermo King Corporation Einpunkt-kommunikationsschema für ein transportkühlsystem
US9645962B2 (en) 2013-09-26 2017-05-09 Delphi Technologies, Inc. Flexible mobile device connectivity to automotive systems with USB hubs
US9460037B2 (en) 2013-09-26 2016-10-04 Delphi Technologies, Inc. Flexible mobile device connectivity to automotive systems with USB hubs
US9563987B2 (en) 2013-09-30 2017-02-07 Bendix Commercial Vehicle Systems Llc Vehicle inspection verification and diagnostic unit
JP6358840B2 (ja) * 2014-04-24 2018-07-18 シャープ株式会社 電動粉挽き機
WO2017151314A1 (en) * 2016-03-03 2017-09-08 Molex, Llc System and method for power over ethernet control
US11221111B2 (en) 2016-02-15 2022-01-11 Molex, Llc Luminaire
TWI620068B (zh) * 2016-05-13 2018-04-01 景相科技股份有限公司 支援多主機的通用序列匯流排集線設備及使用其之車用主機
DE102016219347A1 (de) * 2016-10-06 2018-04-12 Robert Bosch Gmbh Steuergerät, insbesondere Steuergerät für ein Kraftfahrzeug
US11659067B2 (en) * 2017-06-29 2023-05-23 Aamp Of Florida, Inc. Wireless configuration and programming of automotive aftermarket peripheral interfacing modules
US10848600B2 (en) * 2017-06-29 2020-11-24 Aamp Of Florida, Inc. Wireless configuration and programming of automotive aftermarket peripheral interfacing modules
EP3750296A4 (de) * 2018-02-05 2021-09-15 Cisco Technology, Inc. Konfigurierbarer speicherserver mit mehreren sockets
IT201800003980A1 (it) 2018-03-26 2019-09-26 Stmicroelectronics Application Gmbh Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
US10983842B2 (en) 2019-07-08 2021-04-20 Microsoft Technology Licensing, Llc Digital signal processing plug-in implementation
US12122401B1 (en) 2020-10-01 2024-10-22 Howell Ventures Ltd. Self programmable microcontroller and method for a vehicle
IT202100005354A1 (it) 2021-03-08 2022-09-08 Stmicroelectronics Application Gmbh Circuito microcontrollore, dispositivo, sistema e procedimento di funzionamento corrispondenti
US11445148B1 (en) 2021-05-06 2022-09-13 Microsoft Technology Licensing, Llc Video teleconference curated user profile picture
US20220385747A1 (en) * 2021-06-01 2022-12-01 Repairify, Inc. Remote vehicle communications bitrate determination

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4602127A (en) * 1984-03-09 1986-07-22 Micro Processor Systems, Inc. Diagnostic data recorder
JPH0830672B2 (ja) * 1987-12-11 1996-03-27 富士重工業株式会社 車輌診断装置
JP2904296B2 (ja) * 1990-03-30 1999-06-14 マツダ株式会社 車両用多重伝送装置
US5191653A (en) * 1990-12-28 1993-03-02 Apple Computer, Inc. Io adapter for system and io buses having different protocols and speeds
US5475818A (en) * 1992-03-18 1995-12-12 Aeg Transportation Systems, Inc. Communications controller central processing unit board
US5541840A (en) * 1993-06-25 1996-07-30 Chrysler Corporation Hand held automotive diagnostic service tool
US5555498A (en) * 1994-03-18 1996-09-10 Chrysler Corporation Circuit and method for interfacing vehicle controller and diagnostic test instrument
US5737711A (en) * 1994-11-09 1998-04-07 Fuji Jukogyo Kabuishiki Kaisha Diagnosis system for motor vehicle
US5659304A (en) * 1995-03-01 1997-08-19 Eaton Corporation System and method for collision warning based on dynamic deceleration capability using predicted road load
US6064299A (en) * 1995-11-09 2000-05-16 Vehicle Enhancement Systems, Inc. Apparatus and method for data communication between heavy duty vehicle and remote data communication terminal
US5794164A (en) * 1995-11-29 1998-08-11 Microsoft Corporation Vehicle computer system
DE19625002B4 (de) * 1996-06-22 2005-03-10 Daimler Chrysler Ag Fahrzeugkommunikationssystem
DE19631050A1 (de) * 1996-08-01 1998-02-05 Frank Bergler Schnittstellenkonverter für USB
US5916287A (en) * 1996-09-30 1999-06-29 Hewlett-Packard Company Modular automotive diagnostic, test and information system
US5957985A (en) * 1996-12-16 1999-09-28 Microsoft Corporation Fault-resilient automobile control system
US6073063A (en) * 1997-02-06 2000-06-06 Ford Global Technologies, Inc. Automotive data recording device
GB2366496B (en) * 1997-02-28 2002-05-01 Fujitsu Ltd Error indicator of data modulator-demodulator
US5953511A (en) * 1997-04-08 1999-09-14 National Instruments Corporation PCI bus to IEEE 1394 bus translator
US6263268B1 (en) * 1997-08-26 2001-07-17 Transcontech Corporation System and method for providing mobile automotive telemetry
US6718239B2 (en) * 1998-02-09 2004-04-06 I-Witness, Inc. Vehicle event data recorder including validation of output
US6282469B1 (en) * 1998-07-22 2001-08-28 Snap-On Technologies, Inc. Computerized automotive service equipment using multipoint serial link data transmission protocols
US6141610A (en) * 1998-09-08 2000-10-31 Trimble Navigation Limited Automated vehicle monitoring system
US6141710A (en) * 1998-12-15 2000-10-31 Daimlerchrysler Corporation Interfacing vehicle data bus to intelligent transportation system (ITS) data bus via a gateway module
US6236909B1 (en) * 1998-12-28 2001-05-22 International Business Machines Corporation Method for representing automotive device functionality and software services to applications using JavaBeans
US6330499B1 (en) 1999-07-21 2001-12-11 International Business Machines Corporation System and method for vehicle diagnostics and health monitoring
US6253131B1 (en) * 1999-09-08 2001-06-26 Paccar Inc Steering wheel electronic interface
JP2001144828A (ja) * 1999-11-15 2001-05-25 Sharp Corp プロトコル変換装置
US6526340B1 (en) * 1999-12-21 2003-02-25 Spx Corporation Multi-vehicle communication interface
US6236917B1 (en) * 1999-12-21 2001-05-22 Spx Corporation Open architecture diagnostic tool
US6273034B1 (en) * 2000-05-17 2001-08-14 Detroit Diesel Corporation Closed loop fan control using fan motor pressure feedback
US6718425B1 (en) * 2000-05-31 2004-04-06 Cummins Engine Company, Inc. Handheld computer based system for collection, display and analysis of engine/vehicle data
AU2001274599B9 (en) * 2000-06-30 2006-10-05 Sumitomo Electric Industries, Ltd. On-vehicle gateway
JP2002016614A (ja) * 2000-06-30 2002-01-18 Sumitomo Electric Ind Ltd 車載ゲートウェイ
US6430485B1 (en) * 2000-07-06 2002-08-06 International Truck Intellectual Property Company, L.L.C. Wireless interface adaptor for remote diagnosis and programming of vehicle control systems
US6832281B2 (en) * 2000-07-06 2004-12-14 Onspec Electronic Inc. Flashtoaster for reading several types of flash memory cards with or without a PC
US6328000B1 (en) * 2000-07-07 2001-12-11 Detroit Diesel Corporation Closed loop fan control using fan speed feedback
FR2812437B1 (fr) * 2000-07-28 2004-02-06 Sagem Procede et dispositif de communication entre un equipement exterieur a un vehicule automobile et des calculateurs embarques
JP4246356B2 (ja) * 2000-08-08 2009-04-02 富士通株式会社 マルチメディア信号処理装置
US6671799B1 (en) * 2000-08-31 2003-12-30 Stmicroelectronics, Inc. System and method for dynamically sizing hardware loops and executing nested loops in a digital signal processor
US6603394B2 (en) * 2000-12-08 2003-08-05 Spx Corporation Multi-protocol wireless communication module
US6728603B2 (en) * 2001-02-08 2004-04-27 Electronic Data Systems Corporation System and method for managing wireless vehicular communications
US7149206B2 (en) * 2001-02-08 2006-12-12 Electronic Data Systems Corporation System and method for managing wireless vehicular communications
US6889057B2 (en) * 2001-04-20 2005-05-03 Sony Corporation PDA cradle for wireless IP communication
US6879894B1 (en) * 2001-04-30 2005-04-12 Reynolds & Reynolds Holdings, Inc. Internet-based emissions test for vehicles
DE10126880A1 (de) 2001-06-01 2002-12-12 Cartec Gmbh Diagnoseverfahren für Fahrzeuge, insbesondere Kraftfahrzeuge
AU2002347941A1 (en) * 2001-06-15 2003-01-02 Carcheckup, Llc Auto diagnosis method and device
US6459969B1 (en) * 2001-06-15 2002-10-01 International Business Machines Corporation Apparatus, program product and method of processing diagnostic data transferred from a host computer to a portable computer
US7155321B2 (en) * 2001-08-06 2006-12-26 Idsc Holdings Llc System, method and computer program product for remote vehicle diagnostics, monitoring, configuring and reprogramming
US6469621B1 (en) * 2001-08-16 2002-10-22 Johnson Controls Technology Company Tire monitor compatible with multiple data protocols
US6941203B2 (en) * 2001-09-21 2005-09-06 Innova Electronics Corporation Method and system for computer network implemented vehicle diagnostics
US6732218B2 (en) * 2002-07-26 2004-05-04 Motorola, Inc. Dual-role compatible USB hub device and method
US6920380B2 (en) * 2002-09-18 2005-07-19 Dearborn Group, Inc. Protocol selection matrix for in-vehicle networks
AU2003286856A1 (en) * 2002-11-07 2004-06-03 Snap-On Technologies, Inc. Vehicle data stream pause on data trigger value
FR3018771B1 (fr) 2014-03-20 2016-04-29 Airbus Helicopters Aeronef muni d'un systeme avionique

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006013945A1 (de) * 2006-03-27 2007-10-04 Vector Informatik Gmbh Ankopplungsvorrichtung mit einem Prüfschnittstellen-Controller zur Ankopplung eines Diagnosegeräts sowie Verfahren und Diagnosemodul hierzu
DE102006059109A1 (de) * 2006-12-08 2008-06-12 Siemens Ag Anordnungen, Verfahren und Vorrichtungen zur Übertragung von Daten zwischen einer Steuer-Einrichtung und einem elektrischen Gerät
DE102018220038A1 (de) * 2018-11-22 2020-05-28 Continental Automotive Gmbh Reduktion eines Spannungsversatzes zwischen Masseanschlüssen in einem Fahrzeug
DE102021130368A1 (de) 2021-11-19 2023-05-25 Lenze Se Automatisierungstechnische Anordnung und Verfahren zur Inbetriebnahme, Prüfung, Überwachung und/oder Wartung eines Automatisierungsgeräts

Also Published As

Publication number Publication date
GB0416125D0 (en) 2004-08-18
JP2009177804A (ja) 2009-08-06
DE10392279B4 (de) 2020-08-06
US20030167345A1 (en) 2003-09-04
GB2400777A (en) 2004-10-20
WO2003073725A3 (en) 2003-11-20
WO2003073725A2 (en) 2003-09-04
JP2006507703A (ja) 2006-03-02
GB2400777B (en) 2006-04-05

Similar Documents

Publication Publication Date Title
DE10392279B4 (de) Kommunikationsbrücke zwischen einem Fahrzeuginformationsnetz und einem Fernsystem
US8788139B2 (en) Multi-protocol vehicle diagnostic interface device and method
US7778750B2 (en) Vehicle communications network adapter
US7912601B2 (en) Simultaneous vehicle protocol communication apparatus and method
US20050251304A1 (en) Device and method for performing both local and remote vehicle diagnostics
DE102015214915B4 (de) Flexibles Scheduling-Verfahren und Scheduling-Vorrichtung bei einer LIN-Kommunikation
DE102017123252A1 (de) Softwareaktualisierungsverfahren und -vorrichtung für Fahrzeug
DE112011103225B4 (de) Schaltkreisvorrichtung, System und Verfahren mit Drosseln einer integrierten Verbindung
CN105513160B (zh) 基于obd‑ii的车载智能终端及车载信息公共服务系统
DE102021120927A1 (de) Echtzeitüberwachung und -steuerung von usb-typ-c/pd-ports ineinem kraftfahrzeug- oder industrieökosystem
DE112020002841T5 (de) Vorrichtung der physikalischen schicht mit ruhemodus und unterstützung eines teilweisen vernetzens und zugehörige systeme, verfahren und vorrichtungen
EP2044736A1 (de) Verfahren zum betreiben eines lin-busses
EP3174740B1 (de) Reifenüberwachungssystem und verfahren hierzu
DE102005030641A1 (de) Sensor für eine physikalische Grösse und Vorrichtung zum Prüfen des Sensors für eine physikalische Grösse
CN113341922B (zh) 基于lcm的域控制器故障诊断系统
CN104950881A (zh) 数据记录仪、基于该记录仪的远程刷写系统及其应用方法
DE602004008416T2 (de) Verbesserte Kommunikationsschnittstelle für Fahrzeuge
EP1590737B1 (de) Steuergerät für ein kraftfahrzeug und kommunikationsverfahren dafür
EP3598082A1 (de) Messgerät mit nahfeldinteraktionseinrichtung
CN205427973U (zh) 基于obd-ii的车载智能终端及车载信息公共服务系统
DE102021103064A1 (de) Kommunikationssystem
CN113347273A (zh) 一种车载以太网数据转换方法、装置、设备及介质
DE10224163B4 (de) Transaktionsdauermanagement in einem USB-Hostcontroller
DE102018217311B4 (de) Elektronische Steuereinheit
CN204856198U (zh) 数据记录仪、基于该记录仪的远程刷写系统

Legal Events

Date Code Title Description
8110 Request for examination paragraph 44
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029060000

Ipc: H04L0065000000

R071 Expiry of right