WO2004047385A2 - Gateway-einheit zur verbindung von subnetzen in fahrzeugen - Google Patents

Gateway-einheit zur verbindung von subnetzen in fahrzeugen Download PDF

Info

Publication number
WO2004047385A2
WO2004047385A2 PCT/DE2003/003848 DE0303848W WO2004047385A2 WO 2004047385 A2 WO2004047385 A2 WO 2004047385A2 DE 0303848 W DE0303848 W DE 0303848W WO 2004047385 A2 WO2004047385 A2 WO 2004047385A2
Authority
WO
WIPO (PCT)
Prior art keywords
gateway
software
bus
gateways
gateway unit
Prior art date
Application number
PCT/DE2003/003848
Other languages
English (en)
French (fr)
Other versions
WO2004047385A3 (de
Inventor
Doerte Eimers-Klose
Cornelia Heinisch
Joerg Fischer
Timo Gramann
Original Assignee
Robert Bosch Gmbh
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 Robert Bosch Gmbh filed Critical Robert Bosch Gmbh
Priority to EP03788797A priority Critical patent/EP1566029B1/de
Priority to US10/535,486 priority patent/US7802016B2/en
Priority to JP2004552418A priority patent/JP2006506862A/ja
Priority to DE50308326T priority patent/DE50308326D1/de
Publication of WO2004047385A2 publication Critical patent/WO2004047385A2/de
Publication of WO2004047385A3 publication Critical patent/WO2004047385A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
    • H04L12/462—LAN interconnection over a bridge based backbone
    • H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • H04L47/2433—Allocation of priorities to traffic types
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W2050/0001—Details of the control system
    • B60W2050/0043—Signal treatments, identification of variables or parameters, parameter estimation or state estimation
    • B60W2050/0044—In digital systems
    • B60W2050/0045—In digital systems using databus protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/407—Bus networks with decentralised control
    • H04L12/413—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD]
    • H04L12/4135—Bus networks with decentralised control with random access, e.g. carrier-sense multiple-access with collision detection [CSMA-CD] using bit-wise arbitration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40208—Bus networks characterized by the use of a particular bus standard
    • H04L2012/40215—Controller Area Network CAN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L2012/40267—Bus for use in transportation systems
    • H04L2012/40273—Bus for use in transportation systems the transportation system being a vehicle
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/08—Protocols for interworking; Protocol conversion

Definitions

  • Gateway unit for connecting subnets, especially in vehicles
  • the invention relates to a gateway unit for connecting subnets, in particular in vehicles.
  • gateway unit that connects two bus segments with one another has the task of forwarding messages that are received on one bus segment to another bus segment (routing).
  • routing The complexity of such a gateway unit increases with the number of bus segments to be coupled.
  • the modular design of a gateway unit in which a gateway designed in software (logical software gateway) is responsible for routing messages between exactly two subnets, enables gateways to be expanded without changing the existing software of the gateway and / or in the existing configuration tables. By adding or leaving out such a modular gateway when changing the network topology, such change measures are avoided. Accordingly, it is possible to remove a bus segment from a central gateway unit without influencing existing coupling paths.
  • a gateway designed in software logical software gateway
  • the concept outlined above can be flexibly expanded and adapts to the network coupling architecture. If an additional subnet is added to a central gateway, only the additional modular gateways need to be added. The existing modular gateways are not affected. If a subnet is removed, the gateways that link to this subnet are removed, the rest remain unchanged.
  • a message is routed as quickly as possible. This avoids unnecessary overhead for routing a message. Since a logical gateway is responsible for the coupling of two subnets, the flow of information can be controlled separately if the Data transfer takes place between a subnet with safety-critical functions and a subnet with non-safety-critical functions. Thus, an optimal control possibility for a firewall functionality is provided. This can control each coupling path individually.
  • a logical gateway that routes messages via an air interface can implement stricter security mechanisms to ward off external threats than a logical software gateway that routes messages between two CAN subnets in the vehicle and is not directly exposed to any external threats.
  • the complexity of the entire gateway unit is reduced, since the individual logical gateways are not linked to one another at all. It doesn't matter whether three logical gateways run on a central gateway or on three separate point-to-point gateways.
  • Gateways according to which routing tables are provided in each gateway, via which the routing of the messages is handled and which are independent of the software of the gateway.
  • This table-based approach makes it possible to use a tool to configure the gateway software.
  • This approach also advantageously leads to the possibility of prioritizing the messages, so that certain messages that are to be routed preferentially can be assigned a higher priority than other messages.
  • a scheduler is advantageously provided which, despite the division into several modular software gateways, ensures that the sequence of the
  • Message routing is adhered to. In this way, a message that first arrived at the gateway can also leave the gateway first.
  • Figure 1 shows the basic principle of the described architecture of a gateway unit, which connects three bus segments with each other.
  • FIG. 2 shows a preferred embodiment of such a gateway
  • Messages are communicated between a low-speed CAN, a high-speed CAN and an SPI bus.
  • Figure 3 shows a central gateway unit for coupling between four subnets, while in
  • FIG. 5 shows a gateway integrated in a control unit using a
  • gateway unit 10 to which three bus segments 1, 2, 3 are coupled and which has the task of connecting (routing) messages from one bus segment to one of the other or to both other bus segments.
  • the basic principle of the architecture shown are the modular gateways (logical software gateways) 12, 13, 23, such a gateway being responsible for the routing of messages between exactly two subnets.
  • the gateway routes 12 messages from 1 to 2 and vice versa, the gateway 13 messages from 1 to 3 and vice versa, the gateway 23 messages from 2 to 3 and vice versa.
  • Each logical software gateway therefore describes an individual coupling path between two subnets or bus segments.
  • the gateways 12, 13, 23 are designed as software programs, with the aid of which the protocol-specific adaptations that are necessary for a message
  • each subnet is an individual transmission medium.
  • Subnet 1 can be, for example, a low-speed CAN, subnet 2 a high-speed CAN and subnet 3 a SPI bus.
  • a new subnet is added, for example a MOST bus, additional logical software gateways are integrated. The existing do not have to be changed.
  • a subnet is removed, for example the SPI bus, the logical software gateways 13 and 23 are removed.
  • logical software gateways In order to have a universal gateway function, logical software gateways must be written for all coupling options. Depending on the design of the gateway to be implemented, these are then combined to form the overall system.
  • N corresponds to the number of subnets in the overall system. This results in 3 logical software gateways for three subnets, 6 for four subnets and 10 for five subnets. Whether these logical software gateways are located in a central gateway or in several distributed point-to-point gateways plays a subordinate role.
  • FIG. 2 shows a more detailed embodiment of the basic features of the modular
  • the gateway 10 which is preferably implemented as a program in a microcontroller of a control unit, comprises, in addition to the modular software gateways shown (: CANCAN,: CANSPI), bus-specific transmission units which control access to the bus medium.
  • Each bus segment is assigned receive objects (: Rx-CAN,: Rx-SPI), which make the decision as to which logical software gateway an incoming message is routed to.
  • Rx-CAN receive objects
  • Rx-SPI receive objects
  • TxCAN bus-specific transmission objects
  • the software gateways (in Figure 2: CANCAN: CANSPI) are composed internally of several software objects, which buffer incoming messages and make the protocol-specific adjustments.
  • a simple adaptation is, for example, that a CAN message must be sent from the high-speed CAN with ID 100 to the low-speed CAN with ID 200.
  • These protocol-specific adjustments are then made by appropriate programs (for example, in the simplest case using a table).
  • Configuration tables are used for the protocol-specific adjustments that are carried out within the logical software gateways.
  • the bus-specific receive objects are configured using so-called routing tables, with the aid of which it is decided whether an incoming message is passed on to none, to one or to both logical software gateways.
  • the further processing of the message is thus stored in the routing table for each incoming message type. Furthermore, due to the different speed of the buses, it can happen that from one to the other bus segment only every fifth message of a certain type (eg engine speed) is forwarded. This can also be implemented in the receive object using the routing tables mentioned. These routing tables are independent of the source code of the actual gateway, so that changing the routing tables does not result in changes in the software of the affected modular gateway, or only insignificant changes.
  • the bus-specific receiving unit searches for the message found in the routing table and, based on the information contained therein, decides which logical software gateway receives the message for further processing.
  • bus-specific transmission units or the programs provided there control access to the bus. If the bus is currently busy, make sure that no logical software gateway is sending.
  • the logical software gateways buffer the messages to prevent message loss, e.g. when the bus segment to be sent is currently busy. A message is therefore put on hold before it is forwarded directly.
  • the storage of a message in this queue is noted in the internal scheduler of the gateway unit. This then causes the message to be sent by sending a message to the corresponding modular logical software gateway. This then causes the message to be sent. So if a logical software gateway wants to send a message, it has to register this transmission request with the scheduler. It depends on the order of registration which software gateway is the first to be authorized to send one
  • the scheduler provides several methods which can be called by the logical software gateways to register a send request. The scheduler then always processes the high-priority requests first and then the normal and issued Priority-dependent send authorizations to the logical software gateways. For example, each send request is provided with a date representing the priority of the message or the scheduler comprises a table in which the priorities of the messages are noted, from which the scheduler reads the priority.
  • the gateway can be reprogrammed for another message routing by changing the parameter sets in the memory. If the same interfaces are used, the gateway software can only be used
  • Configure parameter sets When connecting other interfaces to the gateway, a modular software module must be integrated into the gateway. Different gateway configurations are thus generated by merging software modules, for example from libraries and from providing the routing information.
  • Matrix is essentially limited to entering the new routing information in the routing table. In this way, CAN-CAN gateways of different baud rates can be fitted into a system in the shortest possible time. The testability and verification of the resulting code are simplified because the configuration-independent code is tested centrally and, in addition to the system test, only an integration test for the new logical SW gateway or the new configuration has to be carried out.
  • FIG. 3 shows a gateway 10 for coupling 4 different bus segments, a low-speed CAN, a high-speed CAN, an SPI bus and a MOST bus.
  • the architecture described above is also used here, whereby logical software gateways OCAN-MOST,: CAN-SPI,: CAN-CAN,: SPI-MOST) are used, each of which realizes an individual coupling path.
  • bus-specific receiver modules (: Rx-Most,: Rx-CAN,: Rx-SPI) and transmitter modules (: Tx-Most,: Tx-CAN,: Tx-SPI) are shown as described above.
  • the architecture shown shows a central gateway unit that connects the four bus segments mentioned.
  • FIG. 1 shows a central gateway unit that connects the four bus segments mentioned.
  • FIG. 4 shows another network topology which has six point-to-point gateway units 10a, 10b, 10c, 10d, 10e and 10f.
  • Each of these point-to-point gateways contains the logical software gateway structure shown above with transmitter and receiver elements for bus-specific connection. It shows that the physical network architecture between the two extremes of central gateway and point-to-point gateway can contain all conceivable mixed forms.
  • the software architecture is independent of the physical network architecture, so that it allows coupling in all conceivable architectures. It can be different that the central
  • Gateway variant the software on a microcontroller, in the decentralized variant it runs on different controllers.
  • the routing decision is configured using routing tables.
  • the bus-specific receive objects decide which logical software gateways a message should be forwarded to. These receive objects are therefore configured with routing tables, which specify which messages are to be forwarded to which subnet and, if necessary, under which boundary conditions (e.g. every 5th, etc.).
  • the software of the software gateways then realizes the bus-specific adaptations and is independent of the actual routing process.
  • the software gateways are then configured by adapting the protocol parameters.
  • the logical gateways are configured using tables that specify how the protocol parameters are to be implemented. Here you can configure that a message with the identification code 100 is sent on the other network segment
  • the routing tables with which the bus-specific reception objects are configured must be divided or merged. This task is performed by an internal scheduler, which coordinates the logical software gateways in a central gateway unit. The scheduler must be generated individually for the different gateway variants.
  • the gateway is not a standalone gateway, but a gateway that is integrated into a control unit with additional application functions.
  • the gateway software can also take over the functionality of a normal communication deck. This means that it must also be possible to forward messages to the actual applications and to receive messages for sending them.
  • additional objects are required, which have the ability have to remove or add the layer-specific protocol parameters in order to pass the message on to the next higher or lower layer. These additional objects are usually part of the software of the normal communication network.
  • FIG. 5 shows the layer model of a control device 100, in which a CAN-CAN gateway is integrated. A distinction is made between application system I and communication system II.
  • a driver 102 for the low-speed CAN and a driver 104 for the high-speed CAN being provided in a first layer.
  • additional objects were inserted in the network layer 3 (CAN layer 3), which communicate with the applications A, B and C via the receive and transmit objects Rx3 and Tx3. If necessary, these additional objects buffer the messages and add or remove protocol-specific parameters.
  • the logical software gateway integrated in this layer (CAN-CAN) routes messages from one bus to another.
  • the receive and transmit objects Rx2 and Tx2 become the same as above
  • Described used for routing messages between the two CAN buses represent the interfaces between the layers.
  • a transport protocol e.g. ISO TP
  • a CAN-CAN gateway can be provided in layer 3, which can transport CAN messages (eg speed information or tank level) in layer 3, while another CAN-CAN gateway links transport information in layer 4, which, for example, text for display in
  • a coupling in higher layers may also be necessary in order to be able to check the content of a message that is to be forwarded. The content can only be analyzed when the complete message has been received.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Es wird eine Gateway-Einheit zur Verbindung von Subsystemen, insbesondere in Fahrzeugen vorgeschlagen, bei welchem wenigstens ein modulares logisches Software-Gateway eingesetzt wird, welches Nachrichten zwischen genau zwei Subnetzen routet und auf diese Weise nur einen individuellen Kopplungspfad bereitstellt.

Description

Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen
Stand der Technik
Die Erfindung betrifft eine Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen.
Um neue Dienste im Fahrzeug zu ermöglichen ist eine Kommunikation der Steuereinheiten, die sich in unterschiedlichen Bussegmenten befinden, zwingend erforderlich. Eine solche Kommunikation kann nur stattfinden, wenn die unterschiedlichen Bussegmente über eine Gateway-Einheit bzw. Gateway-Einheiten miteinander verbunden sind. Eine Gateway-Einheit, die zwei Bussegmente miteinander verbindet, hat dabei die Aufgabe, Nachrichten, die auf einem Bussegment empfangen werden, auf ein anderes Bussegment weiterzuleiten (Routing). Die Komplexität einer solchen Gateway-Einheit steigt mit der Anzahl der zu koppelnden Bussegmente. Bei der Auslegung der Netzkoppelarchitektur eines Fahrzeugs wird versucht, ein Optimum für die Eigenschaften der tolerierbaren Verzögerung für das Nachrichten-Routing, der Fehlertoleranz, der Flexibilität, der Erweiterbarkeit und der Kosten zu finden. Je nach Anwendung werden zentrale Gateway-Einheiten mit einer Sternarchitektur oder mehrere Gateway-Einheiten, die z.B. mit einem Backbone-Bus verbunden sein können, eingesetzt. Die Gateway-Einheiten, über die unterschiedliche Busse gekoppelt sind, sind konfiguriert
(z.B. über Tabellen). Das heißt für das reine Nachrichten-Routing auf ein anderes Segment ist somit keine Abänderung der Software erforderlich. Sobald sich aber die Art und die Anzahl der gekoppelten Bussegmente ändern, ist ein erheblicher Änderungsaufwand erforderlich, bei dem nicht nur die bestehenden Konfigurationstabellen angepasst werden müssen, sondern die komplette Software umgeschrieben werden muss, um den neuen Anforderungen gerecht zu werden. Die Komplexität der zentralen Konfiguration und der Routing-Software steigt also mit der Anzahl der gekoppelten Bussegmente enorm an.
Vorteile der Erfindung ö
Durch den modularen Aufbau einer Gateway-Einheit, bei welcher ein in Software ausgebildetes Gateway (logisches Software-Gateway) für das Routing von Nachrichten zwischen genau zwei Subnetzen zuständig ist, wird es ermöglicht, Gateways zu erweitern, ohne dass eine Änderung in der vorhandenen Software des Gateways und/oder in den vorhandenen Konfigurationstabellen erforderlich ist. Durch das Hinzufügen oder Weglassen eines solchen modularen Gateways bei Änderung der Netztopologie werden solche Änderungsmaßnahmen vermieden. Entsprechend ist es möglich, bei einer zentralen Gateway-Einheit ein Bussegment zu entfernen ohne bestehende Kopplungspfade zu beeinflussen.
Ferner wird durch die oben genannten modularen Gateways eine Fehlerbegrenzung erreicht, da bei nicht funktionsfähigem Gateway die anderen Gateways unabhängig davon weiterhin ihre Aufgabe erfüllen. Ein Fehler wird also auf das unmittelbar betroffene Gateway begrenzt, die Kopplung zu anderen Bussegmenten ist nicht berührt.
Kommt es auf einem Bussegment zu einem Fehler, so werden die Nachrichten über die anderen Bussegmente ohne Einschränkung weiter geroutet.
Ferner ist das oben skizzierte Konzept flexibel erweiterbar und passt sich der Netzkoppelarchitektur an. Wird ein zusätzliches Subnetz einem zentralen Gateway hinzugefügt, so müssen lediglich die zusätzlichen modularen Gateways hinzugefügt werden. Die bestehenden modularen Gateways sind davon nicht betroffen. Wird ein Subnetz entfernt, werden die Gateways, die auf dieses Subnetz koppeln, entfernt, die restlichen bleiben unverändert bestehen.
Da ferner in einem logischen Gateway immer nur die Funktion enthalten ist, die für das Koppeln der zwei unterschiedlichen Subnetze erforderlich ist, wird eine Nachricht schnellst möglich geroutet. Unnötiger Overhead für das Routing einer Nachricht wird so vermieden. Da ein logisches Gateway genau für die Kopplung von zwei Subnetzen zuständig ist, kann ferner der Informationsfluss gesondert kontrolliert werden, wenn der Datentransfer zwischen einem Subnetz mit sicherheitskritischen Funktionen und einem Subnetz mit nicht sicherheitskritischen Funktionen stattfindet. Es wird somit also eine optimale KontroUmöglichkeit für eine Firewall-Funktionalität bereitgestellt. Diese kann jeden Kopplungspfad individuell kontrollieren. So kann ein logisches Gateway, das Nachrichten über eine Luftschnittstelle routet, zur Abwehr von externen Bedrohungen striktere Sicherheitsmechanismen implementieren als ein logisches Software-Gateway, das Nachrichten zwischen zwei CAN-Subnetzen im Fahrzeug routet und direkt keiner externen Bedrohung ausgesetzt ist.
Ferner ermöglicht die dargestellte Architektur ein individuelles Aktiv- und/oder
Inaktivschalten eines einzelnen oder mehrerer Gateways, so dass auf dies Weise abhängig von Systemzuständen ein oder mehrere Gateways ein- bzw. ausgeschaltet werden können.
Ferner erfolgt eine Reduzierung der Komplexität der gesamten Gateway-Einheit, da die einzelnen logischen Gateways untereinander überhaupt nicht miteinander verknüpft sind. Es spielt keine Rolle, ob z.B. drei logische Gateways auf einem zentralen Gateway oder auf drei getrennten Punkt-zu-Punkt-Gateways ablaufen.
Weitere Vorteile ergeben sich aus einer konkreten Ausgestaltung der logischen
Gateways, nach der in jedem Gateway Routingtabellen vorgesehen sind, über die das Routing der Nachrichten abgewickelt wird und die unabhängig von der Software des Gateways sind. Durch diesen tabellenbasierten Ansatz wird es ermöglicht, ein Tool zur Konfiguration der Gateway-Software einzusetzen. Dieser Ansatz führt auch in vorteilhafter Weise zu einer Priorisierungsmöglichkeit der Nachrichten, so dass bestimmte Nachrichten, die bevorzugt geroutet werden sollen, eine höhere Priorität zugeordnet werden kann als anderen Nachrichten.
Ferner ist in vorteilhafter Weise ein Scheduler vorgesehen, der trotz der Aufteilung in mehrere modulare Software-Gateways gewährleistet, dass die Reihenfolge des
Nachrichten-Routings eingehalten wird. Auf diese Weise kann eine Nachricht, die zuerst im Gateway angekommen ist, das Gateway auch zuerst wieder verlassen.
Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von Ausführungsbeispielen bzw. aus den abhängigen Patentansprüchen. Zeichnung
Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert.
Figur 1 zeigt das Grundprinzip der beschriebenen Architektur einer Gateway-Einheit, welche drei Bussegmente miteinander verbindet.
Figur 2 zeigt ein bevorzugtes Ausführungsbeispiel eines solchen Gateways, welches
Nachrichten zwischen einem Lowspeed-CAN, einem Highspeed-CAN und einem SPI- Bus vermittelt.
Figur 3 zeigt eine zentrale Gateway-Einheit zur Kopplung zwischen vier Subnetzen, während in
Figur 4 Punkt-zu-Punkt-Gateway-Einheiteπ zur Kopplung der vier Subnetze mit Hilfe der beschriebenen Gateway-Architektur dargestellt sind. Figur 5 schließlich zeigt ein in eine Steuereinheit integriertes Gateway anhand eines
Schichtenmodells.
Beschreibung von Ausführungsbeispielen
In Figur 1 ist eine Gateway-Einheit 10 dargestellt, an die drei Bussegmente 1, 2, 3 angekoppelt sind und die die Aufgabe hat, Nachrichten von einem Bussegment auf eines der anderen oder beide andere Bussegmente zu verbinden (routen). Grundprinzip der dargestellten Architektur sind die modularenb Gateways (logischen Software-Gateways) 12, 13, 23, wobei ein solches Gateway für das Routing von Nachrichten zwischen genau zwei Subnetzen zuständig ist. Somit routet das Gateway 12 Nachrichten von 1 nach 2 und umgekehrt, das Gateway 13 Nachrichten von 1 nach 3 und umgekehrt, das Gateway 23 Nachrichten von 2 nach 3 und umgekehrt. Jedes logische Software-Gateway beschreibt daher einen individuellen Koppelpfad zwischen zwei Subnetzen bzw. Bussegmenten. Die Gateways 12, 13, 23 sind dabei als Software-Programme ausgestaltet, mit deren Hilfe die protokollspezifischen Anpassungen vorgenommen werden, die für ein Nachrichten-
Routing zwischen den beiden Subnetzen erforderlich sind. Je nach Ausführungsbeispiel handelt es sich bei jedem Subnetz um ein individuelles Übertragungsmedium. Subnetz 1 kann z.B. ein Lowspeed-CAN, Subnetz 2 ein Highspeed-CAN und Subnetz 3 ein SPI-Bus sein. Kommt ein neues Subnetz hinzu, beispielsweise ein MOST-Bus, so werden zusätzliche logische Software-Gateways integriert. Die Bestehenden müssen nicht geändert werden. Wird ein Subnetz entfernt, beispielsweise der SPI-Bus, so werden die logischen Software-Gateways 13 und 23 entfernt. Um eine universelle Gateway-Funktion zu haben, sind logische Software-Gateways für alle Kopplungsmöglichkeiten zu schreiben. Diese werden dann je nach Auslegung des zu realisierenden Gateways zum Gesamtsystem kombiniert. Im Regelfall wird es so sein, dass nicht alle Subnetze direkt miteinander gekoppelt sind, so dass nur ausgewählte Kopplungspfade mit ausgewählten logischen Software-Gateways zu versehen sind. Soll jedes Subnetz mit jedem anderen gekoppelt werden, so benötigt man N*(N-l)/2 logische Software-Gateways. Die Variable N entspricht dabei der Anzahl der im Gesamtsystem vorhandenen Subnetze. Für drei Subnetze ergeben sich damit 3 logische Software-Gateways, für vier Subnetze 6 und für fünf Subnetze 10. Ob sich diese logischen Software-Gateways in einem zentralen Gateway befinden oder in mehreren verteilten Punkt-zu-Punkt-Gateways spielt eine untergeordnete Rolle.
Figur 2 zeigt ein detaillierteres Ausführungsbeispiel der Grundzüge der modularen
Gateway- Architektur gemäß Figur 1. Das Gateway 10, welches vorzugsweise als Programm in einem Mikrocontroller einer Steuereinheit realisiert ist, umfasst neben den dargestellten modularen Software-Gateways (:CANCAN, :CANSPI) busspezifische Sendeeinheiten, die den Zugriff auf das Busmedium kontrollieren. Jedem Bussegment sind Empfangsobjekte zugeordnet (:Rx-CAN, :Rx-SPI), welche die Entscheidung treffen, in welches logische Software-Gateway eine ankommende Nachricht geroutet wird. Entsprechend gibt es für den Sendevorgang busspezifische Sendeobjekte (:TxCAN, :TxSPI) , die den Zugriff auf den jeweiligen Bus kontrollieren und verhindern, dass mehrere modulare Software-Gateways das Sendemedium gleichzeitig belegen.
Die Software-Gateways (in Figur 2: CANCAN :CANSPI) setzen sich intern aus mehreren Software-Objekten zusammen, die ankommende Nachrichten zwischenpuffern und die protokollspezifischen Anpassungen vornehmen. Eine einfache Anpassung ist z.B., dass eine CAN-Nachricht vom Highspeed-CAN mit der ID 100 auf den Lowspeed-CAN mit der ID 200 gesendet werden muss. Diese protokollspezifischen Anpassungen werden dann durch entsprechende Programme (z.B. im einfachsten Fall durch eine Tabelle) vorgenommen. Für die protokollspezifischen Anpassungen, die innerhalb der logischen Software-Gateways durchgeführt werden, kommen Konfigurationstabellen zum Einsatz. In einer bevorzugten Ausführung werden die busspezifischen Empfangsobjekte über sogenannte Routingtabellen konfiguriert, mit deren Hilfe entschieden wird, ob eine ankommende Nachricht an kein, an ein oder an beide logischen Software-Gateways weitergegeben wird. In der Routing-Tabelle werden somit für jeden ankommenden Nachrichtentyp die Weiterbehandlung der Nachricht abgelegt. Ferner kann durch unterschiedliche Schnelligkeit der Busse es vorkommen, dass von einem zum anderen Bussegment nur jede 5. Nachricht eines bestimmten Typs (z.B. Motordrehzahl) weitergeleitet wird. Auch dies kann mittels der genannten Routingtabellen im Empfangsobjekt realisiert sein. Diese Routingtabellen sind dabei unabhängig vom Source-Code des eigentlichen Gateways, so dass eine Veränderung der Routingtabellen nicht oder nur unwesentliche Änderungen der Software des betrofffenen modularen Gateways nach sich zieht. Die busspezifische Empfangseinheit sucht die gefundene Nachricht in der Routing-Tabelle auf und entscheidet aufgrund der darin enthaltenen Informationen, welches logische Software-Gateway die Nachricht zur Weiterverarbeitung erhält.
Die busspezifischen Sendeeinheiten, bzw. die dort vorgesehenen Programme, kontrollieren den Zugriff auf den Bus. Ist der Bus gerade belegt, so stellen sie sicher, dass von keinem logischen Software-Gateway gesendet wird.
Zusätzlich puffern wie oben erwähnt die logischen Software-Gateways die Nachrichten zwischen, um einen Nachrichtenverlust zu verhindern, z.B. dann, wenn das Bussegment auf dem gesendet werden soll, gerade belegt ist. Eine Nachricht wird also vor ihrer direkten Weiterleitung in einer Warteschleife abgelegt. Das Ablegen einer Nachricht in dieser Warteschleife wird beim internen Scheduler der Gateway-Einheit vermerkt. Dieser veranlasst dann das Senden der Nachricht, indem er eine Nachricht an das entsprechende modulare logische Software-Gateway sendet. Dieses veranlasst dann das Versenden der Nachricht. Will also ein logisches Software-Gateway eine Nachricht senden, so muss es diesen Sendewunsch beim Scheduler anmelden. Von der Reihenfolge der Anmeldung ist es abhängig, welches Software-Gateway zuerst die Berechtigung für das Senden einer
Nachricht erhält. Dieses Konzept stellt die Einhaltung der Reihenfolge der Nachrichten sicher. Gibt es besondere hochpriorisierte Nachrichten im System, so stellt der Scheduler mehrere Methoden bereit, welche von den logischen Software-Gateways aufgerufen werden können, um einen Sendewunsch anzumelden. Der Scheduler arbeitet dann immer zuerst die hochpriorisierten Anforderungen ab und dann die normalen und erteilt prioritätenabhängig Sendeberechtungen an die logischen Software-Gateways. Beipsielsweise ist jede Sendewunsch mit einem die Priorität der Nachricht repräsentierenden Datum versehen oder der Scheduler umfasst eine Tabelle, in der die Prioritäten der Nachrichten vermerkt ist, aus der der Scheduler die Priorität ausliest.
Durch die oben dargestellte Architektur und Vorgehensweise ist man in der Lage, die Gateway-Einheit über Tabellen zu konfigurieren, ohne deren Software selbst abzuändern. Beispielsweise kann über eine Abänderung der Parametersätze im Speicher das Gateway für ein anderes Nachrichten-Routing umprogrammiert werden. Werden die gleichen Schnittstellen verwendet, so lässt sich die Gateway-Software ausschließlich über
Parametersätze konfigurieren. Bei dem Anschluss anderer Schnittstellen an das Gateway, ist ein modularer Software-Baustein in das Gateway zu integrieren. Somit werden unterschiedliche Gateway-Konfigurationen durch das Zusammenführen von Software- Modulen beispielsweise aus Bibliotheken und aus dem Bereitstellen der Routing- Information generiert. Die Neuintegration einer CAN-Schnittstelle mit neuer CAN-
Matrix beschränkt sich im wesentlichen auf das Eingeben der neuen Routing-Information in die Routing-Tabelle. So können CAN-CAN-Gateways unterschiedlicher Baudraten in kürzester Zeit in ein System eingepasst werden. Die Testbarkeit und Verifizierung des entstehenden Codes werden dadurch vereinfacht, weil der konfigurationsunabhängige Code zentral getestet wird und neben dem Systemtest ausschliesslich ein Integrationstest für das neue logische SW-Gateway bzw. die neue Konfiguration durchgeführt werden muß.
Figur 3 zeigt ein Gateway 10 zur Kopplung 4 unterschiedlicher Bussegmente, einen Lowspeed-CAN, einen Highspeed-CAN, ein SPI-Bus und einen MOST-Bus. Die vorstehend beschriebene Architektur ist auch hier eingesetzt, wobei logische Software- Gateways OCAN-MOST, :CAN-SPI, :CAN-CAN, :SPI-MOST) eingesetzt werden, die jeweils einen individuellen Kopplungspfad realisieren. Daneben sind busspezifisch Empfängermodule (:Rx-Most, :Rx-CAN, :Rx-SPI) und Sendemodule (:Tx-Most, :Tx- CAN, :Tx-SPI) wie vorstehend beschrieben darstellt. Die dargestellte Architektur zeigt eine zentrale Gateway-Einheit, welche die genannten vier Bussegmente miteinander verbindet. In Figur 4 ist eine andere Netzwerktopologie dargestellt, welche sechs Punkt- zu-Punkt-Gateway-Einheiten 10a, 10b, 10c, lOd, l Oe und lOf aufweist. Jedes dieser Punkt-zu-Punkt-Gateways enthält die oben dargestellte logische Software-Gateway- Struktur mit Sende- und Empfängerelementen zur busspezifischen Anbindung. Es zeigt sich, dass durch die oben dargestellte Architektur die physikalische Netzkoppelarchitektur zwischen den beiden Extremen zentrales Gateway und Punkt-zuPunkt-Gateway alle denkbaren Mischformen enthalten kann. Die Software-Architektur ist unabhängig von der physikalischen Netzkoppelarchitektur, so dass sie die Kopplung in allen denkbaren Architekturen erlaubt. Unterschiedlich kann sein, dass bei der zentralen
Gateway- Variante die Software auf einem Mikrocontroller, in der dezentralen Variante auf unterschiedlichen Controllern abläuft.
Zur Konfiguration der Gateway-Einheit ergeben sich verschiedene Möglichkeiten. Die Konfiguration der Routing-Entscheidung erfolgt über Routing-Tabellen. In diesem Fall entscheiden die busspezifischen Empfangsobjekte, in welche logischen Software- Gateways eine Nachricht weiterzuleiten ist. Diese Empfangsobjekte werden deshalb mit Routing-Tabellen konfiguriert, welche angeben, welche Nachrichten in welches Subnetz und ggf. unter welchen Randbedingungen (z.B. jede 5., etc.) weiterzuleiten sind. Die Software der Software-Gateways realisiert dann die busspezifischen Anpassungen und ist von dem eigentlichen Routing- Vorgang unabhängig. Die Konfiguration der Software- Gateways erfolgt dann durch Anpassung von Protokollparametern. In diesem Fall werden die logischen Gateways über Tabellen konfiguriert, die angeben, wie die Protokoll- Parameter umzusetzen sind. Hier kann konfiguriert werden, dass eine Nachricht mit dem Identifikationscode 100 bei dem Versenden auf dem anderen Netzsegment die
Identifikationsnummer 200 tragen muss. Ferner sind, um die Gateway-Software an die unterschiedlichen Netzkoppelarchitekturen anzupassen, die Routing-Tabellen, mit denen die busspezifischen Empfangsobjekte konfiguriert werden, aufzuteilen bzw. zusammenzuführen. Diese Aufgabe wird durch einen internen Scheduler erledigt, welcher die logischen Software-Gateways in einer zentralen Gateway-Einheit untereinander koordiniert. Der Scheduler muss für die verschiedenen Gateway-Varianten individuell generiert werden.
In einer anderen Ausführungsform, die in Figur 5 dargestellt ist, handelt es sich bei dem Gateway um kein Standalone-Gateway, sondern um ein Gateway, das in ein Steuergerät mit zusätzlichen Anwendungsfunktionen integriert wird. Dort kann die Gateway- Software auch die Funktionalität eines normalen Kommunikationsdecks übernehmen. Das heißt, es muss hier auch möglich sein, Nachrichten zu den eigentlichen Anwendungen weiterzuleiten und Nachrichten zum Versenden von diesen entgegenzunehmen. Hierzu werden weitere Objekte benötigt, welche die Fähigkeit besitzen, die schichtspezifischen Protokollparameter zu entfernen bzw. hinzuzufügen, um die Nachricht in die nächsthöhere bzw. nächstniedrigere Schicht weiterzureichen. Diese zusätzlichen Objekte sind in der Regel Bestandteil der Software des normalen Kommunikationsnetz. Figur 5 zeigt das Schichtenmodell eines Steuergeräts 100, in welchem ein CAN-CAN-Gateway integriert ist. Dabei wird das Anwendungssystem I und das Kommunikationssystem II unterschieden. Es sind drei Schichten 1, 2, 3 abgebildet, wobei in einer ersten Schicht ein Treiber 102 für den Lowspeed-CAN und ein Treiber 104 für den Highspeed-CAN vorgesehen sind. Ferner wurden in der Vermittlungsschicht 3 zusätzliche Objekte eingefügt (CAN-Schicht 3), die über die Empfangs- und Sendeobjekte Rx3 und Tx3 mit den Anwendungen A, B und C kommunizieren. Diese zusätzlichen Objekte führen, falls erforderlich, eine Zwischenpufferung der Nachrichten durch und fügen protokollspezifische Parameter hinzu oder entfernen diese. Das logische Software-Gateway, das in diese Schicht integriert ist (CAN-CAN) routet Nachrichten vom einen Bus zum anderen. Die Empfangs- und Sendeobjekte Rx2 und Tx2 werden entsprechend dem vorstehend
Beschriebenen für das Routing von Nachrichten zwischen den beiden CAN-Bussen verwendet. Sie stellen die Schnittstellen zwischen den Schichten dar. In einer weiteren Ausführung ist durch entsprechende Erweiterung es möglich, zwei Subnetze auf unterschiedlichen Schichten zu koppeln. Dies ist beispielsweise dann erforderlich, wenn ein Transport-Protokoll (z.B. ISO TP) zum Einsatz kommt. In diesem Fall existiert dann pro Schicht, in der eine Kopplung stattfindet, ein logisches Software-Gateway. So kann beispielsweise ein CAN-CAN-Gateway in der Schicht 3 vorgesehen sein, welches CAN- Nachrichten (z.B. Geschwindigkeitsinformation oder Tankfüllstand) in der Schicht 3 transportieren während ein weitere CAN-CAN-Gateway in einer Schicht 4 Transportinformationen koppelt, welche beispielsweise einen Text für die Anzeige im
Fahrzeugcomputer enthält. Eine Kopplung in höheren Schichten kann auch erforderlich sein, um den Inhalt einer Nachricht die weitergeleitet werden soll überprüfen zu können. Der Inhalt kann nur dann analysiert werden, wenn die komplette Nachricht empfangen ist.

Claims

Patentansprüche
1. Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen, wobei die Gateway-Einheit wenigstens zwei Subsysteme miteinander verbindet, dadurch gekennzeichnet, dass die Gateway-Einheit aus wenigstens einem modularen Software-Gateway besteht, welches Nachrichten zwischen genau zwei Subnetzen routet.
2. Gateway-Einheit nach Anspruch 1, dadurch gekennzeichnet, dass wenigstens drei Subnetze an die Gateway-Einheit angeschlossen sind, wobei modulare Software- Gateways eingesetzt werden, wobei jedes modulare Software-Gateway Nachrichten zwischen genau zwei Subsystemen routen.
3. Gateway-Einheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ferner für jedes Subnetz busspezifische Empfangsobjekte vorgesehen sind, welche die ankommenden Nachrichten an ausgewählte Software-
Gateways weitergeben.
4. Gateway-Einheit nach Anspruch 3, dadurch gekennzeichnet, dass die Empfangsobjekte Routing-Tabellen umfassen, in denen die Behandlung ankommender Nachrichten konfiguriert sind.
5. Gateway-Einheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass ferner für jedes Subnetz busspezifische Sendeobjekte vorgesehen sind, welche den Zugriff auf den jeweiligen Bus kontrollieren.
6. Gateway-Einheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das modulare Software-Gateway ankommende Nachrichten zwischenpuffert und protokollspezifische Anpassungen vornimmt.
7. Gateway-Einheit nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei Integration des Gateways in ein Steuergerät mit Anwendungssystem wenigstens ein modulares logisches Gateway in einer Schicht des Kommunikationssystems vorgesehen sein können, wobei das logische Gateway genau zwei Subsysteme verbindet.
PCT/DE2003/003848 2002-11-20 2003-11-20 Gateway-einheit zur verbindung von subnetzen in fahrzeugen WO2004047385A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP03788797A EP1566029B1 (de) 2002-11-20 2003-11-20 Gateway-einheit zur verbindung von subnetzen in fahrzeugen
US10/535,486 US7802016B2 (en) 2002-11-20 2003-11-20 Gateway unit for connecting sub-networks, in particular in vehicles
JP2004552418A JP2006506862A (ja) 2002-11-20 2003-11-20 例えば車両におけるサブネットワークを接続するためのゲートウェイユニット
DE50308326T DE50308326D1 (de) 2002-11-20 2003-11-20 Gateway-einheit zur verbindung von subnetzen in fahrzeugen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10254285.6 2002-11-20
DE10254285A DE10254285A1 (de) 2002-11-20 2002-11-20 Gateway-Einheit zur Verbindung von Subnetzen, insbesondere in Fahrzeugen

Publications (2)

Publication Number Publication Date
WO2004047385A2 true WO2004047385A2 (de) 2004-06-03
WO2004047385A3 WO2004047385A3 (de) 2004-09-02

Family

ID=32240222

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2003/003848 WO2004047385A2 (de) 2002-11-20 2003-11-20 Gateway-einheit zur verbindung von subnetzen in fahrzeugen

Country Status (5)

Country Link
US (1) US7802016B2 (de)
EP (1) EP1566029B1 (de)
JP (1) JP2006506862A (de)
DE (2) DE10254285A1 (de)
WO (1) WO2004047385A2 (de)

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007134955A1 (de) * 2006-05-24 2007-11-29 Robert Bosch Gmbh Kommunikationsbaustein
WO2007143419A2 (en) * 2006-05-31 2007-12-13 Honeywell International Inc. Apparatus and method for integrating wireless or other field devices in a process control system
WO2008029317A2 (en) * 2006-09-06 2008-03-13 Nxp B.V. Cluster coupler in a time triggered network
EP2197160A1 (de) * 2008-12-10 2010-06-16 Siemens Aktiengesellschaft Azyklischer Datentransfer über einen Feldbuskoppler
US7876722B2 (en) 2006-05-31 2011-01-25 Honeywell International Inc. System and method for wireless communication between wired field devices and control system components
US7889747B2 (en) 2006-05-31 2011-02-15 Honeywell International Inc. Apparatus, system, and method for integrating a wireless network with wired field devices in a process control system
US7965664B2 (en) 2006-05-31 2011-06-21 Honeywell International Inc. Apparatus and method for integrating wireless field devices with a wired protocol in a process control system
US8266602B2 (en) 2006-05-31 2012-09-11 Honeywell International Inc. Apparatus and method for converting between device description languages in a process control system
US8498201B2 (en) 2010-08-26 2013-07-30 Honeywell International Inc. Apparatus and method for improving the reliability of industrial wireless networks that experience outages in backbone connectivity
US8756412B2 (en) 2010-04-16 2014-06-17 Honeywell International Inc. Gateway supporting transparent redundancy in process control systems and other systems and related method
EP2800316A1 (de) * 2013-05-01 2014-11-05 Renesas Electronics Europe GmbH Can fd
US9049049B2 (en) 2008-10-20 2015-06-02 Hitachi Automotive Systems, Ltd. Routing method in in-vehicle gateway device
US9110838B2 (en) 2013-07-31 2015-08-18 Honeywell International Inc. Apparatus and method for synchronizing dynamic process data across redundant input/output modules
US9191843B2 (en) 2013-06-12 2015-11-17 Honeywell International Inc. Apparatus and method for measuring and reporting redundant wireless connectivity over time
US9239574B2 (en) 2011-06-30 2016-01-19 Honeywell International Inc. Apparatus for automating field device operations by capturing device method execution steps for later use and related method
US9609524B2 (en) 2014-05-30 2017-03-28 Honeywell International Inc. Apparatus and method for planning and validating a wireless network
US9612587B2 (en) 2014-02-11 2017-04-04 Honeywell International Inc. Mobile extension for industrial operator consoles
US9699022B2 (en) 2014-08-01 2017-07-04 Honeywell International Inc. System and method for controller redundancy and controller network redundancy with ethernet/IP I/O
US9720404B2 (en) 2014-05-05 2017-08-01 Honeywell International Inc. Gateway offering logical model mapped to independent underlying networks
US10042330B2 (en) 2014-05-07 2018-08-07 Honeywell International Inc. Redundant process controllers for segregated supervisory and industrial control networks
US10148485B2 (en) 2014-09-03 2018-12-04 Honeywell International Inc. Apparatus and method for on-process migration of industrial control and automation system across disparate network types
US10162827B2 (en) 2015-04-08 2018-12-25 Honeywell International Inc. Method and system for distributed control system (DCS) process data cloning and migration through secured file system
US10296482B2 (en) 2017-03-07 2019-05-21 Honeywell International Inc. System and method for flexible connection of redundant input-output modules or other devices
US10409270B2 (en) 2015-04-09 2019-09-10 Honeywell International Inc. Methods for on-process migration from one type of process control device to different type of process control device
US10536526B2 (en) 2014-06-25 2020-01-14 Honeywell International Inc. Apparatus and method for virtualizing a connection to a node in an industrial control and automation system

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1657876A1 (de) 2004-11-12 2006-05-17 Sony Deutschland GmbH Verfahren und Vorrichtung zum Senden von Daten eines ersten Standards und Empfangen von Daten eines zweiten Standards auf einem vorbestimmten Sicherheitsgrad in einem Schichten-Netzwerk
EP1694022A1 (de) * 2005-02-16 2006-08-23 Delphi Technologies, Inc. Lokales Netzwerk für Fahrzeuge
EP1703689B1 (de) * 2005-03-18 2008-09-17 Delphi Technologies, Inc. Lokales Netzwerk für Fahrzeuge
US7467246B2 (en) 2005-02-16 2008-12-16 Delphi Technologies, Inc. Secure local network
US7779196B2 (en) 2006-03-01 2010-08-17 Snap-On Technologies, Inc. Interface between busses of different physical layers
US20100220744A1 (en) * 2006-09-06 2010-09-02 Nxp, B.V. Intelligent start coupler for time triggered communication protocol and method for communicating between nodes within a network using a time trigger protocol
EP2122926B1 (de) * 2006-12-14 2012-04-04 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Vernetzung von Steuergeräten eines Kraftfahrzeugs, darauf beruhendes Datenbussystem und Computerprogramm-Produkt
WO2009026597A1 (en) * 2007-08-28 2009-03-05 Tttech Computertechnik Aktiengesellschaft Method for switching from a distributed principle to a master-slave principle in a network
DE102007049958A1 (de) * 2007-10-18 2009-05-07 Siemens Ag Verfahren und System zur Aktualisierung einer mehrschichtigen Applikation
US20110103383A1 (en) * 2009-10-30 2011-05-05 Honeywell International Inc. Two dimensional location transparency of software services
US8924498B2 (en) 2010-11-09 2014-12-30 Honeywell International Inc. Method and system for process control network migration
DE102011083254A1 (de) * 2011-09-23 2013-03-28 Robert Bosch Gmbh Verfahren und Vorrichtung zum Koppeln eines ersten Sensors mit zumindest einem zweiten Sensor
US8797902B2 (en) * 2012-05-29 2014-08-05 Alcatel Lucent Routing decision context objects
US20160103431A1 (en) * 2014-10-14 2016-04-14 Honeywell International, Inc. System and method for point by point hot cutover of controllers and ios
US10401816B2 (en) 2017-07-20 2019-09-03 Honeywell International Inc. Legacy control functions in newgen controllers alongside newgen control functions
EP3676997B1 (de) * 2017-08-31 2022-05-04 Hella Gmbh & Co. Kgaa Datenübertragung zwischen einer steuervorrichtung und einem elektrischen bauteil eines fahrzeugs
WO2020039295A1 (en) * 2018-08-23 2020-02-27 Precision Planting Llc Expandable network architecture for communications between machines and implements
DE102018128095A1 (de) * 2018-11-09 2020-05-14 Lemken Gmbh & Co. Kg Verfahren zum gleichzeitigen Betreiben mehrerer für eine Anwendung zu einer Gerätekombination miteinander verbundener landwirtschaftlicher Geräte
US11323548B2 (en) 2019-01-20 2022-05-03 Arilou Information Security Technologies Ltd. System and method for data compression based on data position in frames structure
CN110667579B (zh) * 2019-10-12 2021-11-16 上海伊控动力系统有限公司 机动车的巡航控制方法及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10044818A1 (de) * 2000-09-11 2002-04-04 Am3 Automotive Multimedia Ag Verfahren zur Adaption von Bussystemen
US20020141438A1 (en) * 2001-02-09 2002-10-03 Smith J. Howard Data communication controller and method
EP1361713A1 (de) * 2002-05-06 2003-11-12 Sony International (Europe) GmbH Gateway

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9406477D0 (en) * 1994-03-31 1994-05-25 D2B Systems Co Ltd Interconnection of local communication bus systems
US5630101A (en) * 1994-11-22 1997-05-13 Minnesota Mining And Manufacturing Company System for communication of image information between multiple-protocol imaging devices
US20040264402A9 (en) * 1995-06-01 2004-12-30 Padcom. Inc. Port routing functionality
JPH118647A (ja) * 1997-06-18 1999-01-12 Fujitsu Ten Ltd ゲートウェイ
JPH11234333A (ja) * 1998-02-13 1999-08-27 Chokosoku Network Computer Gijutsu Kenkyusho:Kk ゲートウェイ装置
JP2000066967A (ja) * 1998-08-26 2000-03-03 Alpine Electronics Inc 車載コンピュータシステム
JP2000115768A (ja) * 1998-10-01 2000-04-21 Fujitsu Ltd 接続制御装置
US6212546B1 (en) * 1998-10-01 2001-04-03 Unisys Corporation Providing a modular gateway architecture which isolates attributes of the client and server systems into independent components
AU7861700A (en) * 1999-10-06 2001-05-10 Sensoria Corporation Method for collecting data using compact internetworked wireless integrated network sensors (wins)
DE10000922A1 (de) * 2000-01-12 2001-07-19 Volkswagen Ag Elektronisches System
JP3617406B2 (ja) * 2000-03-30 2005-02-02 日本電気株式会社 マルチドメインに対応した品質保証型通信サービス提供方式およびサービス提供方法並びにサービス仲介装置
US6693901B1 (en) * 2000-04-06 2004-02-17 Lucent Technologies Inc. Backplane configuration without common switch fabric
US7559066B2 (en) * 2000-08-08 2009-07-07 International Business Machines Corporation CICS BMS (basic message service) meta model
WO2002019636A1 (en) * 2000-08-31 2002-03-07 Padcom, Inc. Method and apparatus for routing data over multiple wireless networks
US7366769B2 (en) * 2000-10-02 2008-04-29 Schlumberger Technology Corporation System, method and computer program product for a universal communication connector
US20020065935A1 (en) * 2000-10-18 2002-05-30 Koperda Frank R. Method and system for a modular residential gateway
US20060036941A1 (en) * 2001-01-09 2006-02-16 Tim Neil System and method for developing an application for extending access to local software of a wireless device
US7152094B1 (en) * 2001-07-31 2006-12-19 Sprint Communications Company L.P. Middleware brokering system adapter

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10044818A1 (de) * 2000-09-11 2002-04-04 Am3 Automotive Multimedia Ag Verfahren zur Adaption von Bussystemen
US20020141438A1 (en) * 2001-02-09 2002-10-03 Smith J. Howard Data communication controller and method
EP1361713A1 (de) * 2002-05-06 2003-11-12 Sony International (Europe) GmbH Gateway

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
AMIRFAIZ F E: "DESIGN AND IMPLEMENTATION OF A GENERIC GATEWAY" PROCEEDINGS OF THE COMPUTER NETWORKING SYMPOSIUM. WASHINGTON, NOV. 17 - 18, 1986, WASHINGTON, IEEE COMP. SOC. PRESS, US, November 1986 (1986-11), Seiten 205-213, XP000812879 *

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8301821B2 (en) 2006-05-24 2012-10-30 Robert Bosch Gmbh Communication module for connecting a serial bus to a plurality of system buses
WO2007134955A1 (de) * 2006-05-24 2007-11-29 Robert Bosch Gmbh Kommunikationsbaustein
WO2007143419A2 (en) * 2006-05-31 2007-12-13 Honeywell International Inc. Apparatus and method for integrating wireless or other field devices in a process control system
WO2007143419A3 (en) * 2006-05-31 2008-06-05 Honeywell Int Inc Apparatus and method for integrating wireless or other field devices in a process control system
US7675935B2 (en) 2006-05-31 2010-03-09 Honeywell International Inc. Apparatus and method for integrating wireless or other field devices in a process control system
US7876722B2 (en) 2006-05-31 2011-01-25 Honeywell International Inc. System and method for wireless communication between wired field devices and control system components
US7889747B2 (en) 2006-05-31 2011-02-15 Honeywell International Inc. Apparatus, system, and method for integrating a wireless network with wired field devices in a process control system
US7965664B2 (en) 2006-05-31 2011-06-21 Honeywell International Inc. Apparatus and method for integrating wireless field devices with a wired protocol in a process control system
US8266602B2 (en) 2006-05-31 2012-09-11 Honeywell International Inc. Apparatus and method for converting between device description languages in a process control system
WO2008029317A2 (en) * 2006-09-06 2008-03-13 Nxp B.V. Cluster coupler in a time triggered network
WO2008029317A3 (en) * 2006-09-06 2008-05-15 Nxp Bv Cluster coupler in a time triggered network
US9049049B2 (en) 2008-10-20 2015-06-02 Hitachi Automotive Systems, Ltd. Routing method in in-vehicle gateway device
EP2197160A1 (de) * 2008-12-10 2010-06-16 Siemens Aktiengesellschaft Azyklischer Datentransfer über einen Feldbuskoppler
US8756412B2 (en) 2010-04-16 2014-06-17 Honeywell International Inc. Gateway supporting transparent redundancy in process control systems and other systems and related method
US8498201B2 (en) 2010-08-26 2013-07-30 Honeywell International Inc. Apparatus and method for improving the reliability of industrial wireless networks that experience outages in backbone connectivity
US9239574B2 (en) 2011-06-30 2016-01-19 Honeywell International Inc. Apparatus for automating field device operations by capturing device method execution steps for later use and related method
EP2800316A1 (de) * 2013-05-01 2014-11-05 Renesas Electronics Europe GmbH Can fd
WO2014177330A1 (en) * 2013-05-01 2014-11-06 Renesas Electronics Europe Gmbh Can fd
US10020958B2 (en) 2013-05-01 2018-07-10 Renesas Electronics Europe Gmbh Can fd
US9191843B2 (en) 2013-06-12 2015-11-17 Honeywell International Inc. Apparatus and method for measuring and reporting redundant wireless connectivity over time
US9110838B2 (en) 2013-07-31 2015-08-18 Honeywell International Inc. Apparatus and method for synchronizing dynamic process data across redundant input/output modules
US9448952B2 (en) 2013-07-31 2016-09-20 Honeywell International Inc. Apparatus and method for synchronizing dynamic process data across redundant input/output modules
US9612587B2 (en) 2014-02-11 2017-04-04 Honeywell International Inc. Mobile extension for industrial operator consoles
US9720404B2 (en) 2014-05-05 2017-08-01 Honeywell International Inc. Gateway offering logical model mapped to independent underlying networks
US10042330B2 (en) 2014-05-07 2018-08-07 Honeywell International Inc. Redundant process controllers for segregated supervisory and industrial control networks
US9609524B2 (en) 2014-05-30 2017-03-28 Honeywell International Inc. Apparatus and method for planning and validating a wireless network
US10536526B2 (en) 2014-06-25 2020-01-14 Honeywell International Inc. Apparatus and method for virtualizing a connection to a node in an industrial control and automation system
US9699022B2 (en) 2014-08-01 2017-07-04 Honeywell International Inc. System and method for controller redundancy and controller network redundancy with ethernet/IP I/O
US10148485B2 (en) 2014-09-03 2018-12-04 Honeywell International Inc. Apparatus and method for on-process migration of industrial control and automation system across disparate network types
US10162827B2 (en) 2015-04-08 2018-12-25 Honeywell International Inc. Method and system for distributed control system (DCS) process data cloning and migration through secured file system
US10409270B2 (en) 2015-04-09 2019-09-10 Honeywell International Inc. Methods for on-process migration from one type of process control device to different type of process control device
US10296482B2 (en) 2017-03-07 2019-05-21 Honeywell International Inc. System and method for flexible connection of redundant input-output modules or other devices

Also Published As

Publication number Publication date
US20060130049A1 (en) 2006-06-15
EP1566029A2 (de) 2005-08-24
EP1566029B1 (de) 2007-10-03
DE50308326D1 (de) 2007-11-15
WO2004047385A3 (de) 2004-09-02
JP2006506862A (ja) 2006-02-23
US7802016B2 (en) 2010-09-21
DE10254285A1 (de) 2004-06-03

Similar Documents

Publication Publication Date Title
EP1566029B1 (de) Gateway-einheit zur verbindung von subnetzen in fahrzeugen
EP3523930B1 (de) Kraftfahrzeug mit einem fahrzeuginternen datennetzwerk sowie verfahren zum betreiben des kraftfahrzeugs
EP2302841B1 (de) Verfahren und Vorrichtung zur sicherheitsgerichteten Kommunikation im Kommunikations-Netzwerk einer Automatisierungs-Anlage
EP2688249B1 (de) Verfahren zur Nachrichtenübermittlung in einem redundant betreibbaren industriellen Kommunikationsnetz und Kommunikationsgerät für ein redundant betreibbares industrielles Kommunikationsnetz
EP2087646B1 (de) Vorrichtung und verfahren zur manipulation von kommunikations-botschaften
WO2015028342A1 (de) Modusumschaltung eines steuergeräts zwischen diagnosebus und externer ethernetverbindung
EP2413538B1 (de) Vermeidung von Sendeschleifen in einem redundanten Ringnetzwerk
EP2637362B1 (de) Busteilnehmer-einrichtung zum anschluss an einen linienredundanten, seriellen datenbus und verfahren zur steuerung der kommunikation eines busteilnehmers mit einem linienredundanten, seriellen datenbus
EP3170288B1 (de) Netzknoten, steuermodul für eine komponente und ethernet ring
DE102006055514A1 (de) Gateway zum Datentransfer zwischen seriellen Bussen
WO1999014643A1 (de) Vorrichtung und verfahren zur steuerung von maschinen, insbesondere webmaschinen
EP3759871B1 (de) Master-slave bussystem und verfahren zum betrieb eines bussystems
WO2006024558A1 (de) Kommunikationsbaustein mit einem kommunikationsschnittstellenelement und kommunikationsschnittstellenelement
EP2137893A1 (de) Paketvermittlungsvorrichtung und lokales kommunikationsnetz mit einer solchen paketvermittlungsvorrichtung
EP3228036B1 (de) Verfahren und steuergerät zur übertragung sicherheitsrelevanter daten in einem kraftfahrzeug mittels eines ethernet-standards
EP1820111B1 (de) Kommunikationsbausteinanordnung mit einem schnittstellenmodul und schnittstellenmodul
EP3497890B1 (de) Verfahren zum übertragen von nachrichten zwischen steuergeräten eines kraftfahrzeugs sowie switchvorrichtung und kraftfahrzeug
DE102016209370A1 (de) Steuervorrichtung und Verfahren zum Übertragen von Datenpaketen zwischen einem Ethernet-Netzwerk und einem zeitgesteuerten Bus-Netzwerk, insbesondere in einem Kraftfahrzeug
DE10244427A1 (de) Kommunikationssystem mit Teilnehmer mit Diagnoseeinheit
WO2020099298A1 (de) Steuergerätearchitektur für fahrzeuge
EP3963838B1 (de) Netzwerkteilnehmer und automatisierungsnetzwerk
EP1629637B1 (de) Übertragung von nachrichten in einem verteilten, zeitgesteuerten echtzeitsystem
DE102018010209A1 (de) Master-Slave Bussystem und Verfahren zum Betrieb eines Bussystems
DE60314928T2 (de) Schaltungsanordnung für ein elektronisches Steuermodul zur Umsetzung von Kommunikationsprotokollen
DE102013008999A1 (de) Einrichtung und Verfahren zur Übertragung von Daten in einem Kraftfahrzeug

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): JP US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR

WWE Wipo information: entry into national phase

Ref document number: 2003788797

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004552418

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2003788797

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2006130049

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10535486

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10535486

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2003788797

Country of ref document: EP