DE10026918B4 - Virtueller Netzwerkadapter - Google Patents

Virtueller Netzwerkadapter Download PDF

Info

Publication number
DE10026918B4
DE10026918B4 DE10026918A DE10026918A DE10026918B4 DE 10026918 B4 DE10026918 B4 DE 10026918B4 DE 10026918 A DE10026918 A DE 10026918A DE 10026918 A DE10026918 A DE 10026918A DE 10026918 B4 DE10026918 B4 DE 10026918B4
Authority
DE
Germany
Prior art keywords
network
control system
electronic control
vna
messages
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.)
Expired - Fee Related
Application number
DE10026918A
Other languages
English (en)
Other versions
DE10026918A1 (de
Inventor
Dieter Staiger
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.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE10026918A1 publication Critical patent/DE10026918A1/de
Application granted granted Critical
Publication of DE10026918B4 publication Critical patent/DE10026918B4/de
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/40006Architecture of a communication node
    • H04L12/40013Details regarding a bus controller
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L12/403Bus networks with centralised control, e.g. polling
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40Bus networks
    • H04L2012/40267Bus for use in transportation systems
    • H04L2012/40273Bus for use in transportation systems the transportation system being a vehicle
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/121Timestamp

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)

Abstract

Elektronisches Steuersystem zum Bereitstellen einer Zugriffsmöglichkeit auf ein geschütztes Netzwerk, insbesondere in einem Kraftfahrzeug, für eine Teilnehmereinheit in einem zweiten Netzwerk, so dass die Sicherheit im geschützten Netzwerk nicht beeinflusst werden kann;
dadurch gekennzeichnet, dass
das elektronische Steuersystem mit dem geschützten Netzwerk über einen Primärzugriffs-Port verbunden ist, so dass
keine signifikante elektrische und/oder physikalische Beeinflussung auf das geschützte Netzwerk ausgeübt wird; und
das elektronische Steuersystem das geschützte Netzwerk nur beobachten kann ohne es zu beeinflussen; und
Bereitstellung einer virtuellen Zugriffsmöglichkeit auf das geschützte Netzwerk, dadurch dass
das elektronische Steuersystem Nachrichten innerhalb des geschützten Netzwerks beobachtet, und
das elektronische Steuersystem eine Vielzahl beobachteter Nachrichten in einer Ablage speichert, und
das elektronische Steuersystem auf eine Anfrage der Teilnehmereinheit im zweiten Netzwerk hin diese Anfrage aus der in der Ablage gespeicherten Vielzahl bereits beobachteter Nachrichten erfüllt ohne die Anfrage in das geschützte Netzwerk zu senden...

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren und eine elektronische Schaltungsanordnung, die es ermöglicht, Bussysteme und Netzwerke zu beobachten. Insbesondere betrifft die Erfindung ein Verfahren und eine Schaltungsanordnung, die keine elektrischen oder physikalischen Zwangsbedingungen und Beeinflussung der Bussysteme und Netzwerke bewirken. In weiteren Einzelheiten sieht die Erfindung den Zugriff auf statische Bussysteme und Netzwerke vor, die insbesondere von durch Echtzeit erzwungenen Systemen und Applikationen benutzt werden.
  • Busse und Netzwerke, die zur Verschaltung von Echtzeit-Elektroniksystemen benutzt werden, werden in der Regel während Systemdefinition und -aufbau definiert. Die Anzahl der Bus-Anbaugeräte (Verbraucher) und, in Abhängigkeit von der Art des Netzwerks, auf das zugegriffen werden soll, die Meldungs-IDs werden bei der Systemdefinition vordefiniert und können während der Laufzeit des Systems nicht mehr geändert werden.
  • Typische Vertreter für Echtzeit-Busse sind z.B. Netzwerke, die in heutigen modernen Kraftfahrzeugen benutzt werden, wie z.B. CAN (Controller Area Network), VAN (Vehicles Area Network), J1939 (spezifiziert von der SAE, Society of Automotive Engineers) und weitere. Der Bustyp, die Topologie und die Busteilnehmer werden vom Kfz-Hersteller definiert. Aus mehreren Gründen ist es nicht möglich, zusätzliche Vorrichtungen oder Einheiten an diese Busse anzuschließen, sobald das Fahrzeug das Herstellerwerk verlassen hat:
    • a) Die wichtigste Tatsache ist durch Sicherheitsüberlegungen gegeben. In der Regel sind sicherheitsrelevante Vorrichtungen, wie Bremssteuerung, elektronische Motorsteuerung u.a., die Zugriff auf alle hauptsächlichen elektronischen Steuereinheiten (ECU – Electronic Control Units) im Fahrzeug haben, an die Echtzeit-Bussysteme angeschlossen.
    • b) Die Echtzeit-Bussysteme haben in der Regel nur eine begrenzte elektrische Ausgangsleistung und beschränken somit die Anzahl der Vorrichtungen, die in einem Netzwerk unterstützt werden können.
    • c) Die Anzahl der Busteilnehmer und damit Adressen/Meldungs-IDs wird auf ein Minimum beschränkt, um kosteneffektive Systeme herstellen zu können.
  • Als Konsequenz der oben erklärten Fakten sind die Busse nicht 'frei für die Allgemeinheit' und lassen es daher nicht zu, dass nachträglich neue Vorrichtungen angeschlossen werden. Nur bei Befolgen dieser Grundregel garantieren die ursprünglichen Hersteller den Fahrzeugbetrieb laut Spezifikationen und, was noch wichtiger ist, haften sie für alle sicherheitsrelevanten Funktionen.
  • Derzeit ist dieser Umstand eine strenge Zwangsbedingung für die weitere Entwicklung neuer, nachträglich einzubauender Vorrichtungen. Eingeschränkt durch den Status der Buszugriffsmöglichkeiten unterstützen diese nachträglich einzubauenden Vorrichtungen keine fortgeschrittenen Applikationen, die Zugriff auf die Echtzeit-Busse und Netzwerke des Fahrzeugs voraussetzen.
  • Beispielhafte typische Produkte sind die heutigen, nachträglich eingebauten Unterhaltungssysteme, Navigationssysteme und Telematiksysteme.
  • Trotzdem erfordern neu entwickelte Applikationen, wie online Dienste (Unterhaltung, Verkehrsinformationen usw.), Echtzeit-Ferndiagnosen, fortgeschrittene 'dynamische' Navigationssysteme und andere, Zugriff auf Daten, die von den verschiedenen Fahrzeug-Untersystemen (Radsensoren, Gyrometer, Drehzahlmesser, Steuerungseinschlagwinkel) geliefert werden.
  • Infolge der einschränkenden Fakten, wie erklärt, kann dieser neue Dienstleistungstyp nur vom ursprünglichen Hersteller als OEM (Original Equipment Manufacturer) Fremdaggregat angeboten werden, wenn es in Zusammenarbeit mit den Fahrzeugkonstrukteuren entwickelt wurde.
  • Falls vom Fahrzeughersteller keine Zusatzbusfähigkeit ausdrücklich vorgesehen und eingebaut wurde, werden nachträglich eingebaute Vorrichtungen nicht unterstützt und können nicht im 'Plug and Play'-Verfahren an die Fahrzeug-Domain-Netzwerke angehängt werden – eine sehr bedeutsame Sicherheitsmaßnahme mit möglichen rechtlichen Folgen, falls sie außer Acht gelassen wird.
  • Darüber hinaus offenbart die Offenlegungsschrift DE 198 15 150 A1 eine Anordnung von Sensoren zur Überwachung eines Arbeitsgerätes, welches in Abhängigkeit der Schaltzustände der Sensoren in Betrieb setzbar ist. Dabei wird die gesamte Datenübertragung zwischen dem Master und den Slaves von einer an das Bussystem angeschlossenen redundanten Auswerteeinheit abgehört und überprüft. Nur wenn die von sämtlichen Empfängern über das Bussystem übertragenen Kodierungen fehlerfrei identifiziert werden, wird über die Auswerteeinheit das Arbeitsgerät in Betrieb gesetzt. Werden die Kodierungen nicht fehlerfrei identifiziert, so ist entweder der Strahlengang einer Lichtschranke unterbrochen oder die Übertragung zwischen Master und Slaves fehlerhaft. In diesen Fällen wird das Arbeitsgerät außer Betrieb gesetzt.
  • Schließlich kann auf DE 196 25 002 A1 "Fahrzeugkommunikationssystem" als allgemeinen Hintergrund zu Fahrzeugkommunikationssystemen verwiesen werden. Diese Druckschrift offenbart beispielshaft ein Fahrzeugkommunikationssystem mit einem Zentralrechner zur Durchführung von Telematik-Applikationen, mit Geräteeinheiten zum Senden, Empfangen, Erfassen und/oder Verarbeiten von zu diesen Applikationen gehörigen Daten und mit einem oder mehreren Datenübertragungskanälen mit zugehörigen Schnittstellen, über welche die Geräteeinheiten mit dem Zentralrechner verbindbar sind.
  • Zusammenfassung der Erfindung
  • Es ist daher eine Aufgabe der Erfindung, ohne die obengenannten Nachteile Zugriff auf nicht-allgemeine, eingeschränkte Netzwerke vorzusehen, wie sie in der Regel in Kraftfahrzeugen benutzt werden.
  • Es ist eine weitere Aufgabe der vorliegenden Erfindung, ein Verfahren vorzusehen, das die wichtigsten Merkmale der typischen Buszugriffsmethoden vorsieht, wie sie in Standardnetzwerkadaptern bekannt sind.
  • Diese und noch weitere Aufgaben und Vorteile werden durch Vorsehen eines elektronischen Steuersystems laut Offenbarung in Anspruch 1, und durch ein Verfahren zum Zugreifen auf ein Netzwerk laut Offenbarung in Anspruch 11 gelöst.
  • Vorteilhafte Ausführungsformen der Erfindung sind in den abhängigen Ansprüchen enthalten.
  • Die vorliegende Erfindung beschreibt ein Prinzip für ein elektronisches Steuersystem, das eine Zugriffsmöglichkeit auf geschützte Netzwerke und Bussysteme für Applikationsprozessoreinheiten vorsieht, wie sie besonders in Kraftfahrzeugen benutzt werden. Das aktive Netzwerkzugriffswerkzeug, nachstehend Virtual Network Adapter (VNA – virtueller Netzwerkadapter) genannt, wird in einer einzigartigen virtuellen Art und Weise ausgeübt, in Wirklichkeit arbeitet der VNA Netzwerkzugriff absolut passiv, somit beeinflußt er das Netzwerk weder logisch noch physikalisch, insbesondere gibt es keine elektrische Beeinflussung.
  • Wie Standard-Busadapter/Controller hat der VNA zwei Zugriffsports, die an die externen elektronischen Systeme angeschlossen sind. Die Primärseite greift auf das im Zentrum stehende geschützte Echtzeitnetzwerk zu, während der sekundäre Zugriffsport des VNA über Schnittstelle mit dem Controllersystem oder ECU, die an das Netzwerk angeschlossen werden sollen, verbunden ist.
  • Wie aus dem Stand der Technik bekannt, schreiben über den Standardbuscontroller angehängte Vorrichtungen aktiv auf Fahrzeug-Echtzeitnetzwerke. Beispielsweise wird die Meldung 'Öltemperatur abrufen' einen Schreibbefehl aufrufen, der an das geschützte Netzwerk gegeben eine spezifische Information von einer spezifischen Fahrzeug-Domain-ECU anfordert. Unter der Annahme dieses typischen Verfahrens, das im Normalfall von Standard-Buscontrollern ausgeführt wird, kann daher die Hauptforderung, das Netzwerk nicht zu beeinflussen, nicht erfüllt werden.
  • Ein Vorteil der vorliegenden Erfindung ist, dass das VNA-System zwar in Wirklichkeit nicht auf das Echtzeit-Netzwerk einwirkt, jedoch die hauptsächlichen Buszugriffsfunktionen unterstützt, wie
    • – Daten/Meldung auf Anforderung – aufgerufen durch eine externe Abrufeinheit ('active bus access mode' – aktiver Buszugriffsmodus)
    • – Daten/Meldung auf Abruf – aufgerufen durch eine externe Abrufeinheit ('active bus access mode')
    • – Daten/Meldung-Senden – VNA-System initialisiert ('passive bus access mode' – passiver Buszugriffsmodus)
    • – Das vom VNA-Prinzip vorgeschlagene Verfahren soll einen Zugriff auf die Meldungen geben, die zu einem gegebenen Zeitpunkt auf den am meisten benutzten Echtzeit-Bussystemen liegen. Um das existierende (vordefinierte) Netzwerk aus keinem Grund, weder logisch noch physikalisch, beeinflussen können, können die Standard-Buscontroller, die die typischen Buszuteilungs- und Buszugriffsverfahren anwenden, nicht benutzt werden.
  • Als Folge, da man also nicht in der Lage ist, die Buszuteilung vorzunehmen und logisch in die entsprechenden Busteilnehmer einzugreifen, und somit keine Möglichkeit besteht, benötigte Daten auf Abruf 'anzufordern', ergibt sich 'als erster Gedanke' die Schlußfolgerung, den für die gedachte Applikation geeigneten Netzwerkzugriff nicht zu machen.
  • Die nachstehende bedeutsame Aussage liefert die elementaren Vorbedingungen für die Anwendbarkeit des VNA-Prinzips:
    Jede ECU, die an ein Echtzeit-Netzwerk angeschlossen ist, wird zu einem bestimmten Zeitpunkt daten- und einheitsrelevante Informationen an das Bussystem geben. Im Umkehrschluß: Wenn diese Tatsache nicht gegeben wäre, würde das Recht dieser Einheit, auf dem Bus zu existieren, überhaupt nicht gegeben sein. Mit anderen Worten, jede an das Netzwerk angeschlossene Einheit wird Daten auf das Netz legen, die auf Anforderung durch andere Einheiten abgerufen werden (ungeachtet Technik, Pooling oder ausgelöstes Ereignis), oder durch eigene Veranlassung, wie z.B. ausgelöst durch einen integrierten Sensor oder ein anderes internes logisches Ereignis.
  • In jedem Fall werden die datenliefernden Meldungen ausgegeben und für das Netzwerk freigegeben, ausgelöst durch sinnvolle Ereignisse und in angemessener Häufigkeit.
  • Genau diese Tatsache ist der Punkt, der die Zulässigkeit für die Anwendbarkeit des vorgeschlagenen VNA-Systems bestimmt – und im Unterschied zur Durchführbarkeit wird jedes Netzwerk, das dieses grundlegende Attribut und Verhalten nicht zeigt, von der VNA nicht, sinnvoll unterstützt.
  • Kurze Beschreibung der Zeichnungen
  • 1 zeigt eine Netzwerk/Client-Applikations-Bearbeitungseinheit, unterstützt vom erfindungsgemäßen VNA;
  • 2 zeigt ein Sekundärport-Netzwerk als VNA-Erweiterung gemäß vorliegender Erfindung;
  • 3 illustriert eine funktionelle VNA-Erweiterung gemäß vorliegender Erfindung;
  • 4 zeigt die erfindungsgemäßen VNA-Prozeßschritte;
  • 5 illustriert ein Beispiel für eine unidirektionale Hoch-Impedanz-Bitübertragungsschicht gemäß vorliegender Erfindung; und
  • 6 zeigt ein Beispiel für ein eNet/Client-Bearbeitungssystem gemäß vorliegender Erfindung.
  • Die Idee des VNA ist, auf die vorstehend erklärten Bedingungen und Konstellation Einfluß zu nehmen. Unter Anwendung eines Bus-Überwachungsverfahrens, das das Netzwerk nicht beeinflußt (unerheblicher Energiestoß), erfaßt der VNA alle im Netzwerk stehenden Meldungen. Die internen Prozesse sind so ausgelegt, dass sie die Meldungen identifizieren und programmierbare Filteralgorithmen einsetzen, um auf diese Weise die Datenmengen und Meldungen zu reduzieren, auf die die anfordernde Applikation abzielt. Als letztendliches Ergebnis kann der drastisch reduzierte Daten/Meldungsstrom entweder gesendet oder für die anfordernde Einheit bei Aufruf bereitgestellt werden.
  • Das in 1 gezeigte Beispiel illustriert ein einfaches Netzwerk/Client-Applikationssystem. Am primären Zugriffs-Port ist der VNA durch Zugriff auf ein Echtzeitbus-System an den geschützten Bereich der Fahrzeug-Domain angehängt. Im vorliegenden Beispiel unterstützt der VNA ein 'eNet/Client Processing System', das mit der sekundären VNA-Zugriffsseite zusammengeschaltet ist. Eine Radio-Sender/Empfänger-Vorrichtung (Radio-TC), die mit diesem Bearbeitungssystem zusammengeschaltet ist, liefert die externe Zugriffsmöglichkeit des Fahrzeugs über ein drahtloses Link, und ermöglicht so den weiten Bereich der e-Geschäfts-Applikationen, die über Netzwerk-Server und Provider aktiviert werden. Die Applikationen, die vom eNet/Client-Prozessor ausgeführt werden, nehmen Einfluß auf den VNA-Controller durch Gewinnen des Zugriffs auf die Fahrzeug-Domain-Daten, die vom internen Echtzeit-Bus des Fahrzeugs geliefert werden.
  • Der VNA-Controller erfaßt die Daten und Meldungen 'unsichtbar' für das Netzwerk und die Bus-Teilnehmer, und liefert ferner die 'vor-berechneten' Meldungen und Dateninformationen an die internen und externen Netzwerk/Client-Einheiten des Fahrzeugs.
  • Da die Netzwerk/Client-Einheiten aktiviert sind, um an die fahrzeugexternen Netzwerke (d.h. Internet) angeschlossen zu werden, arbeiten diese ECUs potentielle Ausführungsapplikationen in einem 'ungeschützten' Bereich ab. Wie oben bereits angedeutet, stellt diese Tatsache eine kritische Gefahr für die sicherheitsrelevanten Operationen dar, die von den am anderen Ende an die Fahrzeug-Echtzeitnetzwerke angeschlossenen Einheiten ausgeführt werden.
  • In strenger Beachtung der VNA-Forderung – das/die sicherheitsrelevanten Fahrzeug-Domain-Netzwerk(e) darf/dürfen auf keinen Fall beeinflußt werden – ist die spezifische Natur des VNA so ausgelegt, dass er unter allen Betriebsbedingungen einen absolut sicheren Betrieb gewährleistet.
  • Als Folgerung aus dieser strengen Grundregel wird der VNA nicht aktiviert, um aktiv auf das sicherheitskritische Fahrzeugnetzwerk zu schreiben oder es auf andere Weise zu stimulieren oder zu manipulieren. Jedoch, um die typischen Funktionen, die von den Standardbusadaptern vorgesehen sind, zu unterstützen, bietet der VNA eine einzigartige Lösung, um beide Forderungen – Unterstützen der Standardbusadapter-Modi und gleichzeitig Garantieren der Betriebssicherheit – unter einen Hut zu bringen.
  • Die Schlüsselidee für den VNA ist, die Funktionalität des aktiven Busadapters auf 'indirekte' Art und Weise vorzusehen – und damit die Fahrzeug-Domain-Buszugriffsbefehle 'virtuell' zu erfüllen.
  • Der VNA-Prozessor überwacht und erfaßt kontinuierlich alle Meldungen, die an das Fahrzeugdomain-Netzwerk gerichtet werden. Diese 'Hintergrundoperation' wird vom VNA laufend ausgeführt, unabhängig von den steuernden ECU-Einheiten, die an den sekundären VNA-Port angeschlossen sind, und ohne Beachtung von Befehlen und Anforderungen, die von diesen ECUs ausgegeben werden. Gesteuert vom spezifischen internen VNA-Programm (VNA Mikrocode / Firmware) werden die Meldungen gefiltert, analysiert und kategorisiert. Das dieser Operation zugrundeliegende Motiv ist, diese Meldungen und Dateninformationen genau zu identifizieren, die potentiell (zu einem bestimmten Zeitpunkt) durch Applikationen angefordert werden, die von den steuernden ECU-Einheiten ausgeführt werden. Wenn eine 'Meldung vom Anforderungstyp' in Betracht gezogen wird, werden die entsprechenden erfaßten Daten in der VNA-internen Daten/Meldungs-Ablage gespeichert. Die Meldungen vom 'Anforderungstyp' werden während der Spezifikation und Konstruktion des entsprechenden spezifischen VNA/ECU-Applikationssystems identifiziert und vordefiniert und werden permanent im VNA-internen Programmspeicher gespeichert.
  • In direktem Bezug zur Operation der Standardbusadapter schließen diese Meldungen alle Meldungs-IDs ein, die von den Applikations-ECUs ausgegeben werden, in Systemen auf dem Stand der Technik im Regelfall aktive Schreibanforderungen für spezifische Dateninformationen an das Fahrzeugdomain-Netzwerk (z.B. 'Lenkeinschlagwinkel abrufen'). Wie schon erklärt, erfaßt der VNA diesen spezifischen Datentyp kontinuierlich – obwohl in diesem Moment keine Anforderungen für Meldungen von den angehängten ECUs eingehen.
  • In Abhängigkeit von den Gesamtsystemanforderungen kann der VNA-Controller einen 'Zeitstempel' – der von der internen Echtzeituhr (RTC – Real-Time-Clock) geliefert wird – an das entsprechende Datenfeld der zu bearbeitenden Meldung anhängen. Eine weitere Aufgabe des VNA-Controllers ist das Bewahren (vorhergehende Meldungen beibehalten/überspringen) der Meldungsdatenablage, um so in der Lage zu sein, für jeden Zeitpunkt die aktuellsten Daten/Meldungen zu liefern.
  • Somit wird, wieder unter Bezugnahme auf den Betrieb von Standard-Bus-Adaptern, der VNA, anstatt real Zugriff auf das Netzwerk zu nehmen, die aktiv Daten aus Einheiten im Fahrzeugdomain-Netzwerk anfordernden ECUs einfach durch Abrufen der in der VNA-Datenablage gespeicherten Daten/Meldung bedienen – die durch den kontinuierlichen VNA-Überwachungsprozeß kontinuierlich erfaßt werden. Diese Täuschung, die einen aktiven Zugriff auf den Fahrzeugbus simuliert, wird von der anfordernden Applikations-ECU-Einheit nicht erkannt, und die Datenlieferung erscheint dem Anforderer wie ein Netzwerkzugriff in Echtzeit.
  • Für zusätzliche Betriebsmodi könnte der VNA aktiviert werden, um ausgewählte Echtzeitdaten, die durch das Applikationsprogramm vordefiniert sind (z.B. Fahrzeuggeschwindigkeit, Motortemperatur u.a.) über den sekundären VNA-Zugriffs-Port an alle an das sekundäre Bus-Link angehängten ECUs zu senden. Unter Vorgabe dieser 'Fahrzeuginternas' wird das in 1 gezeigte beispielhafte System aktiviert und vorbereitet, ein ganzes neues Applikationsspektrum vorzusehen. In Kombination mit einem drahtlosen Link, das ferne Netzwerke (z.B. GSM, Internet) an das Fahrzeug anschließt, wird die beispielhafte 'Network/Client Processing Unit' in die Lage versetzt, zwingende Funktionen, wie On-line Ferndiagnose, elektronische Fernwartung, dynamische Navigation, Notruf, fortgeschrittene Fahrzeugsteuerung – und viele andere – zu unterstützen.
  • Bei der derzeitigen Kraftfahrzeug-Marktlage sind alle diese Applikationen nur durch OEM-(Originalgerätehersteller)-Systeme vorgesehen, die von Anfang an in Auftrag gegeben und bei der Produktion in das Fahrzeug eingebaut werden. Im Regelfall sind diese Funktionen sehr kostenintensive 'Extras' und werden nur für Fahrzeugklassen der oberen Kategorien angeboten. Der VNA unterstützt die hauptsächlichen Bus/Netzwerk-Zugriffsfunktionen, die bei Standardbusadaptern bekannt sind. Es gibt keinen Unterschied zwischen Betriebsmodus, Buszugriffsverfahren und der angebotenen Funktionalität für eine Steuereinheit, die an den VNA angeschlossen wird – der VNA scheint wie ein Standardbusadapter zu arbeiten.
  • Im Gegensatz zu Standardbusadaptern wird der aktive Netzwerkzugriff virtuell ausgeführt. Auf das Netzwerk wird mittels Bereitstellen eines typischen aktiven Netzwerkzugriffs auf Anforderung der am Sekundär-Port angeschlossenen ECUs virtuell zugegriffen. Z.B. schreibt eine ECU den Befehl "get oil temperature" (Öltemperatur ablesen) über den Busadapter aktiv auf das Netzwerk – dieser Befehl repräsentiert eine Meldungsanforderung, die eine bestimmte ECU anspricht, die im Echtzeit-Netzwerk sitzt. In Wirklichkeit führt der VNA einen internen Meldungsabrufprozeß mittels Durchsuchen des VNA-internen Speichers nach den angeforderten Daten durch. Der VNA-internen Speicher enthält Daten/Meldungen, die kontinuierlich vom VNA erfaßt werden (unabhängig davon, ob sie angefordert werden oder nicht). Das schließliche Senden der angeforderten Information an die ECU erscheint der anfordernden ECU als Gesamtprozeß wie ein Standard-'active bus access' (aktiver Buszugriff) – auch wenn er keine Verbindung und Aktivität auf dem Netzwerk bewirkt.
  • In Zusammenfassung der realen Aktion läuft der VNA-Netzwerkzugriff absolut passiv ab und beeinflußt das Netzwerk weder logisch noch physikalisch. Dieses Attribut stellt den Schlüsselvorteil des VNA-Prinzips dar und ermöglicht den Zugriff auf 'nichtöffentliche', sicherheitsgebundene Netzwerke. Insbesondere gibt der VNA den Zugriff auf die internen 'geschützten' Echtzeitnetzwerke moderner Kraftfahrzeuge frei – unter Gewährleistung der unbeeinflußten Betriebssicherheit für alle Fahrzeugdomain-Funktionen – ungeachtet der Applikationen, Anzahl und Typ der applikationsbearbeitenden Einheiten, die sekundärseitig an den VNA angeschlossen sind.
  • Anders als bei Standardbusadaptern setzt der VNA keine Prioritätsverteilungstechniken ein, wie von den entsprechenden betroffenen Netzwerken vorgeschrieben. Als günstige Folge ist es ein weiteres Attribut des VNA, dass er verschiedene fahrzeuginterne 'geschützte' Echtzeitnetwerke unterstützt, ungeachtet Protokollstandard und Netzwerkbandbreite. Nur eine einzige VNA-Instanz ist erforderlich um auf die entsprechenden (individuellen) Netzwerke zur gleichen Zeit zuzugreifen. Ein ausgleichender Gateway-Controller, der alle erforderlichen Informationen auf ein einziges, noch immer geschütztes Netzwerk konzentriert, ist nicht erforderlich.
  • Nicht eingeschränkt durch die Zwangsvorgaben, die für Standard-Busadapter auf dem Stand der Technik vorgeschrieben sind, ermöglicht es der VNA, dass Fahrzeughersteller und auch Zulieferer neue Typen zwingender Erzeugnisse entwickeln, die neue, fortgeschrittene Anwendungen und Dienstleistungsangebote umfassen.
  • Das Prinzip des vorgeschlagenen Systems und der internen Struktur obiger Beschreibung, gibt eine typische VNA-Realisierung vor, die zusätzliche Ergänzungsfunktionen in der VNA-Einheit implementiert – die zu weiteren Vorteilen für das betrachtete Gesamtsystem führen.
  • Die günstigsten funktionellen Erweiterungen werden durch drei Themen abgedeckt, nämlich
    • (1) Meldungs-Vorbearbeitung
    • (2) Sekundär-Netzwerkport
    • (3) Spezifisches Datensammeln
  • Erklärung zu Funktion (1):
  • Über das Vorsehen der typischen Busadapter-Funktionalität hinaus ist eine VNA-Implementierung, die mit allen Echtzeit-Netzwerken eines Fahrzeugs verbunden ist, das prädestinierte Element zum Vorsehen zusätzlicher fortgeschrittener Meldungsüberwachungs- und Meldungsvorbearbeitungsfunktionen:
    • a) Datenreduktionsfunktionalität (ID- und/oder dateninhalt-abhängig Frequenz- oder quantitatives Filtern),
    • b) Datenablage (einschließlich Ablagedatenverwaltung),
    • c) Intelligentes Datensenden (definiert nach Mengen- und/oder Zeitfenster und/oder qualitatives Filtern), und
    • d) Generieren 'newly defined messages' (neudefinierte Meldungen) – Kombinieren/Berechnen der Daten unter Verwendung programm-vordefinierter selektiver Meldungen.
  • Im Gegensatz zu Busadaptern auf dem Stand der Technik ist der VNA infolge seiner inneren Architektur dazu prädestiniert, diese zusätzlich Funktionalität zu unterstützten, während er nur wenig kostentreibende Teile im System beibehält. Auf dem Markt erhältliche Busadapter mit fortgeschrittenem Standard sind in der Lage, nur sehr eingeschränkte Meldungs-ID-Filterfunktionen auszuführen. Die für a) bis d) beschriebenen erweiterten Funktionen müssen dann noch durch zusätzliche Softwaremodule vorgesehen werden und von der zugehörigen Applikations-CPU ausgeführt werden. Infolge der dramatischen, durch diese Routinen geforderten Leistungssteigerung auf Anforderung ist die Implementierung in der Regel auf ein anwendbares Minimum beschränkt – noch immer unter signifikanter Kostensteigerung für das System.
  • Beschreibung der Funktionen a) bis d)
  • Das von einem an mehrfache (alle) Fahrzeugdomain-Busse angeschlossenen VNA erfaßte Datenvolumen kann sich zu einem hohen Datenvolumen summieren und wird, als zweite Konsequenz, eine sehr hohe Interruptrate generieren, die an die an der Sekundärseite des VNA angeschlossenen ECUs ausgegeben wird. Beide Effekte führen potentiell zu einem erweiterten Volumen der Elektronik, zur physikalischer Größe und zu erhöhtem Stromverbrauch, und bewirken schließlich einen signifikanten Kostenanstieg für das Gesamtsystem.
  • Das Datenvolumen, ausgedrückt als Speicherplatz, kann in der Regel von den entsprechenden ECUs bereitgestellt werden. Jedoch wird die Datenverwaltung eine nicht vernachlässigbare Prozessor-Arbeitslast feststellen und kann dazu zwingen, stärkere Prozessoren für die entsprechenden Applikations-ECUs zu wählen.
  • Die von einem an z.B. vier CAN-Echtzeit-Netzwerke angeschlossenen VNA generierte Interrupt-Rate kann leicht eine Rate von über 15.000 Interrupts/s erreichen. In Abhängigkeit von der Interrupt-Latenz und von der für die Ausführung des Interrupt-Treibers benötigten Zeit, können sogar mächtige 32-Bit-Prozessoren in einem sehr hohen Grad geladen werden – und beschränken auf diese Weise dramatisch die Leistung, die für die aktuellen Applikationen noch übrig ist und von der betreffenden ECU ausgeführt werden muß. Wiederum würde diese Tatsache in der Folge zu einem drastischen Anstieg auf Anforderung für Geschwindigkeit und Leistung für den Prozessor, prozessor-unterstützte und Speichervorrichtungen führen, die von den entsprechenden Applikations-ECUs benutzt werden.
  • Aus beiden Gründen, wie oben erklärt, kann die Meldungsberechnungsfähigkeit, die von den Funktionen a) bis d) angegeben wird, einen signifikanten Vorteil für eine Gesamtsystemimplementierung bedeuten. Die VNA-interne Bearbeitungselektronik, die die VNA-Prozeßschritte 3 bis 6 ausführt, wird vorzugsweise durch einen Ablaufsteuerungs-Controller – eine Maschine mit zweckbedingtem Zustand – realisiert, der so ausgelegt ist, dass er die spezifischen VNA-Erfordernisse am besten erfüllt. Wenn die Konstruktionsbemühungen bedeutsam sind und wenn leicht erhöhte VNA-Kosten akzeptabel sind, kann ein Standard-Mikrocontroller oder ein digitaler Signalprozessor benutzt werden, um auch diese Prozeßschritte auszuführen. Bei jeder Gelegenheit können, infolge der internen Struktur des VNA, diese zusätzlichen Merkmale innerhalb der VNA-Einheit implementiert werden, und bewirken so nur sehr geringe Gesamtunkosten auf der Hardwareseite für die VNA-Einheit. Der Vorteil für das Gesamtsystem macht sich in einer drastischen Reduktion auf Anforderung zur Berechnung der Leistung für die steuernden ECUs bezahlt, und erlaubt auf diese Weise einen sehr effektiven Betrieb der zu bedienenden Anwendung.
  • Erklärungen zu Funktion (2):
  • Standardbusadapter sind in der Regel mit einem 8-Bit-Parallel-Zugriffsport ausgerüstet. Für eine Standardimplementierung kann diese Art Port identisch von der VNA vorgesehen sein. Nichtsdestoweniger regt die Art des VNA-Prinzips – in der Lage zu sein, sich an eine Vielzahl (potentiell unterschiedlicher) Netzwerke gleichzeitig anzupassen – die Unterstützung einer Vielzahl von Applikations-ECUs an, die auch an den Sekundär-VNA-Port angeschlossen sind.
  • Als einfache Lösung kann jedes Bussystem so implementiert werden, dass es als Sekundär-Port dient. Das Verwenden akzeptierter Bus-Standards ermöglicht die Unterstützung und das Anhängen von OEM-Vorrichtungen sowie auch verschiedener nachträglich eingebauter Drittsysteme. Die Anzahl der unterstützten Anschlußvorrichtungen wird durch auf das VNA-Prinzip gerichtete theoretische Argumente nicht beschränkt.
  • Das in 2 gezeigte Beispiel illustriert ein Netzwerk/Client-Applikationssystem. Am Primärzugriffs-Port ist der VNA über den Zugriff auf ein Echtzeit-Bussystem an den geschützten Bereich der Fahrzeug-Domain angeschlossen. In diesem Beispiel unterstützt der VNA ein 'Netzwerk/Client-Applikationssystem', bestehend aus drei typischen Vorrichtungen, die an die VNA- Sekundärzugriffsseite angehängt sind. Das erste System ist als Navigationssystem dargestellt, die zweite ECU zeigt eine Human-Machine Interface (HMI – Mensch-Maschine-Schnittstelle) und Multi-Media (MM) Bearbeitungsfähigkeit, und die dritte Einheit bringt die fahrzeug-externe Zugriffsmöglichkeit über das drahtlose Link und sieht auf diese Weise den breiten Bereich der e-Business-Applikationen vor, aktiviert durch Netzwerk-Server und -Provider. Jede der angeschlossenen ECUs nimmt Einfluß auf den VNA-Controller durch Gewinnen des Zugriffs auf die Fahrzeugdomain-Daten, der durch den fahrzeuginternen Echtzeit-Bus ermöglicht wird.
  • Anstatt ein standardverdrahtetes Bus-Schema zu benutzen kann ein Radio-Link-Netzwerk eine zwingende Lösung für die Sekundär-Port-Realisierung bieten. Ein Beispiel, das ein Drahtlosnetzwerk für das VNA-System benutzt, wird nachstehend gezeigt. Die in 6 gezeigte Illustration unterstützt die Kommunikation mit Mehrfacheinheiten, die in einem Nahabstands-Feld lokalisiert sind – wie es für Kraftfahrzeuge typisch ist. In dieser spezifischen Realisierung kann der VNA an jedem geeigneten physikalischen Ort innerhalb des Fahrzeugs untergebracht werden, da er keinen Kabelbaum braucht, um ihn mit den verteilten Anwendungs-ECUs zu verschalten. In der Regel kann diese Tatsache ein überragender Vorteil zum Unterstützen und aktivieren nachgerüsteter und nachträglich gekaufter Vorrichtungen sein.
  • Erklärung zu Funktion (3):
  • Identisch mit der Funktionalität, wie sie von Standard-Bus-Adaptern vorgesehen ist, ist es die primäre Aufgabe des VNA, sich an das/die spezifische(n) Netzwerk e) anzupassen und darauf zuzugreifen. In Anlehnung an den zentralen Zugriffspunkt, der angeforderte Daten und Meldungen an die entsprechenden, an den VNA-Sekundär-Port angeschlossenen Applikationsbearbeitungseinheiten schickt, liegt es nahe, die Informationsdienstleistungsfähigkeit des VNA noch weiter auszudehnen.
  • Aus diesem Grund prädestiniert eine VNA-Implementierung, die die funktionelle Erweiterung (1) und (2) wie beschrieben benutzt, den VNA als idealen Informationspartner, um zusätzliche Datendienste vorzusehen, die über die Datenerfassungsfähigkeiten hinaus gehen, die vom Zugriff auf das Fahrzeugnetzwerk vorgesehen sind. Sogar in modernen Autos, aber ganz sicher in älteren Fahrzeugen, oder ebenso wie höchst typisch für billigere Fahrzeuge, sind nicht alle gewünschten und/oder relevanten Parameter für die Applikationsbearbeitungseinheiten erforderlich, die in den Fahrzeugdomain-Netzwerken verfügbar sind. Die spezifischen Parameter können von OEM-Teilen vorgesehen werden, die ursprünglich in das Fahrzeug eingebaut wurden, oder können durch Nachrüst/Nachkaufvorrichtungen generiert werden.
  • Beispiele für diesen Typ von Dienstleistungselementen und vorgesehenen Parametern sind
    • – Außentemperatur-Sensoren am Fahrzeug
    • – Abstandsfühler, z.B. wie sie bei Einparkhilfe-Applikationen verwendet werden
    • – Regendetektoren, z.B. um den Scheibenwischer automatisch einzuschalten oder um das Sonnendach zu schließen.
    • – Alarmsensoren
    • – RDS/TMC Daten (Radiodatensystem/Verkehrsmeldungskanal)
    • – GPS Global-Positioniersystem)
    • – Positionskoordinatendaten
    • – RTC (Echtzeituhr) – gibt Zeit und Datum, z.B. durch Radio-Link-Service
    • – Tageslichtfühler
  • Da das im besonderen für komplexe Gesamtsysteme gilt, ist es sinnvoll, zum VNA zusätzliche Parametererfassungsmerkmale und spezifische Vorrichtungsschnittstellen hinzuzufügen. 3 illustriert ein Beispiel für eine typische Hardware-Implementierung und zeigt funktionelle Erweiterungen. Bei erweiterten Fähigkeiten, im Gegensatz zur Grund-Busadapterfunktion, ist der VNA an vier individuelle Echtzeit-Bussysteme angehängt, und ermöglicht das Erfassen aller Fahrzeugdomain-Daten, die vom VNA primärzugriffsseitig auf diese Netzwerke gelegt werden.
  • Beispiele für potentielles Informationserfassen und Datenabrufdienste sind
    • (a) Das RDS/TMS-Daten-Link ist an das Fahrzeug-Stereoradio angeschlossen und liefert die Verkehrsinformationen und Datendienste, die von diesen Rundfunk-Dienstleistungen angeboten werden. Dieses oder andere zusätzlich hinzugefügten Untersysteme (d.i. GPS-Einheiten) sind typisch durch serielle Standard-Links, wie RS232, über Schnittstelle angeschlossen;
    • (b) Digitaldaten-Eingabeerfassung: In der Regel unterstützt durch digitale Ports, die z.B. an die Fahrzeugtür-Kontaktschalter, Kofferraum-Kontaktschalter oder andere angeschlossen sind;
    • (c) Analog-Eingabeerfassung: In der Regel implementiert durch ADCs (A/D-Wandler), die vom VNA vorgesehen werden. Sensoren wie Temperaturelemente oder Füllstandsandanzeiger sind typische Beispiele für diese Art Elemente.
  • Alle Applikations-ECUs, die an den VNA-Sekundärport angeschlossen sind, sind so ausgelegt, dass sie diese zusätzlichen Informationen anfordern und benutzen, um weiter fortgeschrittene Anwendungen vom Gesamtsystem durchführen zu lassen.
  • Repräsentativ für fortgeschrittene Anwendungen sind
    • – Fortgeschrittene 'dynamische' Navigation unter Verwendung von RDS/TMS und Informationen, die von fahrzeuginternen Sensoren geliefert werden;
    • – Diebstahlsicherung unter Verwendung von GPS, GSM zusammen mit Daten, die von digitalen und analogen Sensoren geliefert werden.
  • Diese beiden Beispiele sollen den Ausblick auf potentielle erweiterte und neue zwingende Applikationen öffnen.
  • Hier nachstehend wird das VNA-Prinzip in weiteren Einzelheiten beschrieben.
  • Die VNA-Einheit hat als Merkmal im allgemeinen zwei Zugriffs-Ports. Primärzugriffsseitig ist der VNA an das entsprechende betrachtete Bussystem, an das angepaßt werden soll, angeschlossen. Der Sekundärport liefert die Schnittstellen zur Bearbeitungseinheit, die an das Netzwerk angepaßt werden soll. Soweit sind diese Attribute identisch mit den Bus-Adaptern/Controllern, die auf dem Stand der Technik bekannt sind.
  • Eine erste Unterscheidung kann gemacht werden durch die funktionellen Erweiterungen, die vom VNA-Prinzip ermöglicht werden, und die über die Fähigkeiten der Standard-Busadapter/Controller hinaus gehen.
    • (a) Die Primärseite kann so implementiert werden, dass sie eine Vielzahl von Netzwerkzugriffsports unterstützt – die von einer einzigen VNA-Einrichtung vorgesehen sind.
    • (b) Die primärseitig unterstützten Netzwerke können individuelle und unterschiedliche Protokolle, Prioritätenverteilungspläne und Datenformte befolgen – die von einer einzigen VNA-Einrichtung vorgesehen sind.
    • (c) Als Folge der primärseitigen Mehrfachnetzwerk-Zugriffsmöglichkeit ist es ein potentieller Vorteil des VNA-Prinzips, eine Busstruktur auch für den Sekundärzugriffsport zu unterstützen. Die Realisierung der internen Operation für die VNA-Verfahren wird in 4 durch eine Prozeßsequenz beschrieben, die fünf VNA-Prozeßschritte ausführt: Der VNA paßt an Fahrzeugnetzwerke unter Verwendung von nichtbeeinflussenden elektronischen Abtast/Meßmethoden an, z.B. kapazitives Ankoppeln, induktives Ankoppeln, Elektromagnetikfeld-Abtasten usw.,
    • (d) Signalaufbereiten unter Verwendung einer zweiphasigen Ausführung: Phase 1 – Analogaufbereitung unter Verwendung von Hochpaßfiltern und Pegelkappen. Phase 2 – Digitalbearbeitung unter Verwendung einer Erfassungsmethode, die am besten mit Hochfrequenz-Übergangs-Abtasten beschrieben wird;
    • (e) Meldungsidentifikation (Protokoll-Typ identifizieren, Meldungstyp identifizieren); Datenvollständigkeit überprüfen.
    • (f) Datenreduzierung durch intelligentes Filtern: ID-Filter (spezifisch und Bereich), Meldungsvorkommnis (Zeitfenster und Frequenzfilter). Meldungsablage-Speicherverwaltung, die den Betrieb in einem Busadaptermodus in Übereinstimmung mit "Meldung auf Anforderung" ermöglicht.
    • (g) Daten/Meldung liefern durch: Meldung auf Anforderung/Anfrage; Meldung auf Abruf, Meldungssendung.
  • Die Bearbeitungsschritte 1 bis 5 werden der Reihe nach ausgeführt. Nachstehend wird eine detaillierte Beschreibung zur Darlegung der spezifischen Operationen gegeben.
  • Im ersten Bearbeitungsschritt greift der VNA zu und erfaßt die digitalen Informationen des betrachteten Echtzeitnetzwerks. Laut den Grundregeln des VNA-Prinzips muß die Anpassung an den Echtzeit-Bus so ausgeführt werden, dass es keine Beeinflussung des Netzwerks erkennbarer Größe gibt.
  • Im allgemeinen kann man unter zwei grundlegend verschiedenen Zugriffs/Kontaktmethoden unterscheiden:
    • 1) Kontaktfreie Abfühltechniken, wie: a. Kapazitives Ankoppeln, b. Induktives Ankoppeln, und c. Elektromagnetisches Feld abtasten
    • 2) Kontaktbehaftetes Abfühlen sehr niedriger Ströme über Stromfühler, wie Hoch-Eingangsimpedanzverstärker (Impedanzwandlung).
  • Vorteilhaft ist es, einen "Anfangs"-Bandpfadfilter in die Elektronik in Schritt 1 einzubauen, der es ermöglicht, elektrisches Umgebungsrauschen auszufiltern – ein grundlegendes Grobfiltern der zu erfassenden digitalen Daten. Der Netzwerktyp und die ablaufende Bus-Protokoll-Spezifikation ist in diesem Prozeßschritt nicht relevant.
  • Die unter 2) beschriebene Zugriffs/Kontaktmethode liefert eine sehr kosteneffektive elektronische Realisierung für den Prozeßschritt 2, der für die meisten VNA-Implementierungen geeignet ist, und wird daher als Beispiel benutzt.
  • 5 illustriert einen Verstärker mit hoher Impedanz, der als primärer VNA-Zugriffs-Port benutzt wird, und der das im Zentrum stehende geschützte Netzwerk überwacht. Das beispielhafte Netzwerk für diese physikalische Adapterimplementierung benutzt ein zweiadriges elektrisches Differentialtransportmedium.
  • Typische Vertreter für diesen Typ eines Echtzeit-Netzwerks, das weitgehend in modernen Kraftfahrzeugen eingebaut ist, sind das CAN-Bussystem und das VAN-Bussystem, die allgemein in Europa benutzt werden, so beispielsweise das SAE J1939, das in von amerikanischen Kfz-Herstellern gebauten Kraftfahrzeugen benutzt wird.
  • Die in 5 gezeigte Schaltung benutzt einen Standard-Differentialverstärker, der als Impedanzwandler arbeitet. Die Primärseite der Verstärkerschaltung liefert eine hohe elektrische Impedanz und garantiert damit eine minimale Beeinflussung und elektrisches Aufladen des Fahrzeug-Domain-Netzwerks. Die vom Netzwerk durch diesen 'elektrischen Kontakt' der Busadapterlösung abgezogene Energie ist so ausgelegt, dass sie die Primäreneregiebilanz für die entsprechende Gesamtnetzwerkspezifikation auf einem unbedeutenden Wert hält.
  • Der Verstärker arbeitet im Unidirektionalmodus, und erlaubt keinen aktiven Eingriff, der das geschützte Netzwerk beeinflussen würde.
  • Das am Ausgang stehende Signal kann zum weiteren Bearbeiten der vom Eingang überwachten Signale dienen. Der Eingang ist geschützt durch antiparallel geschaltete Dioden sowie Abfangdioden, die an die hohe und die niedere Systemspannung gelegt sind.
  • In Abhängigkeit von der Entwicklung und der Dimensionierung der Klammerschaltungen kann dieses Merkmal bereits Teil der Signalaufbereitung – Teils des Prozeßschritts 2 sein.
  • Die praktische Realisierung kann ein Adapter sein, der zwischen dem Standardsteckverbinder einer beliebigen ECU-Vorrichtung eingesteckt wird, (ein Verfahren wie z.B. durch die typischen 'Dongle'-Vorrichtungen (Kopierschutzverfahren) bekannt ist, die in den Drucker-Steckverbinder eines Personalcomputers eingesteckt werden).
  • Im zweiten VNA-Prozeß werden die erfaßten Daten zu plausiblen digitale Daten umgespeichert – im Hinblick auf Datenraten und Impulsbreite – sowie die Signalspannungshöhen, die vom betreffenden System potentiell erwartet werden.
  • In der Realisierung können Standardtechniken und -methoden benutzt werden:
    • a) Abfangen nach oben und nach unten (Spannungskappen),
    • b) Bandpfad-Filtern (Analog- oder Digitaltechniken), und
    • c) Spezifische Glitch-(Rausch)-Filterschaltungen (Analog- oder Digitaltechniken).
  • Auf diese Weise zulässigkeitsgeprüft können die erfaßten digitalen Signale in geeignete Zeitsignalbeziehungen wiederhergestellt werden durch Anwenden der entsprechenden Echtzeit-Netzwerk-spezifischen Überabtastfrequenzen, die für die erwarteten Datenraten geeignet sind.
  • Der dritte Prozeßschritt wird benutzt, um das/die Echtzeit-Busprotokoll(e) zu identifizieren, und erfaßt den Meldungstyp. An diesem Punkt ist es sinnvoll, die Protokollspezifische Fehlerprüfung und den Meldungsplausibilitätstest durchlaufen zu lassen.
  • In der Spezifikation der Systemanforderungen benutzt eine VNA-Implementierung im allgemeinen eine interne Bearbeitungsmaschine. In der Regel führt diese interne VNA-Bearbeitungsmaschine diese Prozeßarbeit (und höchstwahrscheinlich auch die VNA-Prozeßschritte 4 und 5) aus.
  • Die Grundroutine, die den VNA-Prozeßschritt 3 ausführt, vergleicht das erfaßte Datenmuster mit den typischen Echtzeit-Busprotokoll-Prametern, die von der spezifischen VNA-Konfiguration vorgesehen werden (vorabgespeichert in Konfigurationsregistern). Weitere Mikroprogrammroutinen testen auf Meldungsplausibilität und Datenvollständigkeit. Nachdem auf diese Weise das Meldungsprotokoll und der Meldungstyp identifiziert ist, führen weitere Mikroprogrammroutinen die entsprechende bus-spezifische Fehlerüberprüfung (und/oder Fehlerberichtigung) durch.
  • Wenn der Bustyp und das Protokoll bekannt sind, oder ggf. auch vordefiniert sind, läßt sich dieser Programmschritt signifikant vereinfachen.
  • Gemäß der Natur des VNA-Systems wird durch virtuelles Erfassen aller auf dem geprüften Echtzeit-Netzwerk laufenden Informationen potentiell eine sprichwörtliche Flut von Daten-Meldungen generiert. Es ist daher eine Hauptaufgabe für den Prozeßschritt 4, die erhaltenen Daten-Meldungen auf die Menge und die Typen der Meldungen zurechtzustutzen, die potentiell im Mittelpunkt für die dem VNA zugeordnete ECU stehen (in der Regel eine nachgekaufte Einheit, z.B. ein MMI/MM-System).
  • Das Meldungsfiltern wird in der Regel durch einen besonderen Mikroprozessor ausgeführt (ein Signalprozessor oder eine spezifische Filterprozessorvorrichtung).
  • Über diese Leistung hinaus, kann dieser Prozessor intelligente Meldungs-Filteroperationen durchführen, wie
    • a) Quantitatives Filtern,
    • b) Zeitbeschränktes Filtern (Zeitfenster, Zeitpunkt),
    • c) Dateninhalt filtern, oder
    • d) Meldung anfügen durch Zeitstempeldaten.
  • Die 'letztendlich' gültigen Daten werden in einer Datenablage (Meldungspuffer) gespeichert. Es ist eine weitere Aufgabe des Meldungsfilter-Controller, den Meldungspuffer instandzuhalten, wie durch Löschen 'veralteter' Meldungen oder Duplikat-Informationen – oder Prioritätsmeldungen.
  • Der Bearbeitungsschritt 5 repräsentiert die Bus-Controller-Schnittstellenkompetenz zum Aufbau des 'Sekundär-Zugriffs-Ports' des VNA, der die Anschlußmöglichkeit an die fahrzeuginternen und -externen elektronischen Steuereinheiten vorsieht.
  • Busadapter auf dem Stand der Technik sehen in der Regel eine 8-Bit-Parallelschnittstelle (oder in einigen Fällen auch einen seriellen Standard-Port) vor, die es ermöglicht, einen Anschluß zur entsprechenden Steuereinheit herzustellen.
  • Bei der Differentiation wird der sekundäre VNA-Schnittstellenport vorzugsweise durch ein Standardbussystem implementiert, was die Unterstützung von Mehrfachsysteminternen und -externen ECUs unterstützt. Ungeachtet der spezifischen Realisierung unterstützt der sekundäre VNA-Port mindestens alle bekannten Funktionen, wie sie von Busadaptern auf dem Stand der Technik vorgesehen sind.
  • In Übereinstimmung mit dieser Forderung, Unterstützen aller hauptsächlichen Standard-Busadapterzugriffsmethoden, werden die Meldungen gemäß den typischen Daten/Meldungsabruftypen bearbeitet und vorgesehen, nämlich:
    • a) Meldung auf Anforderung,
    • b) Meldung auf Abruf, oder
    • c) Meldungssendung.
  • Die Typen a) und b) werden eingeleitet durch die aktiv angeschlossenen ECUs (z.B. das Navigationssystem, die HMI/IMM-Bearbeitungseinheit oder das eNet/Client-System – gezeigt in 2).
  • Mit anderen Worten, die eClient-ECU, in diesem Operationstyp, 'schreibt' eine Abrufmeldung auf den Echtzeit-Bus-Controller (VNA) und fordert damit Daten von einer spezifischen Vorrichtung an, von der bekannt ist, dass sie auf dem Echtzeitbus sitzt. Zum Beispiel könnte diese Korrespondenz sein: 'Öltemperatur angeben' – in der Erwartung einer Antwortmeldung, die die Höhe der augenblicklichen Öltemperatur angibt.
  • Wie aber bereits früher erklärt, wird diese Anforderung-Schreibe-Operation nicht in Wirklichkeit ausgeführt, da die VNA-Grundregel nicht zuläßt, dass der Echtzeitbus auf irgendeine aktive Weise beeinflußt wird.
  • Vielmehr wird diese Anforderung-Schreibe-Operation 'virtuell' ausgeführt – ausgelöst durch die Anforderung ruft der VNA-Prozessor eine Suchoperation auf, die schließlich die angeforderte Dateninformation aus dem Meldungspuffer abruft, der die 'vor-erfaßten' Meldungsinformationen enthält.
  • Der interne VNA-Prozeß wird von der aufrufenden ECU nicht erkannt. Für die aufrufende ECU sieht diese Operation genau identisch mit einem aktiven Echtzeit-Buszugriff aus – wie er typisch von einem Standardbus-Controller ausgeführt wird und entlang einer Bitübertragungsschichtvorrichtung abläuft.
  • Die Meldungssendung c) wird vom VNA-Controller eingeleitet. Die eClient-ECU wird unterbrochen und erhält die Sendungsmeldung. Höchstwahrscheinlich gewinnen die Sendemeldungen die Oberhand über die VNA Filterfähigkeiten und halten damit die eClient-ECU-Interruptrate auf einer gemäßigten Frequenz.
  • Der VNA-Prozeßschritt 5 kann durch einen dafür bestimmten Niederleistungs-Controller ausgeführt werden, jedoch kann für die Mehrzahl der Implementierungen der Prozessor, der die Operation des Schritts 4 durchführt, diese Aktivität mit abdecken.
  • Der VNA gibt den Echtzeitbus-Zugriff, mit Unterstützen der von dritter Seite installierten 'nachträglich eingebauten Vorrichtungen' sowie auch der OEM-Vorrichtungen zum Zugriff auf interne Daten im Echtzeitsystem und Verwendung derselben, die durch die Fahrzeug-Domain-Netzwerke erfaßt wurden. Das eröffnet ein neues Gebiet für Applikationen und Dienstleistungen, die heute nur durch OEM-Geräte möglich sind, die vom ursprünglichen Hersteller eingebaut werden.
  • Die Schlüsselvorteile des gezeigten Prinzips sind:
    • – Vorsehen des Zugriffs auf 'geschützte' Bus-Systeme und Netzwerke, Unterstützen der allgemeinsten Bus-Controller-Modi – 'Virtuell aktive/-Schreibmeldungsanforderung',
    • – Keine logische Beeinflussung des Netzwerks und/oder Beteiligter – 'Unsichtbarer Netzwerk-Zugriff',
    • – Kein bedeutsames elektrisches Aufladen oder Beeinflussung des Netzwerks,
    • – Keine signifikanten physikalischen Zwangsbedingungen für das Netzwerk, Daten/Meldungsreduktion durch Meldungs-Vorauswahl und Filtern,
    • – Netzwerkprotokoll-unabhängige Busüberwachung, und Kostenvorteil gegenüber dem Standard-Busadapterzugriff.
  • Typische Anwendungen der vorgeschlagenen Idee sind:.
    • – Netzwerküberwachungs-unterstützende OEM-Vorrichtungen sowie von Dritten installierte 'nachträgliche' Einbauten zum Zugriff auf Echtzeit-Netzwerke,
    • – Fortgeschrittene und neue Applikationen und Dienste, wie z.B.:
    • – Telematische Dienste (d.i. Notruf, automatischer Unfallsbericht...),
    • – Dynamische Navigation,
    • – Multimedia-Dienste,
    • – Ferndiagnosedienst
    • – Fernwartung
    • – Diebstahlsverhütung, Standort des gestohlenen Fahrzeugs,
    • – Neue, fahrzeugexterne netzwerkgestützte Dienstleistungen und Applikationen,
    • – Fahrzeugdomain-Netzwerküberwachung, Test und Diagnose,
    • – Überwachung und Diagnose für Netzwerkvorrichtungen, und
    • – Sendesystem für fahrzeuginterne und -externe Meldungen.

Claims (15)

  1. Elektronisches Steuersystem zum Bereitstellen einer Zugriffsmöglichkeit auf ein geschütztes Netzwerk, insbesondere in einem Kraftfahrzeug, für eine Teilnehmereinheit in einem zweiten Netzwerk, so dass die Sicherheit im geschützten Netzwerk nicht beeinflusst werden kann; dadurch gekennzeichnet, dass das elektronische Steuersystem mit dem geschützten Netzwerk über einen Primärzugriffs-Port verbunden ist, so dass keine signifikante elektrische und/oder physikalische Beeinflussung auf das geschützte Netzwerk ausgeübt wird; und das elektronische Steuersystem das geschützte Netzwerk nur beobachten kann ohne es zu beeinflussen; und Bereitstellung einer virtuellen Zugriffsmöglichkeit auf das geschützte Netzwerk, dadurch dass das elektronische Steuersystem Nachrichten innerhalb des geschützten Netzwerks beobachtet, und das elektronische Steuersystem eine Vielzahl beobachteter Nachrichten in einer Ablage speichert, und das elektronische Steuersystem auf eine Anfrage der Teilnehmereinheit im zweiten Netzwerk hin diese Anfrage aus der in der Ablage gespeicherten Vielzahl bereits beobachteter Nachrichten erfüllt ohne die Anfrage in das geschützte Netzwerk zu senden und dadurch eine virtuelle Zugriffsmöglichkeit bereitstellt.
  2. Elektronisches Steuersystem gemäß Anspruch 1, in dem alle Nachrichten im geschützten Netzwerk kontinuierlich beobachtet und in der Ablage gespeichert werden selbst wenn keine Anfrage von der Teilnehmereinheit des zweiten Netzwerks erfolgt.
  3. Elektronisches Steuersystem gemäß Anspruch 1, in dem das elektronisches Steuersystem mit dem zweiten Netzwerk über einen Sekundärzugriff-Port verbunden ist; und das elektronisches Steuersystem gegenüber der Teilnehmereinheit im zweiten Netzwerk den Eindruck vermittelt mit der Anfrage direkt auf das geschützte Netzwerk zuzugreifen.
  4. Elektronisches Steuersystem gemäß Anspruch 1, in dem die signifikante elektrische und/oder physikalische Beeinflussung über den Primärzugriffs-Port dadurch vermieden wird, dass eine kapazitive Ankopplung vorgesehen ist, oder eine induktive Ankopplung vorgesehen ist, oder das elektromagnetische Feld abgetastet wird, oder über einen Kontakt ein Stromfühler vorgesehen ist.
  5. Elektronisches Steuersystem gemäß einem der vorhergehenden Ansprüche, in dem das elektronisches Steuersystem die beobachtete Nachrichten nach vorgegebenen Kriterien filtert und/oder kategorisiert bevor diese in die Ablage gespeichert werden.
  6. Elektronisches Steuersystem gemäß Anspruch 5, in dem das elektronisches Steuersystem veraltetet Nachrichten durch neue Nachrichten in der Ablage ersetzt.
  7. Elektronisches Steuersystem gemäß einem der vorhergehenden Ansprüchen, in dem das elektronisches Steuersystem ausdrückliche Anforderungen, oder Anforderungen vom Polling-Modus, oder Anforderungen vom Broadcast-Modus unterstützt.
  8. Elektronisches Steuersystem gemäß einem der vorhergehenden Ansprüchen, in dem das geschützte Netzwerk und das zweite Netzwerk vom gleichen oder unterschiedlichen Netzwerk-Typ sind.
  9. Verfahren zur Bereitstellung eines virtuellen Zugriffs auf ein geschütztes Netzwerk, insbesondere in einem Kraftfahrzeug, von einer Teilnehmereinheit in einem zweiten Netzwerk dadurch gekennzeichnet, dass die Teilnehmereinheit keine signifikante elektrische und/oder physikalische Beeinflussung auf das geschützte Netzwerk ausüben kann und das geschützte Netzwerk nur beobachten kann ohne es zu beeinflussen; und in einem elektronisches Steuersystem, über welches das geschützte Netzwerk und das zweite Netzwerk verbunden sind, Nachrichten innerhalb des geschützten Netzwerks beobachtet werden, und eine Vielzahl beobachteter Nachrichten in einer Ablage gespeichert werden, und auf eine Anfrage der Teilnehmereinheit im zweiten Netzwerk hin diese Anfrage aus der in der Ablage gespeicherten Vielzahl bereits beobachteter Nachrichten erfüllt wird ohne die Anfrage in das geschützte Netzwerk zu senden und so ein virtueller Zugriff bereitgestellt wird.
  10. Verfahren gemäß Anspruch 9, in dem alle Nachrichten im geschützten Netzwerk kontinuierlich beobachtet und in der Ablage gespeichert werden selbst wenn keine Anfrage von der Teilnehmereinheit des zweiten Netzwerks erfolgt.
  11. Verfahren gemäß Anspruch 9, in dem gegenüber der Teilnehmereinheit im zweiten Netzwerk der Eindruck vermittelt wird mit der Anfrage direkt auf das geschützte Netzwerk zuzugreifen.
  12. Verfahren gemäß Anspruch 9, in dem die beobachteten Nachrichten nach vorgegebenen Kriterien gefiltert und/oder kategorisiert werden bevor diese in die Ablage gespeichert werden.
  13. Verfahren gemäß Anspruch 9, in dem veraltetet Nachrichten durch neue Nachrichten in der Ablage ersetzt werden.
  14. Verfahren gemäß einem der vorhergehenden Ansprüche 9 – 13, durch das ausdrückliche Anforderungen, oder Anforderungen vom Polling-Modus, oder Anforderungen vom Broadcast-Modus unterstützt werden.
  15. Verfahren gemäß einem der vorhergehenden Ansprüche 9 – 14 wobei das geschützte Netzwerk und das zweite Netzwerk vom gleichen oder unterschiedlichen Netzwerk-Typ sind.
DE10026918A 1999-06-19 2000-05-30 Virtueller Netzwerkadapter Expired - Fee Related DE10026918B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP99111824 1999-06-19
EP99111824 1999-06-19

Publications (2)

Publication Number Publication Date
DE10026918A1 DE10026918A1 (de) 2000-12-28
DE10026918B4 true DE10026918B4 (de) 2004-09-30

Family

ID=8238389

Family Applications (1)

Application Number Title Priority Date Filing Date
DE10026918A Expired - Fee Related DE10026918B4 (de) 1999-06-19 2000-05-30 Virtueller Netzwerkadapter

Country Status (3)

Country Link
US (1) US6571136B1 (de)
CN (1) CN1209715C (de)
DE (1) DE10026918B4 (de)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7337245B2 (en) 1999-03-26 2008-02-26 Dearborn Group, Inc. Protocol adapter for passing diagnostic messages between vehicle networks and a host computer
US6920478B2 (en) * 2000-05-11 2005-07-19 Chikka Pte Ltd. Method and system for tracking the online status of active users of an internet-based instant messaging system
DE10056548A1 (de) * 2000-11-15 2002-06-06 Bosch Gmbh Robert Verfahren zum Bereitstellen eines Zeitsignals in einem Fahrzeug
US7269482B1 (en) * 2001-04-20 2007-09-11 Vetronix Corporation In-vehicle information system and software framework
US7146260B2 (en) 2001-04-24 2006-12-05 Medius, Inc. Method and apparatus for dynamic configuration of multiprocessor system
US10298735B2 (en) 2001-04-24 2019-05-21 Northwater Intellectual Property Fund L.P. 2 Method and apparatus for dynamic configuration of a multiprocessor health data system
US6747365B2 (en) * 2001-08-31 2004-06-08 Motorola, Inc. Vehicle active network adapted to legacy architecture
US7146307B2 (en) * 2002-03-22 2006-12-05 Sun Microsystems, Inc. System and method for testing telematics software
US7178049B2 (en) 2002-04-24 2007-02-13 Medius, Inc. Method for multi-tasking multiple Java virtual machines in a secure environment
US20040048583A1 (en) * 2002-08-21 2004-03-11 Everett Gregory J. Wireless control system for multiple networks
DE60205378T2 (de) * 2002-10-01 2006-06-01 Siemens Ag Multimedia- und Telematiksystem einschliesslich Navigationssystem für Motorfahrzeuge
US20040142722A1 (en) * 2003-01-10 2004-07-22 Everett Gregory J. Databus communicator within a telemetry system
US7991396B2 (en) * 2003-06-09 2011-08-02 Qualcomm Incorporated Method and apparatus for broadcast application in a wireless communication system
US7516244B2 (en) * 2003-07-02 2009-04-07 Caterpillar Inc. Systems and methods for providing server operations in a work machine
US7983820B2 (en) 2003-07-02 2011-07-19 Caterpillar Inc. Systems and methods for providing proxy control functions in a work machine
DE10353031A1 (de) * 2003-11-06 2005-06-09 Dürr Somac GmbH Vorrichtung zum Prüfen,Einstellen,Parametrieren und Flashen ECU-gesteuerter Komponenten in Fahrzeugen oder Fahrzeugbaugruppen
DE102004015163A1 (de) * 2004-02-13 2005-08-25 Volkswagen Ag Verfahren und Einrichtung zur Diagnose von Fahrzeugen
JP2005311874A (ja) * 2004-04-23 2005-11-04 Toshiba Corp 機器操作装置、および機器操作方法
US7337650B1 (en) 2004-11-09 2008-03-04 Medius Inc. System and method for aligning sensors on a vehicle
CN100454219C (zh) * 2004-12-20 2009-01-21 浪潮电子信息产业股份有限公司 基于can总线和lin总线的车载电脑***
DE102005025068B4 (de) 2005-05-30 2007-08-02 Dürr Somac GmbH Vorrichtung und Verfahren zum Prüfen, Parametrieren und Flashen von ECU-gesteuerten Fahrzeugkomponenten
US7845008B2 (en) * 2005-12-07 2010-11-30 Lenovo (Singapore) Pte. Ltd. Virus scanner for journaling file system
US20070214233A1 (en) * 2006-03-07 2007-09-13 Daryl Cromer System and method for implementing a hypervisor for server emulation
AT507237B1 (de) * 2008-07-17 2017-10-15 Österreichisches Forschungs- Und Prüfzentrum Arsenal Ges M B H Verfahren zur personalisierung von tmc diensten
US9358924B1 (en) 2009-05-08 2016-06-07 Eagle Harbor Holdings, Llc System and method for modeling advanced automotive safety systems
US8417490B1 (en) 2009-05-11 2013-04-09 Eagle Harbor Holdings, Llc System and method for the configuration of an automotive vehicle with modeled sensors
WO2010144900A1 (en) 2009-06-12 2010-12-16 Magna Electronics Inc. Scalable integrated electronic control unit for vehicle
US8886392B1 (en) 2011-12-21 2014-11-11 Intellectual Ventures Fund 79 Llc Methods, devices, and mediums associated with managing vehicle maintenance activities
US9365162B2 (en) 2012-08-20 2016-06-14 Magna Electronics Inc. Method of obtaining data relating to a driver assistance system of a vehicle
EP2713301A1 (de) * 2012-09-27 2014-04-02 Siemens Aktiengesellschaft Verfahren und System zur Anbindung einer Steuerung für eine Maschine an ein übergeordnetes IT-System
PT2772886E (pt) * 2013-02-28 2015-07-22 Kapsch Trafficcom Ag Sistema eletrónico de bordo de veículo e método de teste para o mesmo
US20150113125A1 (en) * 2013-10-23 2015-04-23 Cisco Technology Inc. System and Method for Providing the Status of Safety Critical Systems to Untrusted Devices
US10406981B2 (en) 2014-03-20 2019-09-10 Magna Electronics Inc. Vehicle vision system with curvature estimation
US20150278150A1 (en) * 2014-03-28 2015-10-01 Ford Global Technologies, Llc In-vehicle telematics upgrades
CN109644153B (zh) 2016-04-12 2020-10-13 伽德诺克斯信息技术有限公司 具有被配置为实现安全锁定的相关设备的特别编程的计算***及其使用方法
US10708227B2 (en) 2016-07-19 2020-07-07 Magna Electronics Inc. Scalable secure gateway for vehicle
GB201807644D0 (en) 2018-05-10 2018-06-27 Tomtom Telematics Bv Contactless sensor for in-vehicle digital communications network
JP7097347B2 (ja) * 2019-12-25 2022-07-07 本田技研工業株式会社 不正診断機検出装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625002A1 (de) * 1996-06-22 1998-01-02 Daimler Benz Ag Fahrzeugkommunikationssystem
DE19815150A1 (de) * 1997-04-21 1998-10-22 Leuze Electronic Gmbh & Co Sensoranordnung

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4858232A (en) * 1988-05-20 1989-08-15 Dsc Communications Corporation Distributed switching system
EP0559214A1 (de) * 1992-03-06 1993-09-08 Pitney Bowes Inc. Ereignisgesteuertes Kommunikationsnetzwerk
US5471461A (en) * 1993-04-28 1995-11-28 Allen-Bradley Company, Inc. Digital communication network with a moderator station election process
US6009370A (en) * 1993-07-26 1999-12-28 Hitachi, Ltd. Control unit for vehicle and total control system therefor
US6085177A (en) * 1995-01-11 2000-07-04 Civic-Ddi, Llc Systems for accessing the internet and geo-defined data and associated methods
US5642360A (en) * 1995-08-28 1997-06-24 Trainin; Solomon System and method for improving network performance through inter frame spacing adaptation
SE515901C2 (sv) * 1995-12-28 2001-10-22 Dynarc Ab Resursadministrering, plan och arrangemang
US5978578A (en) * 1997-01-30 1999-11-02 Azarya; Arnon Openbus system for control automation networks
US5996025A (en) * 1997-10-31 1999-11-30 International Business Machines Corp. Network transparent access framework for multimedia serving
US6252881B1 (en) * 1999-10-29 2001-06-26 Norwood Living Trust Adaptive universal multiple access

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19625002A1 (de) * 1996-06-22 1998-01-02 Daimler Benz Ag Fahrzeugkommunikationssystem
DE19815150A1 (de) * 1997-04-21 1998-10-22 Leuze Electronic Gmbh & Co Sensoranordnung

Also Published As

Publication number Publication date
CN1283825A (zh) 2001-02-14
DE10026918A1 (de) 2000-12-28
US6571136B1 (en) 2003-05-27
CN1209715C (zh) 2005-07-06

Similar Documents

Publication Publication Date Title
DE10026918B4 (de) Virtueller Netzwerkadapter
EP2040957B1 (de) Verfahren und vorrichtung zur plausibilitätskontrolle von messwerten im kraftfahrzeugumfeld
DE102014001197B4 (de) Kompatibler Netzwerkknoten, insbesondere für CAN-Bussysteme
EP1518383A1 (de) Verfahren und vorrichtung zum senden und/oder zum empfang von informationen in verbindung mit einem fahrzeug
DE10211939A1 (de) Kopplungsvorrichtung zum Ankoppeln von Geräten an ein Bussystem
DE112013006757T5 (de) Datenverarbeitungsvorrichtung und Kommunikationssystem
DE102016009195B3 (de) Verfahren zum Extrahieren von Fahrzeugdaten aus einem Kraftfahrzeug, Steuervorrichtung und Kraftfahrzeug
DE102018217689A1 (de) Verbessertes Fahrzeugdatenkommunikationsnetz
WO2018077528A1 (de) Erkennung von manipulationen in einem can-netzwerk mittels überprüfung von can-identifiern
DE102018205264B3 (de) Verfahren zum Betreiben eines Ethernet-Bordnetzes eines Kraftfahrzeugs, Steuereinheit und Ethernet-Bordnetz
DE102018217690A1 (de) Verbessertes Fahrzeugdatenkommunikationsnetz
DE10357118A1 (de) Laden von Software-Modulen
DE19722115A1 (de) Adressierungsvorrichtung und -verfahren
EP4062591A2 (de) Verfahren zur überwachung der kommunikation auf einem kommunikationsbus, elektronische vorrichtung zum anschluss an einen kommunikationsbus, sowie zentrale überwachungsvorrichtung zum anschluss an einen kommunikationsbus
WO2003007554A1 (de) Netzwerkkomponente für ein optisches netzwerk mit notlauffunktion, insbesondere für ein optisches netzwerk in ringtopologie
DE102017206884B4 (de) Verfahren und System zum Erfassen eines Problems bei einem internetbasierten Infotainmentsystem für ein Kraftfahrzeug
EP2054782B1 (de) Datenaufnahmevorrichtung
DE102006032065A1 (de) Neuprogrammierung von elektronischen Fahrzeug-Steuereinheiten über eingebaute Peripherien für austauschbare Datenspeicher
DE102004054016A1 (de) Steuergerät zum Steuern und/oder regeln mindestens einer Fahrzeugfunktion
DE102007026934B4 (de) System und Verfahren zur Ausfalldetektion eines Sensors, insbesondere eines Winkelsensors, einer aktiven Frontlenkung in einem System mit mehreren Sensoren, insbesondere Winkelsensoren
EP4018603A1 (de) Verfahren zur positionserkennung eines busteilnehmers
WO2021047970A1 (de) Software-komponenten für eine software-architektur
DE102004020880B4 (de) Schnittstelle zur Kommunikation zwischen Fahrzeug-Applikationen und Fahrzeug-Bussystemen
DE102017222179A1 (de) Verfahren zur zentralen Verwaltung und Bereitstellung von Daten mittels eines mehrere Schnittstellen aufweisenden zentralen Speichersystems eines Fahrzeugs, Speichersystem und Fahrzeug
EP1642422B1 (de) Anpassung eines fahrzeugnetzwerks an geänderte anforderungen

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee

Effective date: 20111201