DE102012212962A1 - Gateway und fahrzeuginternes Netzwerksystem - Google Patents

Gateway und fahrzeuginternes Netzwerksystem Download PDF

Info

Publication number
DE102012212962A1
DE102012212962A1 DE102012212962A DE102012212962A DE102012212962A1 DE 102012212962 A1 DE102012212962 A1 DE 102012212962A1 DE 102012212962 A DE102012212962 A DE 102012212962A DE 102012212962 A DE102012212962 A DE 102012212962A DE 102012212962 A1 DE102012212962 A1 DE 102012212962A1
Authority
DE
Germany
Prior art keywords
session
ecu
gateway
state
request
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.)
Withdrawn
Application number
DE102012212962A
Other languages
English (en)
Inventor
Takeshi Enosaki
Masaya OHI
Yuzo Harata
Yasuyuki Takahashi
Hideki Yakabe
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.)
Denso Corp
Original Assignee
Denso 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
Priority claimed from JP2011165718A external-priority patent/JP5423736B2/ja
Priority claimed from JP2011193991A external-priority patent/JP5375905B2/ja
Application filed by Denso Corp filed Critical Denso Corp
Publication of DE102012212962A1 publication Critical patent/DE102012212962A1/de
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28Timers or timing mechanisms used in protocols
    • 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/46Interconnection of networks
    • H04L12/4604LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462LAN interconnection over a bridge based backbone
    • H04L12/4625Single bridge functionality, e.g. connection of two networks over a single bridge
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Small-Scale Networks (AREA)

Abstract

Es wird ein fahrzeuginternes System, das ein Gateway zwischen mehreren Netzwerken aufweist, beschrieben. Eines der Netzwerke spezifiziert, dass, wenn eine Quellenvorrichtung (2), die mit dem einen der Netzwerke verbunden ist, eine Anforderungsnachricht an eine Zielvorrichtung (4a, 4b, 5a, 5b) sendet, die mit einem anderen der Netzwerke verbunden ist, die Quellenvorrichtung (2) unterbrochen werden sollte, wenn die Quellenvorrichtung (2) keine Antwortnachricht innerhalb einer spezifizierten Zeit nach dem Senden der Anforderungsnachricht empfängt. Bei Empfang der Anforderungsnachricht vermittelt das Gateway die Anforderungsnachricht an die Zielvorrichtung (4a, 4b, 5a, 5b) und sendet einen Warteanforderungscode an die Quellenvorrichtung (2), um die die Quellenvorrichtung (2) anzuweisen, durch Ausdehnen der spezifizierten Zeit zu warten.

Description

  • Die vorliegende Erfindung betrifft ein Gateway und ein fahrzeuginternes Netzwerksystem, in dem das Gateway Daten zwischen Netzwerken vermittelt.
  • Ein Fahrzeug ist mit verschiedenen Vorrichtungen ausgerüstet, die über ein Netzwerk verbunden sind und Daten über dieses Netzwerk entsprechend einem vorbestimmten Kommunikationsprotokoll austauschen (siehe JP 2005 47488 A , die der US 2005 0027404 A entspricht).
  • Für den Datenaustausch zwischen den Vorrichtungen, die mit dem Netzwerk verbunden sind, spezifiziert ein Kommunikationsprotokoll, dass ein Prozess beendet wird, wenn keine Antwort innerhalb einer spezifizierten Zeit nach einer Anforderung zum Senden von Daten vorhanden ist.
  • Wenn beispielsweise bei einer Diagnosekommunikation eines CAN-Kommunikationsprotokolls ein Diagnosewerkzeug eine Anforderungsnachricht an eine elektronische Diagnosezielsteuereinheit (ECU) über ein Gateway sendet und das Diagnosewerkzeug keine Antwortnachricht, die auf die Anforderungsnachricht antwortet, innerhalb einer spezifizierten Zeit (beispielsweise 100 Millisekunden) seit dem Senden der Anforderungsnachricht an die Diagnoseziel-ECU empfängt, bestimmt das Diagnosewerkzeug, dass die Diagnoseziel-ECU die Anforderungsnachricht nicht empfangen kann.
  • In den vergangenen Jahren hat sich entsprechend einer Kommunikationsprotokolldiversifizierung die Anzahl der Gateways, die eine Protokollwandlung durchführen, erhöht und die Netzwerkkonfiguration ist komplex geworden, und demzufolge werden eine Anforderungsnachricht und eine Antwortnachricht über mehrere Gateways vermittelt. Da die Netzwerkkonfiguration komplex ist, ist es schwierig, die Antwortnachricht innerhalb einer Unterbrechungsperiode (Time-out-Periode), die in dem Kommunikationsprotokoll spezifiziert ist, zu empfangen.
  • Es gibt ein System, in dem eine Fahrzeugverwaltungs-ECU Daten von jeder ECU in einem Netzwerk überwacht, um für jede ECU einen Diagnosedienst bereitzustellen (siehe JP 2003 19931 A , die der US 2003 0009271 A entspricht).
  • Es gibt ebenfalls ein System, in dem sich ein Diagnosewerkzeug mit einem fahrzeuginternen Netzwerk verbinden kann, verschiedene Daten von jeder ECU, die mit dem fahrzeuginternen Netzwerk verbunden ist, erlangen und einen Diagnosedienst für die ECU bereitstellen kann.
  • In dem obigen System ist es möglich, verschiedene Diagnosen durch Ändern eines Einstellzustands eines speziellen Dienstes durchzuführen. Es ist beispielsweise möglich, individuell eine Sicherheitseinstellung für eine allgemeine Wartung, für einen autorisierten Händler und für einen Entwickler zu konfigurieren, und es ist möglich, die Diagnose durch Entsperren der Sicherheitseinstellung individuell durchzuführen. Bei dieser Art von System ist es möglich, eine Sicherheitssperre entsprechend Prozeduren, die in einem Kommunikationsprotokoll spezifiziert sind, zu entsperren, um die Diagnose durchzuführen. Bei der Diagnosekommunikation der CAN-Kommunikation sendet beispielsweise das Diagnosewerkzeug eine Sitzungsübergangsanforderung zum Auffordern der ECU, von einer Anfangssitzung, in der ein Sicherheitssperrzustand zu halten ist, zu einer Diagnosesitzung, in der ein Sicherheitsentsperrzustand zu halten ist, überzugehen. Als Antwort auf diese Sitzungsübergangsanforderung geht die ECU von der Anfangssitzung in die Diagnosesitzung über. Nachdem die ECU eine Sitzungsantwort (positive Antwort) als Antwort auf die Sitzungsübergangsanforderung an das Diagnosewerkzeug gesendet hat, sendet das Diagnosewerkzeug eine Sicherheitsentsperranforderung an die ECU. Auf die Einrichtung der Sicherheitsentsperrung hin gelangt die ECU in den Sicherheitsentsperrzustand.
  • In diesem System verringert die Fortsetzung des Sicherheitsentsperrzustands während einer langen Zeit die Sicherheit. Somit kehrt die ECU nach dem Verstreichen einer vorbestimmten Sitzungsunterbrechungsperiode (beispielsweise 5 Sekunden) durch Übergehen von der Sitzung, die den Sicherheitsentsperrzustand hält, zu der Sitzung, die den Sicherheitssperrzustand hält, zu dem Sicherheitssperrzustand zurück.
  • Gemäß der Diagnosekommunikation der CAN-Kommunikation kehrt der spezielle Diensteinstellzustand wie beispielsweise eine Sicherheitseinstellung, eine Türverriegelungseinstellung und Ähnliches nach dem Verstreichen einer spezifizierten Zeit zu einem Anfangszustand zurück. Außerdem werden Zeiten für verschiedene Einstellungen zum Zurückkehren zu dem Anfangszustand je Sitzung verwaltet.
  • In dem Fall einer einfachen Netzwerkkonfiguration ist es möglich, die Sicherheit der ECU aufzuheben (entsperren) und die ECU mit der oben beschriebenen Prozedur zu diagnostizieren.
  • In den vergangenen Jahren wurden jedoch entsprechend einer Diversifizierung und Verfeinerung von Diensten von fahrzeuginternen Vorrichtungen ECUs in einem Fahrzeug montiert, die verschiedene Kommunikationsprotokolle wie beispielsweise CAN, LIN, FlexRay, KWP2000 und Ähnliches unterstützen. Die ECUs, die jeweilige unterschiedliche Kommunikationsprotokolle verwenden, sind über Gateways in dem Netzwerksystem miteinander verbunden. Aufgrund dessen gibt es mehrere Gateways zwischen einem Diagnosewerkzeug und einer ECU.
  • Bei der obigen komplexen Netzwerkkonfiguration ist die Datenlatenz und -verzögerung groß. Somit kann beispielsweise die folgende Situation auftreten. Nachdem das Diagnosewerkzeug die Sitzungsübergangsanforderung an eine ECU gesendet hat und die ECU als Antwort auf die Sitzungsübergangsanforderung eine positive Antwort an das Diagnosewerkzeug gesendet hat, wird die ECU unterbrochen (Sitzungsunterbrechung bzw. Sitzungs-Time-out) und kehrt zu der Anfangssitzung zurück, bevor das Diagnosewerkzeug die Sicherheitsentsperranforderung an die ECU sendet. In diesem Fall wird es unmöglich, die ECU zu diagnostizieren.
  • Die vorliegende Erfindung entstand im Hinblick auf Obiges. Es ist eine Aufgabe der vorliegenden Erfindung, ein Gateway und ein fahrzeuginternes Netzwerksystem zu schaffen, die eine normale Beendigung verschiedener Dienste wie beispielsweise eines Diagnosedienstes oder Ähnlichem sogar dann ermöglichen, wenn eine Unterbrechung bzw. ein Time-out aufgrund von Kommunikationsprotokollspezifikationen, Sicherheiteinstellungen oder Ähnlichem auftritt.
  • Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Gateway zum Durchführen einer Datenvermittlung zwischen mehreren Netzwerken geschaffen, wobei mindestens eines der Netzwerke spezifiziert, dass, wenn eine Quellenvorrichtung, die mit dem mindestens einen der Netzwerke verbunden ist, eine Anforderungsnachricht an eine Zielvorrichtung, die mit einem anderen der Netzwerke verbunden ist, das sich von dem mindestens einen der Netzwerke unterscheidet, sendet, die Quellenvorrichtung unterbrochen werden sollte, wenn die Quellenvorrichtung innerhalb einer spezifizierten Zeit nach dem Senden der Anforderungsnachricht keine Antwortnachricht, die auf die Anforderungsnachricht antwortet, empfängt. Das Gateway weist eine Warteanforderungssendevorrichtung auf, die bei Empfang der Anforderungsnachricht, die von der Quellenvorrichtung an die Zielvorrichtung gesendet wird, die Anforderungsnachricht an die Zielvorrichtung vermittelt und an die Quellenvorrichtung einen Warteanforderungscode sendet, der die Quellenvorrichtung anweist, durch Ausdehnen der spezifizierten Zeit zu warten.
  • Gemäß dem obigen Gateway wird es möglich, verschiedene Dienste wie beispielsweise einen Diagnosedienst oder Ähnliches sogar dann bereitzustellen, wenn eine Unterbrechung aufgrund von Kommunikationsprotokollspezifikationen, Sicherheitseinstellungen oder Ähnlichem auftritt.
  • Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein fahrzeuginternes Netzwerksystem geschaffen. Das fahrzeuginterne Netzwerksystem weist ein Gateway auf, das zwischen einem Netzwerk, das mit einer elektronischen Steuereinheit (ECU) verbunden ist, und einem anderen Netzwerk, das mit einem Diagnosewerkzeug verbindbar ist, angeordnet ist. Das Diagnosewerkzeug ist ausgelegt, die ECU zu diagnostizieren. Wenn die ECU eine Sitzungsübergangsanforderung von dem Diagnosewerkzeug über das Gateway empfängt, geht die ECU von einer Anfangssitzung zu einer speziellen Sitzung über und sendet eine Sitzungsantwort an das Diagnosewerkzeug über das Gateway entsprechend einem Empfang der Sitzungsübergangsanforderung, wobei die Sitzungsübergangsanforderung die ECU auffordert, von der Anfangssitzung, bei der ein spezieller Diensteinstellzustand ein Anfangszustand ist, zu der speziellen Sitzung, bei der der spezielle Diensteinstellzustand ein spezieller Zustand ist, der sich von dem Anfangszustand unterscheidet, überzugehen. Wenn das Diagnosewerkzeug die Sitzungsantwort empfängt, sendet das Diagnosewerkzeug über das Gateway eine Zustandsübergangsanforderung an die ECU, wobei die Zustandsübergangsanforderung einen Übergang des speziellen Diensteinstellzustands der ECU von einem Anfangszustand in den speziellen Zustand anfordert. Wenn die ECU die Zustandsübergangsanforderung über das Gateway von dem Diagnosewerkzeug in einem Zustand empfängt, in dem die ECU zu der speziellen Sitzung übergegangen ist, geht der spezielle Diensteinstellzustand der ECU von dem Anfangszustand in den speziellen Zustand über. Bei Verstreichen einer spezifizierten Zeit seit dem Übergang der ECU von der Anfangssitzung zu der speziellen Sitzung geht die ECU von der speziellen Sitzung zu der Anfangssitzung über, und der spezielle Diensteinstellzustand kehrt zu dem Anfangszustand zurück. Das Gateway enthält einen ersten Zeitnehmer, eine Sitzungszustandsaufzeichnungsvorrichtung und eine Sitzungshalteanforderungssendevorrichtung. Der erste Zeitnehmer misst eine verstrichene Zeit, seitdem das Gateway die Sitzungsübergangsanforderung empfangen hat, die von dem Diagnosewerkzeug an die ECU gesendet wurde, um die ECU aufzufordern, von der Anfangssitzung zu der speziellen Sitzung überzugehen. Die Sitzungszustandsaufzeichnungsvorrichtung schätzt einen Sitzungszustand der ECU, der von dem Diagnosewerkzeug erkannt wird, auf der Grundlage der verstrichenen Zeit, die von dem ersten Zeitnehmer gemessen wird, und zeichnet den geschätzten Sitzungszustand der ECU in einem Speichermedium auf. In Fällen, in denen der Sitzungszustand der ECU, der von dem Diagnosewerkzeug erkannt wird, auf der Grundlage des Sitzungszustands der ECU, der in dem Speichermedium gespeichert ist, als die spezielle Sitzung bestimmt wird, sendet die Sitzungshalteanforderungssendevorrichtung eine Sitzungszustandshalteanforderung, die die ECU anweist, die spezielle Sitzung zu halten, an die ECU, um zu verhindern, dass die ECU von der speziellen Sitzung zu der Anfangssitzung übergeht.
  • Gemäß dem obigen fahrzeuginternen Netzwerksystem wird es möglich, verschiedene Dienste wie beispielsweise einen Diagnosedienst oder Ähnliches sogar dann bereitzustellen, wenn eine Unterbrechung aufgrund von Kommunikationsprotokollspezifikationen, Sicherheitseinstellungen oder Ähnlichem auftritt.
  • Die obigen und weitere Aufgaben, Merkmale und Vorteile der vorliegenden Erfindung werden anhand der folgenden detaillierten Beschreibung mit Bezug auf die zugehörigen Zeichnungen deutlich. Es zeigen:
  • 1 ein Diagramm, das ein fahrzeuginternes LAN-System, das ein Gateway enthält, darstellt;
  • 2 ein Diagramm, das einen Signalfluss zwischen einem Diagnosewerkzeug, einem Gateway und einer ECU gemäß einer ersten Ausführungsform darstellt;
  • 3 ein Diagramm, das ein Rahmenformat eines Warteanforderungscodes gemäß der ersten Ausführungsform darstellt;
  • 4 ein Flussdiagramm, das eine Verarbeitung darstellt, die von einem Gateway gemäß der ersten Ausführungsform durchgeführt wird;
  • 5 ein Diagramm, das ein Lernergebnis einer Vermittlungshistorie gemäß der ersten Ausführungsform darstellt;
  • 6 ein Blockdiagramm, das ein Gateway darstellt;
  • 7 ein Diagramm, das einen Sitzungszustand, der von einem Gateway gemäß der zweiten Ausführungsform verwaltet wird, darstellt;
  • 8 ein Flussdiagramm, das eine Verarbeitung eines Gateway gemäß einer zweiten Ausführungsform darstellt;
  • 9 ein Flussdiagramm, das einen Fluss B gemäß der zweiten Ausführungsform darstellt;
  • 10 ein Flussdiagramm, das einen Fluss C gemäß der zweiten Ausführungsform darstellt; und
  • 11 ein Diagramm, das einen Signalfluss zwischen einem Diagnosewerkzeug, einem Gateway und einer ECU gemäß der zweiten Ausführungsform darstellt.
  • (Erste Ausführungsform)
  • Ein fahrzeuginternes LAN-System, das ein Gateway einer ersten Ausführungsform enthält, ist in 1 dargestellt. Das fahrzeuginterne LAN-System enthält Gateways 1a, 1b, ECUs 3a, 3b, 4a, 4b, 5a, 5b sowie Busse A, B, C.
  • Die ECUs 3a, 3b und das Diagnosewerkzeug 2 sind über den Bus A verbunden. Die ECUs 4a, 4b sind mit dem Bus B verbunden. Die ECUs 5a, 5b sind mit dem Bus C verbundne.
  • Die Netzwerke, die mit dem Bus A, dem Bus B und dem Bus C verbunden sind, unterscheiden sich hinsichtlich des Kommunikationsprotokolls. In der vorliegenden Ausführungsform ist das Kommunikationsprotokoll des Busses A ein CAN-Kommunikationsprotokoll. Das Kommunikationsprotokoll des Busses B ist ein CAN-Kommunikationsprotokoll. Das Kommunikationsprotokoll des Busses C ist ein FlexRay-Kommunikationsprotokoll.
  • Jedes Gateway 1a, 1b enthält eine zentrale Verarbeitungseinheit (CPU) 100, einen Nur-Lese-Speicher (ROM) 101, einen Speicher mit wahlfreiem Zugriff (RAM) 102 und eine Steuerung eines lokalen Netzwerks (LAN) bzw. LAN-Steuerung 103, 104, wie es in 6 gezeigt ist. Die CPU 100 führt verschiedene Prozesse entsprechend Programmen, die in dem ROM 101 gespeichert sind, aus. Das Gateway 1a und das Gateway 1b weisen im Wesentlichen dieselbe Konfiguration auf. Die LAN-Steuerung 103, 104 führt eine Datenübertragung und einen Datenempfang entsprechend einem Datenformat, das in den jeweiligen Kommunikationsprotokollen spezifiziert ist, durch.
  • Die Gateway-Vorrichtung 1a führt eine Protokollwandlung zwischen dem Kommunikationsprotokoll des Busses A und dem Kommunikationsprotokoll des Busses B durch, um die Daten zu vermitteln. Das Gateway 1b führt eine Protokollwandlung zwischen dem Kommunikationsprotokoll des Busses B und dem Kommunikationsprotokoll des Busses C durch, um die Daten zu vermitteln.
  • Ein Diagnosewerkzeug 2, das eine Vielzahl von Informationen von jeder ECU sammelt, um eine Fehlerdiagnose oder Ähnliches durchzuführen, ist mit dem Bus A verbunden.
  • Das CAN-Kommunikationsprotokoll spezifiziert, dass, wenn eine Quellenvorrichtung, die mit einem Netzwerk verbunden ist, eine Anforderungsnachricht an eine Zielvorrichtung, die mit einem anderen Netzwerk verbunden ist, sendet, die Quellenvorrichtung unterbrochen werden sollte, wenn die Quellenvorrichtung keine Antwortnachricht innerhalb einer spezifizierten Zeit nach dem Senden der Anforderungsnachricht empfängt. Oben ist die Antwortnachricht eine Nachricht, die auf die Anforderungsnachricht antwortet. Die Quellenvorrichtung, die mit dem Netzwerk verbunden ist, ist beispielsweise das Diagnosewerkzeug 2. Die Zielvorrichtung, die mit dem anderen Netzwerk verbunden ist, ist beispielsweise die ECU 4a. Wenn daher die Quellenvorrichtung die Antwortnachricht nicht innerhalb der spezifizierten Zeit nach dem Senden der Anforderungsnachricht empfängt, führt die Quellenvorrichtung eine Verarbeitung unter der Annahme durch, dass die Zielvorrichtung die Anforderungsnachricht nicht empfangen hat.
  • In der vorliegenden Ausführungsform sendet das Gateway 1a beim Vermitteln der Anforderungsnachricht oder Ähnlichem von dem Diagnosewerkzeug 2 an die ECU 4a einen Warteanforderungscode an das Diagnosewerkzeug 2, um das Diagnosewerkzeug 2 anzuweisen, durch Ausdehnen der spezifizierten Zeit (100 Millisekunden) 5 Sekunden zu warten.
  • 2 stellt einen Signalfluss zwischen dem Diagnosewerkzeug 2, dem Gateway 1a und der ECU 4a in Fällen dar, in denen die Anforderungsnachricht von dem Diagnosewerkzeug 2 an die ECU 4a gesendet wird. Mit Bezug auf 2 wird der Signalfluss zwischen dem Diagnosewerkzeug 2, dem Gateway 1a und der ECU 4a in Fällen erläutert, in denen die Anforderungsnachricht von dem Diagnosewerkzeug 2 an die ECU 4a gesendet wird.
  • Wenn das Diagnosewerkzeug 2 einen ersten Rahmen (FF) an das Gateway 1a sendet, sendet das Gateway 1a eine Flusssteuerung (FC) an das Diagnosewerkzeug 2. Beim Empfang der Flusssteuerung (FC) sendet das Diagnosewerkzeug 2 aufeinanderfolgend Rahmen #1, #2, #3. Wenn das Diagnosewerkzeug 2 das Senden des Rahmens #3 beendet, wird das Senden der Anforderungsnachricht beendet.
  • Bei Beendigung des Empfangs der Anforderungsnachricht von dem Diagnosewerkzeug 2 vermittelt das Gateway 1 die empfangene Anforderungsnachricht an die ECU 4a und sendet außerdem den Warteanforderungscode an das Diagnosewerkzeug 2, um das Diagnosewerkzeug 2 anzuweisen, die spezifizierte Zeit (100 Millisekunden) zu erweitern und 5 Sekunden zu warten. Wenn beispielsweise das Gateway 1a den Empfang der Anforderungsnachricht von dem Diagnosewerkzeug 2 beendet hat, sendet das Gateway 1a unmittelbar einen Code NRC 0x78, der in der Diagnosekommunikation des CAN-Kommunikationsprotokolls spezifiziert ist, als den Warteanforderungscode an das Diagnosewerkzeug 2. Wenn das Gateway 1a den ersten Rahmen (FF) an die ECU 4a sendet und die ECU 4a die Flusssteuerung (FC) an das Gateway 1a sendet, sendet das Gateway 1a aufeinanderfolgend den Rahmen #1, den Rahmen #2 und den Rahmen #3 an die ECU 4a. Wie es aus Obigem ersichtlich ist, tauschen das Diagnosewerkzeug 2 und das Gateway 1a verschiedene Arten von Rahmen aus, um die Vermittlung der Anforderungsnachricht zu beenden.
  • Bei Beendigung des Empfangs der Anforderungsnachricht sendet die ECU 4a die Antwortnachricht an das Diagnosewerkzeug 2, um auf die Anforderungsnachricht zu antworten. Insbesondere wenn die ECU 4a einen ersten Rahmen (FF) an das Gateway 1a sendet und das Gateway 1a eine Flusssteuerung (FC) an die ECU 4a sendet, sendet die ECU 4a aufeinanderfolgend Rahmen (CF) #1, #2, #3 an das Gateway 1a. Wie es aus Obigem ersichtlich ist, tauschen die ECU 4a und das Gateway 1a verschiedene Arten von Rahmen aus, um ein Senden der Antwortnachricht zu beenden.
  • Bei Beendigung des Empfangs der Antwortnachricht vermittelt das Gateway 1a die empfangene Antwortnachricht an das Diagnosewerkzeug 2. Insbesondere wenn das Gateway 1a den ersten Rahmen (FF) an das Diagnosewerkzeug 2 sendet und das Diagnosewerkzeug 2 die Flusssteuerung (FC) an das Gateway 1a sendet, sendet das Gateway 1a aufeinanderfolgend den Rahmen (CF) #1, den Rahmen (CF) #2 und den Rahmen (CF) #3 an das Diagnosewerkzeug 2. Wie es aus Obigem ersichtlich ist, tauschen das Diagnosewerkzeug 2 und das Gateway 1a verschiedene Arten von Rahmen aus, um die Vermittlung der Antwortnachricht zu vollenden.
  • Das Diagnosewerkzeug 2 misst unter Verwendung eines Zeitnehmers eine Zeitdauer von einem Zeitpunkt des Starts des Sendens der Anforderungsnachricht bis zu einem Zeitpunkt des Empfangs der Antwortnachricht. Wenn das Diagnosewerkzeug 2 die Antwortnachricht nach Verstreichen von 100 Millisekunden nicht empfängt, wird das Diagnosewerkzeug 2 gewöhnlich unterbrochen. Wenn jedoch das Diagnosewerkzeug 2 den Warteanforderungscode empfängt, setzt das Diagnosewerkzeug 2 den Zeitnehmer zurück und ändert die spezifizierte Zeit (Unterbrechungsperiode) von 100 Millisekunden auf 5 Sekunden. Daher kann das Diagnosewerkzeug 2 sogar in einer Situation, in der das Diagnosewerkzeug 2 die Antwortnachricht aufgrund der Datenvermittlung an die ECU über viele Gateways nicht innerhalb der spezifizierten Zeit (Unterbrechungsperiode) empfangen kann, die Antwortnachricht ohne Unterbrechung (Time-out) empfangen. Dieses kommt daher, dass das Gateway 1a den Warteanforderungscode an das Diagnosewerkzeug 2 senden kann und die spezifizierte Zeit (Unterbrechungsperiode) auf der Seite des Diagnosewerkzeugs 2 ausgedehnt werden kann.
  • 3 ist ein Diagramm, das ein Rahmenformat eines Codes NRC 0x78 darstellt. In der vorliegenden Ausführungsform wird der Code NRC 0x78, der das in 3 dargestellte Rahmenformat aufweist, als der Warteanforderungscode an die Quellenvorrichtung (beispielsweise das Diagnosewerkzeug 2) gesendet.
  • Die Verarbeitung des Gateway 1a in Fällen, in denen das Gateway 1a die Daten zwischen dem Diagnosewerkzeug 2 und der ECU 5a vermittelt, wird im Folgenden beschrieben. 4 ist ein Flussdiagramm, das die Verarbeitung des Gateway 1a darstellt. Das Gateway 1a (insbesondere die CPU 100) führt die Verarbeitung, die in 4 dargestellt ist, in regelmäßigen Intervallen durch.
  • In Schritt S1100 bestimmt das Gateway 1a, ob das Gateway 1a die Anforderungsnachricht empfängt. Wenn die Anforderungsnachricht nicht empfangen wird, was NEIN in Schritt S1100 entspricht, wiederholt das Gateway 1a die Durchführung der Bestimmung in Schritt S1100.
  • Wenn die Anforderungsnachricht, die von dem Diagnosewerkzeug 2 an die ECU 5a gesendet wird, empfangen wird, was JA in Schritt S1100 entspricht, schreitet die Verarbeitung zum Schritt S1102. In Schritt S1102 vermittelt das Gateway 1a diese Anforderungsnachricht an die ECU 5a. Insbesondere vermittelt das Gateway 1a die Anforderungsnachricht an die ECU 5a über das Gateway 1b durch Durchführen der Protokollwandlung von dem CAN-Kommunikationsprotokoll des Busses A in das LIN-Kommunikationsprotokoll des Busses B.
  • In Schritt S1104 startet das Gateway 1a mit dem Messen der Zeit. Insbesondere startet das Gateway 1a die Zeitmessung durch Zurücksetzen des Zeitnehmers.
  • In Schritt S1106 bestimmt das Gateway 1a auf der Grundlage einer unten beschriebenen Vermittlungshistorie, ob es notwendig ist, den Warteanforderungscode auf der Grundlage der Vermittlungshistorie zu senden. Hier wird angenommen, dass es notwendig ist, den Warteanforderungscode zu senden. In diesem Fall führt die Bestimmung in Schritt S1106 zu JA, und die Verarbeitung schreitet zum Schritt S1108. In Schritt S1108 sendet das Gateway 1a den Warteanforderungscode. Insbesondere sendet das Gateway 1a den Code NRC 0x78, der in der Diagnosekommunikation des CAN-Kommunikationsprotokolls spezifiziert ist, als den Warteanforderungscode an das Diagnosewerkzeug 2.
  • In Schritt S1110 bestimmt das Gateway 1a, ob das Gateway 1a den Warteanforderungscode innerhalb einer spezifizierten Zeit empfängt. Wenn beispielsweise die Anforderungsnachricht, die in Schritt S1102 vermittelt wird, durch das Gateway 1b an die ECU 5a vermittelt wird und der Warteanforderungscode von dem Gateway 1b an das Diagnosewerkzeug 2 gesendet wird, empfängt das Gateway 1a diesen Warteanforderungscode. In diesem Fall ist das Ergebnis der Bestimmung in Schritt S1110 JA und die Verarbeitung schreitet zum Schritt S1112. In Schritt S1112 zeichnet das Gateway 1a die gemessene Zeit in dem Speicher auf. Insbesondere zeichnet das Gateway 1a den Wert des Zeitnehmers zu einem Zeitpunkt des Empfangs des Warteanforderungscodes in dem Speicher auf.
  • In Schritt S1114 vermittelt das Gateway 1a den Warteanforderungscode an das Diagnosewerkzeug 2, und dann kehrt die Verarbeitung zum Schritt S1110 zurück, um erneut zu bestimmen, ob das Gateway 1a den Warteanforderungscode empfängt.
  • Wenn das Gateway 1a den Warteanforderungscode nicht innerhalb der spezifizierten Zeit empfängt, was NEIN in Schritt S1110 entspricht, schreitet die Verarbeitung zum Schritt S1116. In Schritt S1116 bestimmt das Gateway 1a, ob das Gateway 1a die Antwortnachricht von der ECU empfängt.
  • Wenn die ECU 5a die Anforderungsnachricht empfängt und die Antwortnachricht sendet und wenn das Gateway 1a diese Antwortnachricht empfängt, ist das Ergebnis der Bestimmung in Schritt S1116 JA und die Verarbeitung schreitet zum Schritt S1118. In Schritt S1118 zeichnet das Gateway 1a die gemessene Zeit auf. Insbesondere zeichnet das Gateway 1a den Wert des Zeitnehmers zu dem Zeitpunkt des Empfangs der Antwortnachricht auf.
  • In Schritt S1120 vermittelt das Gateway 1a die Antwortnachricht an das Diagnosewerkzeug 2. Insbesondere vermittelt das Gateway 1a die Antwortnachricht an das Diagnosewerkzeug 2 durch Durchführen der Protokollwandlung von dem LIN-Kommunikationsprotokoll des Busses B in das CAN-Kommunikationsprotokoll des Busses A.
  • In Schritt S1122 lernt das Gateway 1a die Vermittlungshistorie und beendet dann diese Verarbeitung. Wenn die Antwortnachricht von der ECU 5a nicht empfangen wird, was NEIN in Schritt S1116 entspricht, schreitet die Verarbeitung zum Schritt S1124. In Schritt S1124 meldet das Gateway 1a dem Diagnosewerkzeug 2 einen Fehler. Insbesondere sendet das Gateway 1a einen Fehlercode, der in der Diagnosekommunikation des CAN-Kommunikationsprotokolls spezifiziert ist, an das Diagnosewerkzeug 2. Danach lernt das Gateway 1a in Schritt S1122 die Vermittlungshistorie und beendet diese Verarbeitung.
  • 5 zeigt ein Beispiel eines Lernergebnisses der Vermittlungshistorie. Wie es in 5 gezeigt ist, werden für jede Ziel-ECU die Anzahl der Gateways, die Antwortzeit und Informationen, die eine Normalität oder eine Abnormität angeben, (normale/abnorme Informationen) in dem Speicher als die Vermittlungshistorie gespeichert.
  • Die Anzahl der Gateways kann anhand der Anzahl von Malen, mit der der Warteanforderungscode empfangen wird, erhalten werden. Die Antwortzeit ist eine Zeitdauer von einem Zeitpunkt der Vermittlung der Anforderungsnachricht bis zu einem Zeitpunkt des Empfangs der Antwortnachricht.
  • In der vorliegenden Ausführungsform wird, wenn die Antwortzeit kürzer als die spezifizierte Zeit (100 Millisekunden) ist, in Schritt S1106 bestimmt, dass es nicht notwendig ist, den Warteanforderungscode zu senden. Wenn die Antwortzeit länger als die spezifizierte Zeit (100 Millisekunden) ist, wird in Schritt S1106 bestimmt, dass es notwendig ist, den Warteanforderungscode zu senden.
  • Wenn ein Vermittlungsziel der Anforderungsnachricht eine ECU ist, die als abnorm bestimmt wird, wird außerdem in Schritt S1106 bestimmt, dass es nicht notwendig ist, den Warteanforderungscode zu senden. Wenn ein Vermittlungsziel der Anforderungsnachricht eine ECU ist, die als normal bestimmt wird, wird in Schritt S1106 bestimmt, dass es notwendig ist, den Warteanforderungscode zu senden.
  • Gemäß der obigen Konfiguration vermittelt das Gateway beim Empfang der Anforderungsnachricht, die von der Quellenvorrichtung an die Zielvorrichtung gesendet wird, die Anforderungsnachricht an die Zielvorrichtung und sendet an die Quellenvorrichtung den Warteanforderungscode, der die Quellenvorrichtung anweist, die spezifizierte Zeit auszudehnen und zu warten. Daher kann ohne Ausdehnung individueller Unterbrechungsperioden durch eine Vorrichtung, die mit einem Netzwerk verbunden ist, die Unterbrechung und das resultierende Misslingen des Empfangs der Antwortnachricht verhindert werden.
  • Wenn bestimmt wird, dass eine Abnormität in der Datenvermittlung vorhanden ist, meldet das Gateway der Quellenvorrichtung, dass eine Abnormität in der Datenvermittlung vorhanden ist. Daher kann die Quellenvorrichtung erkennen, dass die Abnormität in der Datenvermittlung vorhanden ist.
  • Das Gateway lernt eine Vermittlungshistorie von mindestens der Anforderungsnachricht, der Antwortnachricht oder dem Warteanforderungscode und zeichnet ein Lernergebnis der Vermittlungshistorie in einem Speichermedium auf. Auf der Grundlage des Lernergebnisses der Vermittlungshistorie, die in dem Speichermedium gespeichert ist, bestimmt das Gateway, ob es notwendig ist, den Warteanforderungscode zu senden. Wenn das Gateway bestimmt, dass es notwendig ist, den Warteanforderungscode zu senden, sendet das Gateway den Warteanforderungscode an die Quellenvorrichtung, die die Quelle der Anforderungsnachricht ist. Daher kann beispielsweise ein unnötiges Senden des Warteanforderungscodes an die Quellenvorrichtung und eine daraus resultierende Verringerung des Reaktionsvermögens verhindert werden. Außerdem kann das Diagnosewerkzeug durch Erlangen der Vermittlungshistorie von dem Gateway die Antwortzeit von dem Gateway an jede ECU und/oder die Anzahl der Gateways zwischen dem Gateway und der ECU und Ähnliches erkennen.
  • Die erste Ausführungsform kann auf verschiedene Weisen modifiziert werden, wobei Beispiele dafür im Folgenden beschrieben werden.
  • In der obigen Ausführungsform lernt das Gateway die Vermittlungshistorien der Anforderungsnachricht, der Antwortnachricht und des Warteanforderungscodes. Das Gateway kann jedoch die Vermittlungshistorie von mindestens einem aus der Anforderungsnachricht, der Antwortnachricht und dem Warteanforderungscode lernen.
  • In der oben beschriebenen Ausführungsform wird die Datenvermittlung unter der Annahme durchgeführt, dass das Diagnosewerkzeug 2 einer Quellenvorrichtung entspricht und die ECU der Zielvorrichtung entspricht. Es kann jedoch eine andere Vorrichtung als das Diagnosewerkzeug 2 und die ECU jeweils die Quellenvorrichtung oder die Zielvorrichtung sein.
  • In der obigen Ausführungsform kann das Gateway (insbesondere die CPU 100), das den Schritt S1108 durchführt, einer Warteanforderungssendevorrichtung oder -einrichtung entsprechen. Das Gateway (insbesondere die CPU 100), das den Schritt S1116 durchführt, kann einer Abnormitätsbestimmungsvorrichtung oder -einrichtung entsprechen. Das Gateway (insbesondere die CPU 100), das den Schritt S1124 durchführt, kann einer Meldevorrichtung oder -einrichtung entsprechen. Das Gateway (insbesondere die CPU 100), das den Schritt S1122 durchführt, kann einer Vermittlungshistorienlernvorrichtung oder -einrichtung entsprechen. Das Gateway (insbesondere die CPU 100), das den Schritt S1106 durchführt, kann einer Warteanforderungscodesendebestimmungsvorrichtung oder -einrichtung entsprechen. Das Gateway (insbesondere die CPU 100), das den Schritt S1104 und den Schritt S1118 durchführt, kann einer Messvorrichtung oder -einrichtung entsprechen.
  • (Zweite Ausführungsform)
  • 1 stellt außerdem eine Konfiguration eines fahrzeuginternen Netzwerksystems einer zweiten Ausführungsform dar. Das fahrzeuginterne Netzwerksystem enthält Gateways 1a, 1b (auch als Gateway-Vorrichtungen bezeichnet), ECUs 3a, 3b, 4a, 4b, 5a, 5b sowie Busse A, B, C.
  • Die ECUs 3a, 3b sind mit dem Bus A verbunden. Die ECUs 4a, 4b sind mit dem Bus B verbunden. Die ECUs 5a, 5b sind mit dem Bus C verbunden. Das Gateway 1a ist zwischen den Bus A und den Bus B geschaltet. Das Gateway 1b ist zwischen den Bus B und den Bus C geschaltet.
  • In der vorliegenden Ausführungsform ist ein Kommunikationsprotokoll des Netzwerks, das mit dem Bus A und dem Bus B verbunden ist, ein CAN-Kommunikationsprotokoll. Ein Kommunikationsprotokoll des Netzwerks, das mit dem Bus C verbunden ist, ist ein FlexRay-Kommunikationsprotokoll.
  • 6 ist ein Blockdiagramm, das das Gateway 1a, 1b darstellt. Jedes Gateway 1a, 1b enthält eine zentrale Verarbeitungseinheit (CPU) 100, einen Nur-Lese-Speicher (ROM) 101, einen Speicher mit wahlfreiem Zugriff (RAM) 102 und Steuerungen eines lokalen Netzwerks (LAN) bzw. LAN-Steuerungen 103, 104. Die CPU 100 führt verschiedene Verarbeitungen entsprechend Programmen, die in dem ROM 101 gespeichert sind, aus. Das Gateway 1a und das Gateway 1b weisen im Wesentlichen dieselbe Konfiguration auf. Die LAN-Steuerungen 103, 104 führen eine Datenübertragung und einen Datenempfang entsprechend Datenformaten, die in Kommunikationsprotokollen jeweiliger Busse A bis C spezifiziert werden, durch.
  • Das Gateway 1a vermittelt Daten zwischen dem Netzwerk des Busses A und dem Netzwerk des Busses B. Das Gateway 1b vermittelt Daten zwischen dem Netzwerk des Busses B und dem Netzwerk des Busses C.
  • Das Diagnosewerkzeug 2 sammelt eine Vielzahl von Informationen von jeder ECU, um eine Fehlerdiagnose oder Ähnliches durchzuführen. Das Diagnosewerkzeug 2 ist mit dem Bus A verbunden. Das Diagnosewerkzeug 2 kann die Sicherheitseinstellung entsperrren (deaktivieren) und die Diagnose entsprechend einer Prozedur, die in dem Kommunikationsprotokoll spezifiziert ist, durchführen. Um die Sicherheitseinstellung der ECU 5a zu entsperren und die Diagnose der ECU 5a durchzuführen, sendet das Diagnosewerkzeug 2 eine Sitzungsübergangsanforderung an die ECU 5a. Die Sitzungsübergangsanforderung fordert die ECU 5a auf, von einer Anfangssitzung, in der die Sicherheitssperre zu halten ist, zu einer Diagnosesitzung, in der die Sicherheitssperre zu deaktivieren ist, überzugehen. Dann sendet die ECU 5a eine Sitzungsantwort (positive Antwort) als Antwort auf die Sitzungsübergangsanforderung an das Diagnosewerkzeug 2. Nach Empfang dieser Sitzungsantwort sendet das Diagnosewerkzeug 2 eine Sicherheitsentsperranforderung (entspricht einer Beschränkungsentsperranforderung) an die ECU 5a. Nach Versetzen der ECU 5a in den Sicherheitsentsperrzustand diagnostiziert das Diagnosewerkzeug 2 die ECU 5a.
  • Jede der Sitzungen wie die Anfangssitzung, die Diagnosesitzung und Ähnliches bezieht sich auf eine Sitzung, die in der Sitzungsschicht spezifiziert ist, die eine der sieben Schichten des OSI-Modells (Open Systems Interconnection) ist, das von der Internationalen Organisation für Standardisierung (ISO) entwickelt wurde. Die Sitzungen beinhalten eine Programmierungssitzung, eine erweiterte Diagnosesitzung und Ähnliches zusätzlich zu der Anfangssitzung und der Diagnosesitzung.
  • In dem vorliegenden fahrzeuginternen Netzwerksystem verringert eine Fortsetzung des Sicherheitsentsperrzustands während einer langen Zeitdauer die Sicherheit. Somit kehrt die ECU 4a, 4b, 5a, 5b nach Verstreichen einer vorbestimmten Zeit (beispielsweise 5 Sekunden), die in dem Kommunikationsprotokoll spezifiziert wird, durch Übergang von der Diagnosesitzung, in der die Sicherheitssperre zu deaktivieren ist, zu der Anfangssitzung, in der die Sicherheitssperre zu halten ist, zu dem Sicherheitssperrzustand zurück.
  • Insbesondere enthält das Diagnosewerkzeug 2 einen Sitzungs-Client-Zeitnehmer zum Messen einer Zeit, seitdem eine Steuerziel-ECU von der Anfangssitzung zu der Diagnosesitzung übergegangen ist. Wenn die gemessene Zeit des Sitzungs-Client-Zeitnehmers die spezifizierte Zeit überschreitet, führt das Diagnosewerkzeug 2 eine Verarbeitung unter der Annahme durch, dass die Steuerziel-ECU zu der Anfangssitzung zurückgekehrt ist.
  • Jede ECU 3a, 3b, 4a, 4b, 5a, 5b enthält einen Sitzungs-Server-Zeitnehmer zum Verwalten eines Sitzungszustands. Wenn eine jeweilige ECU 3a, 3b, 4a, 4b, 5a, 5b ein Verstreichen der spezifizierten Zeit unter Verwendung des Sitzungs-Server-Zeitnehmers erkennt, geht die ECU 3a, 3b, 4a, 4b, 5a, 5b zu der Anfangssitzung über und kehrt zu dem Sicherheitssperrzustand zurück.
  • In dem fahrzeuginternen Netzwerksystem kehren bei Verstreichen der spezifizierten Zeit verschiedene Einstellungen wie beispielsweise die Sicherheitseinstellung, die Türverriegelungseinstellung und Ähnliches zu dem Anfangszustand zurück. Eine Zeitverwaltung beim Zurückkehren verschiedener Einstellungen zu dem Anfangszustand wird von der Sitzung durchgeführt.
  • Wenn die Netzwerkkonfigurationskomplexität die Datenvermittlung zwischen dem Diagnosewerkzeug 2 und einer Steuerziel-ECU verzögert, kann die folgende Situation auftreten. Sogar wenn die Steuerziel-ECU als Antwort auf die Anforderung von dem Diagnosewerkzeug 2 von der Anfangssitzung zu der Diagnosesitzung übergeht, wird die Steuerziel-ECU nicht innerhalb der spezifizierten Zeit diagnostiziert und geht von der Diagnosesitzung zu der Anfangssitzung über. Als Ergebnis kann die Diagnose nicht richtig durchgeführt werden.
  • Im Hinblick darauf enthält das Gateway 1a, 1b der vorliegenden Ausführungsform einen Sitzungszeitnehmer A und einen Sitzungszeitnehmer B. Der Sitzungszeitnehmer A misst eine Zeit, seitdem das Gateway die Sitzungsübergangsanforderung empfangen hat, die die Steuerziel-ECU auffordert, von der Anfangssitzung zu einer speziellen Sitzung überzugehen. Der Sitzungszeitnehmer B wird beim Anweisen der Steuerziel-ECU verwendet, den Sitzungszustand in der speziellen Sitzung zu halten, um zu verhindern, dass die Steuerziel-ECU von der speziellen Sitzung zu der Anfangssitzung übergeht. Insbesondere schätzt das Gateway auf der Grundlage der verstrichenen Zeit, die von dem Sitzungszeitnehmer A gemessen wird, den Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug erkannt wird. Das Gateway zeichnet den geschätzten Sitzungszustand der Steuerziel-ECU in dem RAM auf. Wenn das Gateway auf der Grundlage des Sitzungszustands, der in dem RAM gespeichert ist, bestimmt, dass der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug erkannt wird, die spezielle Sitzung ist, weist das Gateway unter Verwendung des Sitzungszeitnehmers B die Steuerziel-ECU an, den Sitzungszustand in der speziellen Sitzung zu halten, um zu verhindern, dass die Steuerziel-ECU von der speziellen Sitzung in die Anfangssitzung übergeht.
  • 7 stellt den Sitzungszustand, der von dem Gateway 1a verwaltet wird, dar. Das Gateway (GW) 1a enthält den Sitzungszeitnehmer A zum Verwalten der Sitzung zwischen dem Diagnosewerkzeug 2 und dem Gateway 1a und verwendet den Sitzungszeitnehmer A, um den Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, zu schätzen. Insbesondere wenn das Gateway 1a von dem Diagnosewerkzeug 2 die Sitzungsübergangsanforderung empfängt, die einen Übergang in die Diagnosesitzung anfordert, ändert das Gateway 1a den Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, von der Anfangssitzung (A-1) in die Diagnosesitzung (A-2). Wenn danach der Sitzungszeitnehmer A des Gateway 1a unterbrochen wird oder wenn das Gateway 1a von dem Diagnosewerkzeug 2 die Sitzungsübergangsanforderung empfängt, die einen Übergang in die Anfangssitzung anfordert, ändert das Gateway 1a den Sitzungszustand der Steuerziel-ECU durch das Diagnosewerkzeug 2 von der Diagnosesitzung (A-2) in die Anfangssitzung (A-1).
  • Das Gateway 1a enthält außerdem den Sitzungszeitnehmer B zum Abgleichen (i) des Sitzungszustands der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, mit (ii) einem tatsächlichen Sitzungszustand der Steuerziel-ECU. Man beachte, dass der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, unter Verwendung des Sitzungszeitnehmers A geschätzt wird. Das Gateway 1a synchronisiert den Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, mit dem tatsächlichen Sitzungszustand der Steuerziel-ECU unter Verwendung dieses Sitzungszeitnehmers B. Insbesondere misst das Gateway 1a unter Verwendung des Sitzungszeitnehmers B eine Zeit, seitdem die Steuerziel-ECU von der Anfangssitzung (B-1) in die Diagnosesitzung (B-2) übergegangen ist, und außerdem sendet das Gateway 1a regelmäßig eine Zustandshalteanforderung an die Steuerziel-ECU im Auftrag des Diagnosewerkzeugs 2 jedes Mal, wenn der Sitzungszeitnehmer B unterbrochen wird (Sitzungs-Time-out). Dieses verhindert das Auftreten des folgenden Problems: Aufgrund der Netzwerkkonfigurationskomplexität geht die Steuerziel-ECU von der Diagnosesitzung in die Anfangssitzung über, bevor das Diagnosewerkzeug 2 die Sicherheitsentsperranforderung an die Steuerziel-ECU sendet, und demzufolge stimmt der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, nicht mit dem tatsächlichen Sitzungszustand der Steuerziel-ECU überein.
  • Die 8 bis 10 stellen die Verarbeitung dar, die von dem Gateway 1a in Fällen durchgeführt wird, in denen das Diagnosewerkzeug 2 die ECU 4a diagnostiziert. Das Gateway 1a führt zyklisch die Verarbeitung, die in 8 dargestellt ist, durch. In der folgenden Erläuterung wird angenommen, dass sich die ECU 4a in der Anfangssitzung und dem Sicherheitssperrzustand befindet.
  • In Schritt S2100 bestimmt das Gateway 1a, ob das Gateway 1a eine Sitzungsanforderungsnachricht von dem Diagnosewerkzeug 2 empfängt. Wenn die Sitzungsanforderungsnachricht nicht empfangen wird, führt das Gateway 1a wiederholt die Bestimmung in Schritt S2100 durch. Wenn die Sitzungsanforderungsnachricht empfangen wird, was JA in Schritt S2100 entspricht, schreitet die Verarbeitung zum Schritt S2102. In Schritt S2102 vermittelt das Gateway 1a die Sitzungsanforderungsnachricht an die ECU 4a.
  • Bei Empfang dieser Sitzungsanforderungsnachricht bestimmt die ECU 4a, ob die Sitzungsanforderungsnachricht die ECU 4a auffordert, in die Diagnosesitzung oder in die Anfangssitzung überzugehen. Wenn die ECU 4a bestimmt, dass die Sitzungsanforderungsnachricht die ECU 4a auffordert, in die Diagnosesitzung überzugehen, geht die ECU 4a von der Anfangssitzung in die Diagnosesitzung über. Wenn die ECU 4a bestimmt, dass die Sitzungsanforderungsnachricht die ECU 4a auffordert, in die Anfangssitzung überzugehen, hält die ECU 4a die Anfangssitzung.
  • In Schritt S2104 startet das Gateway 1a die Durchführung des in 10 dargestellten Flusses C. In diesem Fluss C vermittelt das Gateway 1a eine Sitzungsantwort, die von der ECU 4a als Antwort auf den Empfang der Sitzungsanforderungsnachricht gesendet wird, an das Diagnosewerkzeug 2. Die Details des Flusses C werden später beschrieben.
  • In Schritt S2106 bestimmt das Gateway 1a, ob die empfangene Sitzungsanforderungsnachricht eine Übergangsanforderung (d. h. eine Anforderung für einen Übergang in die Diagnosesitzung) oder eine Standardanforderung bzw. Anfangsanforderung (d. h. eine Anforderung für einen Übergang in die Anfangssitzung) ist.
  • Wenn die empfangene Sitzungsanforderungsnachricht die Standardanforderung (d. h. eine Anforderung für einen Übergang in die Anfangssitzung) ist, schreitet die Verarbeitung zum Schritt S2107. In Schritt S2107 ändert das Gateway 1a den Sitzungszustand der ECU 4a, der von dem Diagnosewerkzeug 2 erkannt wird, in einen A-1-Zustand (die Anfangssitzung). Insbesondere werden Informationen, die angeben, dass der Sitzungszustand des Diagnosewerkzeugs der A-1-Zustand (die Anfangssitzung) ist, in dem RAM aufgezeichnet. Dann kehrt die Verarbeitung zum Schritt S2100 zurück.
  • Wenn die empfangene Sitzungsanforderungsnachricht die Übergangsanforderung (d. h. eine Anforderung für einen Übergang in die Diagnosesitzung) ist, schreitet die Verarbeitung zum Schritt S2108. In Schritt S2108 ändert das Gateway 1a den Sitzungszustand der ECU 4a, der von dem Diagnosewerkzeug 2 erkannt wird, in einen A-2-Zustand (die Diagnosesitzung). Insbesondere zeichnet das Gateway 1a in dem RAM Informationen auf, die angeben, dass der Sitzungszustand der ECU 4a, der von dem Diagnosewerkzeug 2 erkannt wird, der A-2-Zustand (die Diagnosesitzung) ist. Dann schreitet die Verarbeitung zum Schritt S2110. In Schritt S2110 startet das Gateway 1a mit der Durchführung des Flusses B, der in 9 dargestellt ist. In dem Fluss B schätzt das Gateway 1a den Sitzungszustand der ECU 4a, der von der ECU 4a erkannt wird. Wenn der Sitzungszustand der ECU 4a, der von der ECU 4a erkannt wird, als eine spezielle Sitzung bestimmt wird, weist das Gateway 1a im Namen des Diagnosewerkzeugs 2 die Steuerziel-ECU an, die spezielle Sitzung zu halten, um zu verhindern, dass die Steuerziel-ECU von der speziellen Sitzung in die Anfangssitzung übergeht. Die Details des Flusses B werden später beschrieben.
  • In Schritt S2112 startet das Gateway 1a eine Zeitmessung mittels des Sitzungszeitnehmers A. Insbesondere misst das Gateway 1a unter Verwendung des Sitzungszeitnehmers A eine Zeit, seitdem der Sitzungszustand der ECU 4a, der von dem Diagnosewerkzeug 2 erkannt wird, den A-2-Zustand (Diagnosesitzung) angenommen hat.
  • In Schritt S2114 bestimmt das Gateway 1a, ob eine Zustandshalteanforderungsnachricht von dem Diagnosewerkzeug 2 vorliegt.
  • Wenn das Gateway 1a die Zustandshalteanforderungsnachricht von dem Diagnosewerkzeug 2 empfängt, was JA in Schritt S2114 entspricht, schreitet die Verarbeitung zum Schritt S2120. In Schritt S2120 lädt das Gateway 1a den Sitzungszeitnehmer A neu und hält den A-2-Zustand (Diagnosesitzung) aufrecht. Danach kehrt die Verarbeitung zum Schritt S2114 zurück. Oben bezieht sich „Neuladen“ auf „Rücksetzen eines Zählerwerts des Zeitnehmers und Neustarten des Zählens“.
  • Wenn das Gateway 1a die Zustandshalteanforderungsnachricht von dem Diagnosewerkzeug 2 nicht empfängt, was NEIN in Schritt S2114 entspricht, schreitet die Verarbeitung zum Schritt S2116. In Schritt S2116 bestimmt das Gateway 1a, ob der Sitzungszeitnehmer A unterbrochen (time out) ist. Insbesondere bestimmt das Gateway 1a, ob die gemessene Zeit des Sitzungszeitnehmers A die spezifizierte Zeit (beispielsweise 5 Sekunden) überschreitet.
  • Wenn die gemessene Zeit des Sitzungszeitnehmers A die spezifizierte Zeit nicht überschreitet, was NEIN in Schritt S2116 entspricht, kehrt die Verarbeitung zum Schritt S2114 zurück. Wenn die gemessene Zeit des Sitzungszeitnehmers A die spezifizierte Zeit überschreitet, was JA in Schritt S2116 entspricht, schreitet die Verarbeitung zum Schritt S2118. In Schritt S2118 ändert das Gateway 1a den Sitzungszustand der ECU 4a, der von dem Diagnosewerkzeug 2 erkannt wird, von dem A-2-Zustand (Diagnosesitzung) in den A-1-Zustand (Anfangssitzung). Danach kehrt die Verarbeitung zum Schritt S2100 zurück.
  • Der Fluss B wird im Folgenden mit Bezug auf 9 erläutert. Als Antwort auf einen Befehl zum Starten des Flusses B in Schritt S2110 startet der Fluss B.
  • In Schritt S2200 wird der Sitzungszustand der Steuerziel-ECU von der Anfangssitzung (B-1) in die Diagnosesitzung (B-2) geändert. Insbesondere werden Informationen, die angeben, dass der Sitzungszustand der Steuerziel-ECU die Diagnosesitzung ist, in dem RAM aufgezeichnet.
  • In Schritt S2202 startet das Gateway 1a die Zeitmessung des Sitzungszeitnehmers B. In Schritt S2204 bestimmt das Gateway 1a, ob der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, die Anfangssitzung (A-1) ist.
  • Wenn der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, die Diagnosesitzung (A-2) ist, was NEIN in Schritt S2204 entspricht, schreitet die Verarbeitung zum Schritt S2206. In Schritt S2206 bestimmt das Gateway 1a, ob der Sitzungszeitnehmer B unterbrochen (time out) ist.
  • Wenn der Sitzungszeitnehmer B nicht unterbrochen ist, was NEIN in Schritt S2206 entspricht, kehrt die Verarbeitung zum Schritt S2204 zurück. Wenn der Sitzungszeitnehmer B unterbrochen ist, was JA in Schritt S2206 entspricht, schreitet die Verarbeitung zum Schritt S2208. In Schritt S2208 sendet das Gateway 1a an die Steuerziel-ECU 4a die Zustandshalteanforderung, die die Steuerziel-ECU 4a anweist, die Diagnosesitzung zu halten. In Schritt S2210 lädt das Gateway 1a den Sitzungszeitnehmer B neu, und die Verarbeitung kehrt zum Schritt S2204 zurück.
  • Wenn der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, die Anfangssitzung (A-1) ist, was JA in Schritt S2204 entspricht, schreitet die Verarbeitung zum Schritt S2212. In Schritt S2212 ändert das Gateway 1a den Sitzungszustand der Steuerziel-ECU von der Diagnosesitzung (B-2) in die Anfangssitzung (B-1). Auf die obige Weise wird der Sitzungszustand der Steuerziel-ECU, der von dem Diagnosewerkzeug 2 erkannt wird, mit dem Sitzungszustand der Steuerziel-ECU synchronisiert.
  • Mit Bezug auf 10 wird im Folgenden der Fluss C erläutert. Als Antwort auf einen Befehl zum Starten des Flusses C in Schritt S2114 startet der Fluss C.
  • In Schritt S2300 startet das Gateway 1a die Zeitmessung eines Zeitnehmers P2. Der Zeitnehmer P2 wird zum Bestimmen, ob eine Zeitdauer von einem ersten Zeitpunkt zu einem zweiten Zeitpunkt innerhalb einer spezifizierten Zeit liegt, verwendet. Der erste Zeitpunkt ist ein Zeitpunkt, zu dem die Sitzungsanforderungsnachricht, die von dem Diagnosewerkzeug 2 gesendet wird, durch das Gateway 1a an die Steuerziel-ECU vermittelt wird. Der zweite Zeitpunkt ist ein Zeitpunkt, zu dem das Gateway 1a die Sitzungsanwort, die die Steuerziel-ECU als Antwort auf den Empfang der Sitzungsanforderungsnachricht sendet, empfängt.
  • In Schritt S2302 bestimmt das Gateway 1a, ob das Gateway 1a die Sitzungsantwortnachricht empfängt. Wenn das Gateway 1a die Sitzungsantwortnachricht nicht empfängt, was NEIN in Schritt S2302 entspricht, schreitet die Verarbeitung zum Schritt S2312. In Schritt S2312 bestimmt das Gateway 1a, ob der Zeitnehmer P2 unterbrochen (time out) ist. Insbesondere bestimmt das Gateway 1a, ob der Zeitnehmer P2 die spezifizierte Zeit überschreitet.
  • Wenn der Zeitnehmer P2 die spezifizierte Zeit überschreitet, was NEIN in Schritt S2312 entspricht, kehrt die Verarbeitung zum Schritt S2302 zurück. Wenn das Gateway 1a die Sitzungsantwortnachricht von der ECU 4a empfängt, bevor der Zeitnehmer P2 die spezifizierte Zeit überschreitet, was JA in Schritt S2302 entspricht, schreitet die Verarbeitung zum Schritt S2304. In Schritt S2304 bestimmt das Gateway 1a, ob die Sitzungsantwortnachricht eine positive Antwort oder eine negative Antwort ist.
  • Wenn die Sitzungsantwortnachricht die positive Antwort ist, vermittelt das Gateway 1a die Antwortnachricht an das Diagnosewerkzeug 2 und beendet diese Verarbeitung.
  • Wenn die Sitzungsantwortnachricht die negative Antwort ist, schreitet die Verarbeitung zum Schritt S2308. In Schritt S2308 vermittelt das Gateway 1a die Antwortnachricht an das Diagnosewerkzeug 2. In Schritt S2310 beendet das Gateway 1a den Fluss B und beendet diese Verarbeitung.
  • Wenn der Zeitnehmer P2 ohne Empfang der Sitzungsantwortnachricht von der ECU 4a unterbrochen wird, was JA in Schritt S2312 entspricht, schreitet die Verarbeitung zum Schritt S2310. In Schritt S2310 beendet das Gateway 1a den Fluss C und beendet diese Verarbeitung.
  • 11 stellt einen Signalfluss zwischen dem Diagnosewerkzeug 2, dem Gateway 1a und der ECU 4a in Fällen dar, in denen das Diagnosewerkzeug 2 die Anforderungsnachricht an die ECU 4a sendet. Dieser Signalfluss wird im Folgenden mit Bezug auf 11 erläutert.
  • Wenn das Diagnosewerkzeug 2 die Sitzungsübergangsanforderung an die ECU 4a sendet, vermittelt das Gateway 1a die Sitzungsübergangsanforderung an die ECU 4a und startet eine Zeitmessung des Sitzungszeitnehmers A und eine Zeitmessung des Sitzungszeitnehmers B.
  • Wenn sie diese Sitzungsübergangsanforderung empfängt, geht die ECU 4a von der Anfangssitzung in die Diagnosesitzung über und sendet die Sitzungsantwort an das Diagnosewerkzeug 2.
  • Das Gateway 1a vermittelt die Sitzungsantwort an das Diagnosewerkzeug 2. Wenn der Sitzungszeitnehmer B unterbrochen wird, sendet das Gateway 1a die Sitzungszustandshalteanforderung im Namen des Diagnosewerkzeugs 2 an die ECU 4a, um die ECU 4a anzuweisen, die Diagnosesitzung zu halten. Bei Empfang der Sitzungszustandshalteanforderung hält die ECU 4a die Diagnosesitzung.
  • Bei Empfang der Sitzungsantwort sendet das Diagnosewerkzeug 2 aufeinanderfolgend eine Sicherheitszugriffsanforderung und einen Sicherheitsschlüssel an die ECU 4a.
  • Das Gateway 1a vermittelt die Sicherheitszugriffsanforderung und den Sicherheitsschlüssel an die ECU 4a. Wenn die ECU 4a in der Diagnosesitzung die Sicherheitszugriffsanforderung und den Sicherheitsschlüssel empfängt und eine Sicherheitsentsperrung durchführt, gelangt die ECU 4a in den Sicherheitsentsperrzustand.
  • Jedes Mal, wenn der Sitzungszeitnehmer B unterbrochen wird, sendet das Gateway 1a regelmäßig die Sitzungszustandshalteanforderung an die ECU 4a. Diese Sitzungszustandshalteanforderung weist die ECU 4a an, die Diagnosesitzung zu halten.
  • Wenn die ECU 4a in den Sicherheitsentsperrzustand gelangt, ist das Diagnosewerkzeug 2 in der Lage, verschiedene Diagnosen durchzuführen.
  • Auch wenn 11 darstellt, dass die Zustandshalteanforderung, die von dem Diagnosewerkzeug 2 gesendet wird, von dem Gateway 1a nicht an die ECU vermittelt wird, kann die Zustandshalteanforderung, die von dem Diagnosewerkzeug 2 gesendet wird, von dem Gateway 1a an die ECU vermittelt werden.
  • Gemäß der vorliegenden Ausführungsform kann das Diagnosewerkzeug eine Übergangsanforderung senden, die die ECU auffordert, von der Anfangssitzung, bei der der Sicherheitseinstellzustand (entspricht einem speziellen Diensteinstellzustand) ein Sicherheitssperrzustand (entspricht einem Anfangszustand) ist, in die Diagnosesitzung (entspricht einer speziellen Sitzung), in der der Sicherheitseinstellzustand der Sicherheitsentsperrzustand (entspricht einem speziellen Zustand) ist, überzugehen. Wenn die ECU die Übergangsanforderung von dem Diagnosewerkzeug über das Gateway empfängt, geht die ECU von der Anfangssitzung zu der Diagnosesitzung über und sendet eine Sitzungsantwort an das Diagnosewerkzeug über das Gateway entsprechend dem Empfang der Sitzungsübergangsanforderung. Wenn das Diagnosewerkzeug die Sitzungsantwort empfängt, sendet das Diagnosewerkzeug eine Zustandsübergangsanforderung an die ECU über das Gateway, wobei die Zustandsübergangsanforderung einen Übergang des Sicherheitseinstellzustands der ECU von dem Sicherheitssperrzustand in den Sicherheitsentsperrzustand anfordert. Wenn die ECU die Zustandsübergangsanforderung von dem Diagnosewerkzeug über das Gateway in einem Zustand empfängt, in dem die ECU in die Diagnosesitzung übergegangen ist, geht der Sicherheitseinstellzustand der ECU von dem Sicherheitssperrzustand in den Sicherheitsentsperrzustand über. Bei Verstreichen einer spezifizierten Zeit seit dem Übergang der ECU von der Anfangssitzung zu der Diagnosesitzung geht die ECU von der Diagnosesitzung zu der Anfangssitzung über, und der Sicherheitseinstellzustand kehrt zu dem Sicherheitssperrzustand zurück. Das Gateway enthält einen Sitzungszeitnehmer A, eine Sitzungszustandsaufzeichnungsvorrichtung und eine Sitzungshalteanforderungssendevorrichtung. Der Sitzungszeitnehmer A misst eine verstrichene Zeit, seitdem das Gateway die Sitzungsübergangsanforderung empfangen hat, die von dem Diagnosewerkzeug an die ECU gesendet wurde, um die ECU aufzufordern, von der Anfangssitzung zu der Diagnosesitzung überzugehen. Die Sitzungszustandsaufzeichnungsvorrichtung schätzt einen Sitzungszustand der ECU, der von dem Diagnosewerkzeug erkannt wird, auf der Grundlage der verstrichenen Zeit, die von dem Sitzungszeitnehmer A gemessen wird, und zeichnet den geschätzten Sitzungszustand der ECU in dem RAM (entspricht einem Speichermedium) auf. Wenn der Sitzungszustand der ECU, der von dem Diagnosewerkzeug erkannt wird, basierend auf dem Sitzungszustand der ECU, der in dem RAM gespeichert ist, als die Diagnosesitzung bestimmt wird, sendet die Sitzungshalteanforderungssendevorrichtung an die ECU eine Sitzungshalteanforderung, um zu verhindern, dass die ECU von der Diagnosesitzung in die Anfangssitzung übergeht, wobei die Sitzungshalteanforderung die ECU anweist, die Diagnosesitzung zu halten. Dementsprechend ist es sogar dann, wenn eine Netzwerkkonfiguration komplex ist und die Verzögerung der Datenvermittlung groß ist, möglich, die ECU in dem geänderten speziellen Diensteinstellzustand zu diagnostizieren.
  • Das Gateway enthält außerdem den Sitzungszeitnehmer B (entspricht einem zweiten Zeitnehmer), der eine verstrichene Zeit, seitdem die Sitzungshalteanforderungssendevorrichtung die Sitzungszustandshalteanforderung an die ECU gesendet hat, misst. Somit ist es möglich, die Sitzungszustandshalteanforderung unter Verwendung des Sitzungszeitnehmers B regelmäßig zu senden, und es ist möglich, die ECU in dem geänderten speziellen Diensteinstellzustand zu diagnostizieren.
  • Wenn auf der Grundlage des Sitzungszustands der ECU, der in dem RAM gespeichert ist, bestimmt wird, dass sich der Sitzungszustand der ECU, der von dem Diagnosewerkzeug erkannt wird, in den Diagnosezustand (spezieller Zustand) geändert hat, stoppt die Sitzungshalteanforderungssendevorrichtung das Senden der Sitzungszustandshalteanforderung. Daher ist es möglich, zu verhindern, dass der Sicherheitsentsperrzustand (der geänderte spezielle Diensteinstellzustand) während einer langen Zeitdauer fortgesetzt wird, und es ist möglich, eine Verringerung der Sicherheit zu verhindern.
  • Die zweite Ausführungsform kann auf verschiedene Arten modifiziert werden, wobei Beispiele dafür im Folgenden beschrieben werden.
  • In der obigen Ausführungsform werden das CAN-Kommunikationsprotokoll und das FlexRay-Kommunikationsprotokoll als die Kommunikationsprotokolle der Kommunikationsbusse A bis C verwendet. Die Kommunikationsprotokolle sind jedoch nicht auf diese Beispiele beschränkt.
  • In der obigen Ausführungsform ist das Entsperren der Sicherheitssperre als Ändern des speziellen Diensteinstellzustands gezeigt. Dieses ist jedoch für die Ausführungsform nicht beschränkend. Die vorliegende Ausführungsform ist beispielsweise für die Änderung von Einstellzuständen verschiedener Dienste anwendbar. Insbesondere ist die vorliegende Ausführungsform anwendbar, um einen verfügbaren Bereich eines Nutzers zu ändern, um eine Sensorausgangseinstellung zu ändern, um eine Aktuatorsteuereinstellung zu ändern oder Ähnliches.
  • In der obigen Ausführungsform sendet das Diagnosewerkzeug die Übergangsanforderung, die die Steuerziel-ECU auffordert, von der Anfangssitzung, in der die Sicherheitssperre zu halten ist, in die Diagnosesitzung, in der die Sicherheit zu entsperren ist, überzugehen. Die Sitzung, in der die Sicherheit entsperrt wird, ist jedoch nicht auf die Diagnosesitzung beschränkt. Die Sitzung, in der die Sicherheit entsperrt wird, kann die Programmiersitzung, die erweiterte Diagnosesitzung oder Ähnliches sein.
  • In der obigen Ausführungsform entspricht der RAM 102 einem Speichermedium. Der Sitzungszeitnehmer A, der von der CPU 100 bereitgestellt werden kann, entspricht einem ersten Zeitnehmer. Die Schritte S2112 bis S2118, die von der CPU 100 des Gateway durchgeführt werden, können einer Sitzungszustandsaufzeichnungsvorrichtung oder -einrichtung entsprechen. Die Schritte S2202 bis S2210, die von der CPU 100 des Gateway durchgeführt werden, können einer Sitzungshalteanforderungssendevorrichtung oder -einrichtung entsprechen. Der Sitzungszeitnehmer B, der von der CPU 100 bereitgestellt werden kann, kann einem zweiten Zeitnehmer entsprechen.
  • Während die vorliegende Erfindung mit Bezug auf ihre Ausführungsformen beschrieben wurde, ist die Erfindung nicht auf die obigen Ausführungsformen und Aufbauten beschränkt. Die vorliegende Erfindung deckt verschiedene Modifikationen und äquivalente Anordnungen innerhalb des Bereichs der Ansprüche ab.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • JP 200547488 A [0002]
    • US 20050027404 A [0002]
    • JP 200319931 A [0006]
    • US 20030009271 A [0006]

Claims (9)

  1. Gateway zum Durchführen einer Datenvermittlung zwischen mehreren Netzwerken, wobei mindestens eines der Netzwerke spezifiziert, dass, wenn eine Quellenvorrichtung (2), die mit dem mindestens einen der Netzwerke verbunden ist, eine Anforderungsnachricht an eine Zielvorrichtung (4a, 4b, 5a, 5b) sendet, die mit einem anderen der Netzwerke, das sich von dem mindestens einen der Netzwerke unterscheidet, verbunden ist, die Quellenvorrichtung (2) unterbrochen werden sollte, wenn die Quellenvorrichtung (2) nicht innerhalb einer spezifizierten Zeit nach dem Senden der Anforderungsnachricht eine Antwortnachricht, die auf die Anforderungsnachricht antwortet, empfängt, wobei das Gateway aufweist: eine Warteanforderungssendevorrichtung (100, S1108), die bei Empfang der Anforderungsnachricht, die von der Quellenvorrichtung (2) an die Zielvorrichtung (4a, 4b, 5a, 5b) gesendet wird, die Anforderungsnachricht an die Zielvorrichtung (4a, 4b, 5a, 5b) vermittelt und an die Quellenvorrichtung (2) einen Warteanforderungscode sendet, der die Quellenvorrichtung (2) anweist, durch Ausdehnen der spezifizierten Zeit zu warten.
  2. Gateway nach Anspruch 1, das außerdem aufweist: eine Abnormitätsbestimmungsvorrichtung (100, S1116), die bestimmt, ob eine Abnormität in der Datenvermittlung vorhanden ist; und eine Meldevorrichtung (100, S1124), die der Quellenvorrichtung (2) ein Auftreten der Abnormität in der Datenvermittlung meldet, wenn die Abnormitätsbestimmungsvorrichtung (100, S1116) bestimmt, dass die Abnormität in der Datenvermittlung vorhanden ist.
  3. Gateway nach Anspruch 1 oder 2, das außerdem aufweist: eine Vermittlungshistorienlernvorrichtung (100, S1122), die eine Vermittlungshistorie von mindestens einem aus der Anforderungsnachricht, der Antwortnachricht oder des Warteanforderungscodes lernt, und ein Lernergebnis der Vermittlungshistorie in einem Speichermedium (102) aufzeichnet; und eine Warteanforderungscodesendebestimmungsvorrichtung (100, S1106), die auf der Grundlage des Lernergebnisses der Vermittlungshistorie, die in dem Speichermedium (102) gespeichert ist, bestimmt, ob es notwendig ist, den Warteanforderungscode zu senden, wobei wenn die Warteanforderungscodesendebestimmungsvorrichtung (100, S1106) bestimmt, dass es notwendig ist, den Warteanforderungscode zu senden, die Warteanforderungscodesendevorrichtung den Warteanforderungscode an die Quellenvorrichtung (2), die eine Quelle der Anforderungsnachricht ist, sendet.
  4. Gateway nach Anspruch 3, das außerdem aufweist: eine Messvorrichtung (100, S1104, S1118), die eine Zeitdauer von einem Zeitpunkt der Vermittlung der Anforderungsnachricht bis zu einem Zeitpunkt des Empfangs der Antwortnachricht misst, wobei die Vermittlungshistorienlernvorrichtung (100, S1122) die Zeitdauer von dem Zeitpunkt der Vermittlung der Anforderungsnachricht bis zu dem Zeitpunkt des Empfangs der Antwortnachricht als die Vermittlungshistorie der Antwortnachricht lernt.
  5. Fahrzeuginternes Netzwerksystem, das aufweist: ein Gateway (1a, 1b), das zwischen einem Netzwerk, das mit einer elektronischen Steuereinheit (ECU) verbunden ist, und einem anderen Netzwerk, das mit einem Diagnosewerkzeug (2) verbindbar ist, angeordnet ist, wobei die Diagnosevorrichtung (2) ausgelegt ist, die ECU (4a, 4b, 5a, 5b) zu diagnostizieren, wobei wenn die ECU (4a, 4b, 5a, 5b) eine Sitzungsübergangsanforderung von dem Diagnosewerkzeug (2) über das Gateway (1a, 1b) empfängt, die ECU (4a, 4b, 5a, 5b) von einer Anfangssitzung zu einer speziellen Sitzung übergeht und eine Sitzungsantwort an das Diagnosewerkzeug (2) über das Gateway (1a, 1b) entsprechend einem Empfang der Sitzungsübergangsanforderung sendet, wobei die Sitzungsübergangsanforderung die ECU (4a, 4b, 5a, 5b) auffordert, von der Anfangssitzung, bei der ein spezieller Diensteinstellzustand ein Anfangszustand ist, in die spezielle Sitzung, bei der der spezielle Diensteinstellzustand ein spezieller Zustand, der sich von dem Anfangszustand unterscheidet, ist, überzugehen; wenn das Diagnosewerkzeug (2) die Sitzungsantwort empfängt, das Diagnosewerkzeug (2) eine Zustandsübergangsanforderung an die ECU (4a, 4b, 5a, 5b) über das Gateway (1a, 1b) sendet, wobei die Zustandsübergangsanforderung einen Übergang des speziellen Diensteinstellzustands der ECU (4a, 4b, 5a, 5b) von dem Anfangszustand in den speziellen Zustand anfordert; wenn die ECU (4a, 4b, 5a, 5b) die Zustandsübergangsanforderung von dem Diagnosewerkzeug (2) über das Gateway (1a, 1b) in einem Zustand empfängt, in dem die ECU (4a, 4b, 5a, 5b) in die spezielle Sitzung übergegangen ist, der spezielle Diensteinstellzustand der ECU (4a, 4b, 5a, 5b) von dem Anfangszustand in den speziellen Zustand übergeht; und die ECU (4a, 4b, 5a, 5b) bei Verstreichen einer spezifizierten Zeit seit dem Übergang der ECU (4a, 4b, 5a, 5b) von der Anfangssitzung in die spezielle Sitzung von der speziellen Sitzung zu der Anfangssitzung übergeht und der spezielle Diensteinstellzustand zu dem Anfangszustand zurückkehrt, wobei das Gateway (1a, 1b) enthält: einen ersten Zeitnehmer (100), der eine verstrichene Zeit, seitdem das Gateway (1a, 1b) die Sitzungsübergangsanforderung empfangen hat, die von dem Diagnosewerkzeug (2) an die ECU (4a, 4b, 5a, 5b) gesendet wurde, um die ECU (4a, 4b, 5a, 5b) aufzufordern, von der Anfangssitzung zu der speziellen Sitzung überzugehen, misst; eine Sitzungszustandsaufzeichnungsvorrichtung (S2112 bis S2118), die einen Sitzungszustand der ECU, der von dem Diagnosewerkzeug (2) erkannt wird, auf der Grundlage der verstrichenen Zeit, die von dem ersten Zeitnehmer (100) gemessen wird, schätzt und den geschätzten Sitzungszustand der ECU in einem Speichermedium (102) aufzeichnet; und eine Sitzungshalteanforderungssendevorrichtung (S2202 bis S2210), die in Fällen, in denen der Sitzungszustand der ECU, der von dem Diagnosewerkzeug (2) erkannt wird, auf der Grundlage des Sitzungszustands der ECU, der in dem Speichermedium (102) gespeichert ist, als die spezielle Sitzung bestimmt wird, eine Sitzungszustandshalteanforderung, die die ECU (4a, 4b, 5a, 5b) anweist, die spezielle Sitzung zu halten, an die ECU (4a, 4b, 5a, 5b) sendet, um zu verhindern, dass die ECU (4a, 4b, 5a, 5b) von der speziellen Sitzung zu der Anfangssitzung übergeht.
  6. Fahrzeuginternes Netzwerksystem nach Anspruch 5, wobei das Gateway (1a, 1b) außerdem einen zweiten Zeitnehmer (100) enthält, der eine verstrichene Zeit, seitdem die Sitzungshalteanforderungssendevorrichtung (S2202 bis S2210) die Sitzungszustandshalteanforderung an die ECU (4a, 4b, 5a, 5b) gesendet hat, misst.
  7. Fahrzeuginternes Netzwerksystem nach Anspruch 5 oder 6, wobei die Sitzungshalteanforderungssendevorrichtung beim Bestimmen auf der Grundlage des Sitzungszustands der ECU, der in dem Speichermedium (102) gespeichert ist, dass der Sitzungszustand der ECU, der von dem Diagnosewerkzeug (2) erkannt wird, in den Anfangszustand übergeht, das Senden der Sitzungszustandshalteanforderung stoppt.
  8. Fahrzeuginternes Netzwerksystem nach einem der Ansprüche 5 bis 7, wobei der spezielle Diensteinstellzustand ein Sicherheitseinstellzustand ist; der Anfangszustand ein Sicherheitssperrzustand ist; und der spezielle Zustand ein Sicherheitsentsperrzustand ist.
  9. Gateway nach Anspruch 1, das außerdem aufweist: eine LAN-Steuerung (103, 104), die eine Datenübertragung und einen Datenempfang zwischen dem mindestens einen der Netzwerke und dem anderen der Netzwerke durchführt, wobei ein Kommunikationsprotokoll des mindestens einen der Netzwerke sich von demjenigen des anderen der Netzwerke unterscheidet.
DE102012212962A 2011-07-28 2012-07-24 Gateway und fahrzeuginternes Netzwerksystem Withdrawn DE102012212962A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2011165718A JP5423736B2 (ja) 2011-07-28 2011-07-28 ゲートウェイ装置
JP2011-165718 2011-07-28
JP2011-193991 2011-09-06
JP2011193991A JP5375905B2 (ja) 2011-09-06 2011-09-06 車載ネットワークシステム

Publications (1)

Publication Number Publication Date
DE102012212962A1 true DE102012212962A1 (de) 2013-01-31

Family

ID=47503314

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102012212962A Withdrawn DE102012212962A1 (de) 2011-07-28 2012-07-24 Gateway und fahrzeuginternes Netzwerksystem

Country Status (2)

Country Link
US (1) US9219802B2 (de)
DE (1) DE102012212962A1 (de)

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5451705B2 (ja) * 2011-09-21 2014-03-26 日立オートモティブシステムズ株式会社 自動車用電子制御装置及びデータ通信方法
DE102013101508A1 (de) * 2012-02-20 2013-08-22 Denso Corporation Datenkommunikationsauthentifizierungssystem für ein Fahrzeug, Netzkopplungsvorrichtung für ein Fahrzeug, Datenkommunikationssystem für ein Fahrzeug und Datenkommunikationsvorrichtung für ein Fahrzeug
JP6024564B2 (ja) * 2013-03-28 2016-11-16 株式会社オートネットワーク技術研究所 車載通信システム
JP6578224B2 (ja) * 2016-02-22 2019-09-18 ルネサスエレクトロニクス株式会社 車載システム、プログラムおよびコントローラ
CN106357681A (zh) * 2016-11-02 2017-01-25 合肥工业大学 一种车载远程诊断服务的安全接入与保密通信方法
US10756924B2 (en) * 2017-04-12 2020-08-25 Denso International America, Inc. System and method for encoding data within a vehicle communication network
JP6785720B2 (ja) * 2017-05-29 2020-11-18 日立オートモティブシステムズ株式会社 車両用制御装置及びプログラム書き換え方法
US10977875B2 (en) 2017-11-20 2021-04-13 Ford Global Technologies, Llc Systems and methods for vehicle diagnostic tester coordination
US10486626B2 (en) * 2017-11-20 2019-11-26 Ford Global Technologies, Llc Systems and methods for vehicle diagnostic tester coordination
JP7379892B2 (ja) 2018-07-25 2023-11-15 株式会社デンソー 車両用電子制御システム、車両側システム及び携帯端末
WO2020022265A1 (ja) 2018-07-25 2020-01-30 株式会社デンソー 車両用電子制御システム、プログラム更新の承諾判定方法及びプログラム更新の承諾判定プログラム
JP7354631B2 (ja) 2018-08-10 2023-10-03 株式会社デンソー 電子制御装置、車両用電子制御システム、差分データの整合性判定方法及び差分データの整合性判定プログラム
JP7047819B2 (ja) 2018-08-10 2022-04-05 株式会社デンソー 電子制御装置、車両用電子制御システム、アクティベートの実行制御方法及びアクティベートの実行制御プログラム
JP7439402B2 (ja) 2018-08-10 2024-02-28 株式会社デンソー 表示制御装置、書換え進捗状況の表示制御方法及び書換え進捗状況の表示制御プログラム
JP7354658B2 (ja) 2018-08-10 2023-10-03 株式会社デンソー 車両用電子制御システム、進捗表示の画面表示制御方法及び進捗表示の画面表示制御プログラム
JP6973450B2 (ja) 2018-08-10 2021-12-01 株式会社デンソー 車両用マスタ装置、インストールの指示判定方法及びインストールの指示判定プログラム
JP7003976B2 (ja) 2018-08-10 2022-01-21 株式会社デンソー 車両用マスタ装置、更新データの検証方法及び更新データの検証プログラム
JP7024765B2 (ja) 2018-08-10 2022-02-24 株式会社デンソー 車両用マスタ装置、更新データの配信制御方法及び更新データの配信制御プログラム
JP7111074B2 (ja) 2018-08-10 2022-08-02 株式会社デンソー 車両用マスタ装置、セキュリティアクセス鍵の管理方法、セキュリティアクセス鍵の管理プログラム及び車両用電子制御システム
JP7427879B2 (ja) 2018-08-10 2024-02-06 株式会社デンソー 車両用マスタ装置、書換え対象のグループ管理方法及び書換え対象のグループ管理プログラム
JP7115429B2 (ja) 2018-08-10 2022-08-09 株式会社デンソー 車両用マスタ装置、ロールバックの実行制御方法及びロールバックの実行制御プログラム
JP7419689B2 (ja) 2018-08-10 2024-01-23 株式会社デンソー 車両用電子制御システム、センター装置、車両用マスタ装置、表示制御情報の送信制御方法、表示制御情報の受信制御方法、表示制御情報の送信制御プログラム及び表示制御情報の受信制御プログラム
JP7400232B2 (ja) 2018-08-10 2023-12-19 株式会社デンソー 電子制御装置、リトライポイントの特定方法、リトライポイントの特定プログラム及び車両用電子制御システム
JP7346956B2 (ja) 2018-08-10 2023-09-20 株式会社デンソー 車両用プログラム書換えシステム、車両用マスタ装置、進捗状態の同期制御方法及び進捗状態の同期制御プログラム
JP7484096B2 (ja) 2018-08-10 2024-05-16 株式会社デンソー 電子制御装置、書換えの実行制御方法及び書換えの実行制御プログラム
JP7264256B2 (ja) 2019-08-28 2023-04-25 株式会社デンソー 車両用電子制御システム、車両用マスタ装置、特定モードによる書換え指示方法及び特定モードによる書換え指示プログラム
WO2021039326A1 (ja) 2019-08-28 2021-03-04 株式会社デンソー 車両用電子制御システム、車両用マスタ装置、コンフィグ情報の上書きによる書換え指示方法及びコンフィグ情報の上書きによる書換え指示プログラム
US11318878B2 (en) * 2019-10-14 2022-05-03 Infineon Technologies Ag Interfaces for cost effective video communication within advanced vehicle headlamp circuits
CN112565341A (zh) * 2020-11-13 2021-03-26 华人运通(江苏)技术有限公司 诊断路由的方法、装置、系统、设备和存储介质
JP2022154558A (ja) * 2021-03-30 2022-10-13 本田技研工業株式会社 車載電子システム、車両、制御方法、及びプログラム
CN115776526A (zh) * 2022-11-30 2023-03-10 重庆长安汽车股份有限公司 一种车载诊断报文协议转换控制方法、装置、设备及介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009271A1 (en) 2001-07-06 2003-01-09 Susumu Akiyama Vehicular relay device, in-vehicle communication system, failure diagnostic system, vehicle management device, server device and detection and diagnostic program
US20050027404A1 (en) 2003-07-16 2005-02-03 Denso Corporation In-vehicle control apparatus communicably coupled through a communication line

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7359775B2 (en) * 2001-06-13 2008-04-15 Hunter Engineering Company Method and apparatus for information transfer in vehicle service systems
JP3832347B2 (ja) * 2002-01-21 2006-10-11 株式会社デンソー 車両の盗難防止装置及びプログラム
JP4191088B2 (ja) * 2004-05-14 2008-12-03 株式会社デンソー 電子装置
JP2008265491A (ja) * 2007-04-19 2008-11-06 Fujitsu Ten Ltd 遠隔エンジン制御システム
KR100900882B1 (ko) * 2007-06-11 2009-06-04 성균관대학교산학협력단 상호 상이한 복수의 네트워크 프로토콜을 사용하는 차량에적용되는 게이트웨이 디바이스, 네트워크 시스템 및 데이터변환방법
JP2009098908A (ja) 2007-10-16 2009-05-07 Kyocera Mita Corp タイムアウト制御システム、クライアント装置、サーバ装置およびタイムアウト制御方法
EP2217995A4 (de) * 2007-10-26 2012-11-21 Telcordia Tech Inc Verfahren und system zur sicheren sitzungsherstellung unter verwendung von auf identität basierender verschlüsselung (vdtls)
JP4941500B2 (ja) * 2009-04-17 2012-05-30 株式会社デンソー ノード装置および車両ネットワークシステム
JP5484865B2 (ja) 2009-11-16 2014-05-07 パナソニック株式会社 通信システム
US9055022B2 (en) * 2011-11-16 2015-06-09 Flextronics Ap, Llc On board vehicle networking module

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030009271A1 (en) 2001-07-06 2003-01-09 Susumu Akiyama Vehicular relay device, in-vehicle communication system, failure diagnostic system, vehicle management device, server device and detection and diagnostic program
US20050027404A1 (en) 2003-07-16 2005-02-03 Denso Corporation In-vehicle control apparatus communicably coupled through a communication line

Also Published As

Publication number Publication date
US9219802B2 (en) 2015-12-22
US20130031212A1 (en) 2013-01-31

Similar Documents

Publication Publication Date Title
DE102012212962A1 (de) Gateway und fahrzeuginternes Netzwerksystem
DE112010001370B4 (de) Signalübertragungsvorrichtung für einen Aufzug
EP1516291B1 (de) Verfahren und vorrichtung für einen fahrzeugbezogenen telematikdienst
DE102015221330A1 (de) Verfahren und Vorrichtung zum robusten Aktualisieren von Firmware eines Fahrzeuges über eine Luftschnittstelle
EP2059416B1 (de) Buskommunikationsmanagement bei einem kraftfahrzeug mit mehreren, über einen bus verbundenen steuergeräten
DE112006003180T5 (de) Anlagensteuersystem
DE10329871B4 (de) Verfahren und System zur telemetrischen Diagnose elektronischer Einrichtungen eines Fahrzeugs
EP3098673A1 (de) Verfahren und vorrichtung zur automatischen validierung von sicherheitsfunktionen an einem modular aufgebauten sicherheitssystem
EP2957075B1 (de) Master-busgerät für einen fahrzeugkommunikationsbus eines kraftwagens
EP1199846A1 (de) Verfahren zur automatischen Gerätekonfiguration in einem Feldbus-System
DE112012006248B4 (de) Datenverarbeitungsvorrichtung und Programm
WO2003016856A2 (de) Kommunikationsverfahren und kommunikationsmodul
DE102012017386B4 (de) Verfahren zum Überwachen einer mit einem Kommunikationskanal verbundenen Vorrichtung
DE102021104422A1 (de) Verfahren zum Betreiben eines Kommunikationssystems, Kommunikationssystem und Rechensystem
EP3470939B1 (de) Verfahren und system zum überwachen der sicherheitsintegrität einer durch ein sicherheitssystem bereitgestellten sicherheitsfunktion
DE102005033874A1 (de) Verfahren zur Überwachung des Schlafmodus eines Bussystems in einem Kraftfahrzeug
EP3470937B1 (de) Verfahren und vorrichtungen zum überwachen der reaktionszeit einer durch ein sicherheitssystem bereitgestellten sicherheitsfunktion
DE112019007853T5 (de) Steuereinrichtung
DE102019111623A1 (de) Lenksteuerapparat und lenksteuerverfahren und lenksystem
DE102017109703B3 (de) Verfahren zur Koordination des Zugriffs auf eine Ressource eines verteilten Computersystems, Computersystem und Computerprogramm
EP4096198A1 (de) Verfahren zur diagnose eines bordnetzes eines fahrzeugs
EP1384122B1 (de) Verfahren zur ansteuerung einer komponente eines verteilten sicherheitsrelevanten systems
EP3647794B1 (de) Verfahren zum steuern einer kommunikation zwischen einer aufzeichnungseinheit und einem geschwindigkeitsgeber eines tachographensystems eines kraftfahrzeugs sowie korrespondierendes tachographensystem und aufzeichnungseinheit für das tachographensystem
EP2090948A1 (de) Automatisierungssystem und Verfahren zum Betrieb eines solchen Automatisierungssystems
EP1917595A2 (de) Verfahren zur systemdiagnose in technischen systemen

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R084 Declaration of willingness to licence
R119 Application deemed withdrawn, or ip right lapsed, due to non-payment of renewal fee