WO2006044140A2 - Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile - Google Patents

Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile Download PDF

Info

Publication number
WO2006044140A2
WO2006044140A2 PCT/US2005/034865 US2005034865W WO2006044140A2 WO 2006044140 A2 WO2006044140 A2 WO 2006044140A2 US 2005034865 W US2005034865 W US 2005034865W WO 2006044140 A2 WO2006044140 A2 WO 2006044140A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
offset
request message
synchronization request
synchronization
Prior art date
Application number
PCT/US2005/034865
Other languages
English (en)
Other versions
WO2006044140A3 (fr
Inventor
Patrick D. Jordan
Hai Dong
Hugh W. Johnson
Prakash U. Kartha
Original Assignee
Motorola, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US11/016,139 external-priority patent/US7623552B2/en
Application filed by Motorola, Inc. filed Critical Motorola, Inc.
Publication of WO2006044140A2 publication Critical patent/WO2006044140A2/fr
Publication of WO2006044140A3 publication Critical patent/WO2006044140A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0676—Mutual
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/40—Bus networks
    • H04L12/403—Bus networks with centralised control, e.g. polling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/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
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L2012/5672—Multiplexing, e.g. coding, scrambling
    • H04L2012/5674—Synchronisation, timing recovery or alignment

Definitions

  • This invention in general relates to in-vehicle communication networks and particularly to a system and method for synchronizing nodes in an in-vehicle network.
  • the switch fabric is a web of interconnected switching devices or nodes. Control devices, sensors, actuators and the like are coupled to the switch fabric, and the switch fabric facilitates communication between these coupled devices.
  • the coupled devices may be indicator lights, vehicle control systems, vehicle safety systems, and comfort and convenience systems.
  • a command to actuate a device or devices may be generated by a control element coupled to the switch fabric and is communicated to the device or devices via the switch fabric.
  • the command may require simultaneous activation of two or more devices.
  • the switch fabric may be a packet based communication medium making coordinating simultaneous events difficult. To illustrate this difficulty take for example the need to capture data from multiple sensors at the same time. For example, it may be necessary to communicate various control parameters from a number of engine sensors to an engine controller so that it may then issue commands for the control of the engine. For example, to detect misfire, the engine controller receives data from several oxygen sensors, the crankshaft position sensor and potentially other sensors.
  • the data must arrive to the engine controller in a coordinated manner or have a reliable time indication. Unless each of the sensors are time synchronized, there is no way to accurately time stamp the data packets or to effectively communicate them to the engine controller in a coordinated manner.
  • Another problem may involve the need for multiple devices to be activated at the same time or at a predefined time in the future. For example, there is a need to illuminate the left, right and center high-mounted brake lights on an automobile. Each of the brake lights should appear to illuminate substantially simultaneously. Each of the lights is coupled to the switch fabric. The command to illuminate the lights may be generated by a braking control module, which is also coupled to the switch fabric. The command is communicated from the braking control module to the three brake lights. However, the command may take different incremental amounts of time based upon the paths the command takes through the network to arrive at each of the three brake lights. If the brake lights act on the command when received, the lights may not appear to come on simultaneously.
  • the command may give a time at which to activate, but if each of the brake lights are not time synchronized, they still will not actuate at the same coordinated time. It is, therefore, desirable to provide a system and method to overcome or minimize most, if not all, of the preceding problems especially in the area of synchronizing elements of an in-vehicle network.
  • FIG. 1 is a block diagram illustrating an embodiment of a vehicle active network
  • FIG. 2 is a graphic illustration of an embodiment of a vehicle switch fabric network according to the invention.
  • FIG. 3 is a graphic illustration of a portion of the vehicle active network illustrating the exchange of messages between two nodes
  • FIG. 4 is a flow diagram illustrating one embodiment of a synchronization process between two nodes
  • FIG. 5 is a graphic illustration of an offset table that may be stored in a node of the vehicle active network
  • FIG. 6 is a graphic illustration of a routing table that may be stored in a node of the vehicle active network.
  • a synchronization request message is transmitted from a requesting node to a neighboring node.
  • the requesting node will store a unique message identification associated with the request message as well as a first timestamp that is associated with the time that the synchronization request message was transmitted by the requesting node.
  • the neighboring node will receive the synchronization request message and store a second timestamp associated with the time that the synchronization request message was received by the neighboring node. Thereafter, the neighboring node will transmit to the requesting node a synchronization response message that includes the message identification and the second timestamp.
  • the requesting node will then calculate a timer offset value that is based on the first timestamp and the second timestamp.
  • the timer offset values may then be shared with other nodes in the network so that a summed offset may be used to transmit network messages across a plurality of nodes.
  • FIG. 1 illustrates a vehicle 20 including a network 22 to which various vehicle devices 24a-d are coupled via respective interfaces 26a-d.
  • the vehicle devices 24a-d may be sensors, actuators, and processors used in connection with various vehicle functional systems and sub-systems, such as, but not limited to, diagnostics, control-by-wire applications for throttle, braking and steering control, adaptive suspension, power accessory control, communications, entertainment, and the like.
  • the interfaces 26a-d are any suitable interface for coupling the particular vehicle device 24a-d to the network 22, and may be wire, optical, wireless or combinations thereof.
  • the vehicle device 24a-d is particularly adapted to provide one or more functions associated with the vehicle 20.
  • vehicle devices 24a-d may be data producing, such as a sensor, data consuming, such as an actuator, or processing, which both produces and consumes data.
  • an actuator typically a data- consuming device, may also produce data, for example where the actuator produces data indicating it has achieved the instructed state, or a sensor may consume data, for example, where it is provided instructions for the manner of function.
  • Data produced by or provided to a vehicle device 24a-d, and carried by the network 22, is independent of the function of the vehicle device 24a-d itself. That is, the interfaces 26a-d provide device independent data exchange between the coupled device 24a-d and the network 22.
  • the network 22 may include a switch fabric 28 defining a plurality of communication paths between the vehicle devices 24a-d.
  • the communication paths permit multiple simultaneous peer-to-peer, one-to-many, many-to-many, etc. communications between the vehicle devices 24a-d.
  • data exchanged, for example, between devices 24a and 24d may utilize any available path or paths between the vehicle devices 24a, 24d.
  • a single path through the switch fabric 28 may carry all of a single data communication between one vehicle device 24a and another vehicle device 24d, or several communication paths may carry portions of the data communication. Subsequent communications may use the same path or other paths as dictated by the then state of the network 22. This provides reliability and speed advantages over bus architectures that provide single communication paths between devices, and hence are subject to failure with failure of the single path.
  • communications between other of the devices 24b, 24c may occur simultaneously using the communication paths within the switch fabric 28.
  • the network 22 may comply with transmission control protocol/Internet (TCP/IP), asynchronous transfer mode (ATM), Infiniband, RapidIO, or other packet data protocols. As such, the network 22 utilizes data packets, having fixed or variable length, defined by the applicable protocol. For example, if the network 22 uses asynchronous transfer mode (ATM) communication protocol, ATM standard data cells are used.
  • TCP/IP transmission control protocol/Internet
  • ATM asynchronous transfer mode
  • ATM asynchronous transfer mode
  • ATM ATM standard data cells are used.
  • the vehicle devices 24a-d need not be discrete devices.
  • the devices may be systems or subsystems of the vehicle and may include one or more legacy communication media, i.e., legacy bus architectures such as the Controller Area Network (CAN) protocol, the SAE Jl 850 Communications Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, the Media Oriented Systems Transport or MOST Protocol, or similar bus structures.
  • legacy bus architectures such as the Controller Area Network (CAN) protocol, the SAE Jl 850 Communications Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, the Media Oriented Systems Transport or MOST Protocol, or similar bus structures.
  • the respective interface 26a-d may be configured as a proxy or gateway to permit communication between the network 22 and the legacy device,
  • an active network 22 in accordance with one embodiment of the present invention includes a switch fabric 28 of nodes 30a-h that communicatively couple a plurality of devices 24a-d via respective interfaces 26a-d.
  • Connection media 32 interconnects the nodes 30a-h.
  • the connection media 32 may be bounded media, such as wire or optical fiber, unbounded media, such as free optical or radio frequency, or combinations thereof.
  • node is used broadly in connection with the definition of the switch fabric 28 to include any number of intelligent structures for communicating data packets within the network 22 without an arbiter or other network controller and may include: switches, intelligent switches, routers, bridges, gateways and the like. Data is thus carried through the network 22 in data packet form guided by the nodes 30a-h.
  • a route 34 defines a communication path from device 24a to device 24d. If there is a disruption along the route 34 inhibiting communication of the data packets from the device 24a to the device 24d, for example, if one or more nodes are at capacity or have become disabled or there is a disruption in the connection media joining the nodes along route 34, a new route, illustrated as route 36, can be used.
  • the route 36 may be dynamically generated or previously defined as a possible communication path, to ensure the communication between device 24a and device 24d.
  • FIG. 3 illustrates a portion of the network 22 that includes a switch fabric 28 of nodes, including a first node 30a and a second node 30b. Connection media 32 interconnects the first node 30a to the second node 30b.
  • the first node 30a and the second node 30b may include a microprocessor 40a,b, a memory 42a,b, a clock 44a,b, and a data transceiver 46a,b to transmit and send data.
  • the microprocessor 40a,b includes a suitable control program for effecting the operation of the node 30a,b for coupling inputs and outputs in order to transmit data within the network 22.
  • the microprocessor 40a,b may be configured to effect the operation of the timestamp of the transmission and reception of synchronization messages, as will be explained in further detail below.
  • FIG. 3 also illustrates, at a high level, one embodiment of the present invention for generating and providing synchronization information within the network 22.
  • the process begins by the first node 30a transmitting a synchronization request message to the second node 30b (arrow 50).
  • the synchronization request message may be sent on a predetermined, periodic basis.
  • the synchronization request message may include a variety of field including an identification of the sending node and a message identification.
  • the second node 30b will respond with a synchronization response message that includes a timestamp that represents the time when the synchronization request message was received by the second node 30b (arrow 52).
  • the first node 30a will then calculate a timer offset value between the two nodes and store the offset value in an offset table or database.
  • FIG. 4 further explains, at a more detailed level, one embodiment of the present invention for providing synchronization information within the network 22. Synchronization in this case is a process used by the nodes to calculate the relative clock offset between themselves and other neighboring nodes in the network 22.
  • the flow diagrams in FIG. 4 contain further descriptions of one embodiment for implementing the functions to calculate neighboring offsets by a node. For purposes of illustration, these diagrams represent a synchronization dialogue between the requesting node (such as node 30a) and any immediate neighboring nodes (such as nodes 30b, 30e).
  • the requesting node (the node that desires to initiate synchronization messages) may be configured to compute offsets with any neighboring nodes on a predetermined, periodic basis.
  • decision block 102 if the requesting node needs to compute offsets with its neighboring nodes, the process will continue to process block 104. Otherwise, the process will remain at decision block 102.
  • the requesting node may set a counter so that it can compute offsets with each connecting neighboring node.
  • each node may have one or more input/output data ports that connect the node's data transceiver to the communication link 32 for the transmission and reception of data message with another neighboring node.
  • FIG. 2 illustrates that the node 30a is connected to neighboring nodes 30b and 30e via different communication links 32.
  • the synchronization request message may include a variety of fields such as an identification of the sending node and a message identification.
  • the requesting node After the transmission of the synchronization request message, in block 108, the requesting node will store a value of a timestamp from its clock in memory that represents the time that the synchronization request message was sent to the neighboring node.
  • the neighboring node will receive the synchronization request message from the requesting node.
  • the neighboring node will store the message identification of the synchronization request message and a value of a timestamp from its clock in memory that represent the time that the synchronization request message was received at the neighboring node.
  • the neighboring node will then transmit a synchronization response message back to the requesting node as shown in process block 114.
  • the synchronization response message may include fields such as the message identification in the synchronization request message and the timestamp value associated with the time that the request message was received at the neighboring node.
  • the requesting node will receive the synchronization response message from the neighboring node.
  • the requesting node may then perform a series of tasks including verifying the message identification, computing an offset value, and storing the offset value in an offset table in its memory.
  • the requesting node will compare the message identification in the synchronization response message (received from the neighboring node) with the message identification in the synchronization request message (transmitted to the neighboring node). If they match, the process continues to process block 122.
  • the requesting node may further initiate a series of steps to see if there is a failure in the link between the requesting node and the neighboring node.
  • the requesting node may compute the offset value based on the difference in time between the timestamp associated with the time that the reference synchronization message left the requesting node (stored in the requesting node's memory) and the timestamp associated with the time that the reference synchronization message was received by the neighboring node (retrieved from the synchronization response message transmitted by the neighboring node).
  • the requesting node may then store the computed offset in an offset table in its memory as illustrated in block 124.
  • the requesting node may then proceed to do a similar process with any other immediate neighboring nodes. Accordingly, in decision block 126, a determination is made whether additional input/output data ports exist on the requesting node that are connected to other neighboring nodes. If so, at process block 128, the process may increment a counter to step through the next input/output data port on the requesting node. The process continues back to block 106 where a new synchronization request message is transmitted to the next neighboring node. This will result in another computed offset that is stored in memory.
  • each node 30a-h may maintain an offset table 70 in memory that represents the offsets that it has computed on its own as well as any offsets that it has received from other nodes.
  • the benefit of the offset table 70 as illustrated in FIG. 5, is that a node may further compute or calculate a clock offset between itself and any other node on the network 22. As shown in FIG.
  • the nodes 30a-h may be configured to infer or determine an acceleration or drift rate of remote clocks over time.
  • the acceleration or drift rate may be computed by determining the difference between computed or received offsets over the difference in time between synchronization dialogs.
  • Using inferred acceleration and drifts of clocks can improve accuracy between the periodic synchronization steps. It also allows the system to use less accurate crystals or ceramic resonators to reduce costs. It further allows longer periods between synchronization dialogs.
  • a synchronization request message is transmitted from a requesting node to a neighboring node.
  • the requesting node will store a unique message identification associated with the request message as well as a timestamp that is associated with the time that the synchronization request message was transmitted by the requesting node.
  • a neighboring node will receive the synchronization request message and store the message identification in the request message as well as a timestamp associated with the time that the synchronization request message was received by the neighboring node.
  • the neighboring node will transmit to the requesting node a synchronization response message that includes the message identification and the timestamp associated with the time that the synchronization request message was received by the neighboring node.
  • the requesting node will then calculate a timer offset value that is based on the timestamp that the synchronization request message left the requesting node and the timestamp that the synchronization request message was received by the neighboring node.
  • the timer offset values may then be shared with other nodes in the network so that a summed offset may be used to transmit network messages across a plurality of nodes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)

Abstract

Un message de demande de synchronisation est émis par un noeud demandeur à un noeud voisin. Après transmission au message de demande de synchronisation, le noeud demandeur mémorise une identification de message unique, associée au message de demande, et sous forme d'une première marque temporelle associée au temps de transmission du message de demande de synchronisation par le noeud demandeur. Le noeud voisin reçoit le message de demande de synchronisation et mémorise une seconde marque temporelle associée au moment où la demande de synchronisation a été reçue par le noeud voisin. Le noeud voisin transmet ensuite au noeud demandeur un message de réponse de synchronisation comprenant l'identification du message et la seconde marque temporelle. Le noeud demandeur calcule une valeur de décalage d'horloge basée sur la première et la seconde marques temporelles. Les valeurs de décalage d'horloge peuvent alors être partagées avec d'autres noeuds dans le réseau, de façon qu'un décalage cumulé puisse être utilisé pour transmettre les messages de réseau à travers une pluralité de noeuds.
PCT/US2005/034865 2004-10-14 2005-09-29 Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile WO2006044140A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US61876904P 2004-10-14 2004-10-14
US60/618,769 2004-10-14
US11/016,139 US7623552B2 (en) 2004-10-14 2004-12-17 System and method for time synchronizing nodes in an automotive network using input capture
US11/016,139 2004-12-17

Publications (2)

Publication Number Publication Date
WO2006044140A2 true WO2006044140A2 (fr) 2006-04-27
WO2006044140A3 WO2006044140A3 (fr) 2006-09-08

Family

ID=36203381

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/034865 WO2006044140A2 (fr) 2004-10-14 2005-09-29 Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile

Country Status (1)

Country Link
WO (1) WO2006044140A2 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009144308A3 (fr) * 2008-05-30 2010-02-25 Continental Teves Ag & Co. Ohg Interface de type serial peripheral interface (interface de périphérique série) à nombre réduit de lignes de connexion
WO2010058008A1 (fr) * 2008-11-21 2010-05-27 Continental Tevesag & Co. Ohg Protocole de transmission de données
EP2637360A4 (fr) * 2010-11-01 2015-05-06 Toshiba Kk Terminal et procédé de communication
RU2635377C2 (ru) * 2012-08-07 2017-11-13 Филипс Лайтинг Холдинг Б.В. Синхронизированное по времени управление освещением
TWI734743B (zh) * 2016-02-22 2021-08-01 日商富士電機股份有限公司 控制網路系統及其節點裝置

Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4816989A (en) * 1987-04-15 1989-03-28 Allied-Signal Inc. Synchronizer for a fault tolerant multiple node processing system
US5195091A (en) * 1991-07-09 1993-03-16 At&T Bell Laboratories Adaptive synchronization arrangement
US5566180A (en) * 1994-12-21 1996-10-15 Hewlett-Packard Company Method for recognizing events and synchronizing clocks
US5612953A (en) * 1991-02-22 1997-03-18 International Business Machines Corporation Multi-media serial line switching adapter for parallel networks and heterogeneous and homologous computer systems
US6373834B1 (en) * 1997-12-19 2002-04-16 Telefonaktiebolaget Lm Ericsson Synchronization for cellular telecommunications network
US20020080829A1 (en) * 1998-07-22 2002-06-27 Yoram Ofek Link transmission control with common time reference
US6420797B1 (en) * 1998-02-19 2002-07-16 Robert Edward Steele Electrical/electronic system architecture
US20030091035A1 (en) * 2000-11-21 2003-05-15 Roy Subhash C. Phase and frequency drift and jitter compensation in a distributed telecommunications switch
US6611519B1 (en) * 1998-08-19 2003-08-26 Swxtch The Rules, Llc Layer one switching in a packet, cell, or frame-based network
US6747365B2 (en) * 2001-08-31 2004-06-08 Motorola, Inc. Vehicle active network adapted to legacy architecture

Patent Citations (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4816989A (en) * 1987-04-15 1989-03-28 Allied-Signal Inc. Synchronizer for a fault tolerant multiple node processing system
US5612953A (en) * 1991-02-22 1997-03-18 International Business Machines Corporation Multi-media serial line switching adapter for parallel networks and heterogeneous and homologous computer systems
US5195091A (en) * 1991-07-09 1993-03-16 At&T Bell Laboratories Adaptive synchronization arrangement
US5566180A (en) * 1994-12-21 1996-10-15 Hewlett-Packard Company Method for recognizing events and synchronizing clocks
US6373834B1 (en) * 1997-12-19 2002-04-16 Telefonaktiebolaget Lm Ericsson Synchronization for cellular telecommunications network
US6420797B1 (en) * 1998-02-19 2002-07-16 Robert Edward Steele Electrical/electronic system architecture
US20020080829A1 (en) * 1998-07-22 2002-06-27 Yoram Ofek Link transmission control with common time reference
US6611519B1 (en) * 1998-08-19 2003-08-26 Swxtch The Rules, Llc Layer one switching in a packet, cell, or frame-based network
US20030091035A1 (en) * 2000-11-21 2003-05-15 Roy Subhash C. Phase and frequency drift and jitter compensation in a distributed telecommunications switch
US6747365B2 (en) * 2001-08-31 2004-06-08 Motorola, Inc. Vehicle active network adapted to legacy architecture

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009144308A3 (fr) * 2008-05-30 2010-02-25 Continental Teves Ag & Co. Ohg Interface de type serial peripheral interface (interface de périphérique série) à nombre réduit de lignes de connexion
US9042274B2 (en) 2008-05-30 2015-05-26 Continental Teves Ag & Co. Ohg Serial peripheral interface having a reduced number of connecting lines
WO2010058008A1 (fr) * 2008-11-21 2010-05-27 Continental Tevesag & Co. Ohg Protocole de transmission de données
US8862685B2 (en) 2008-11-21 2014-10-14 Continental Teves Ag & Co. Ohg Data transmission protocol for synchronization communication between two communication devices
EP2637360A4 (fr) * 2010-11-01 2015-05-06 Toshiba Kk Terminal et procédé de communication
RU2635377C2 (ru) * 2012-08-07 2017-11-13 Филипс Лайтинг Холдинг Б.В. Синхронизированное по времени управление освещением
TWI734743B (zh) * 2016-02-22 2021-08-01 日商富士電機股份有限公司 控制網路系統及其節點裝置

Also Published As

Publication number Publication date
WO2006044140A3 (fr) 2006-09-08

Similar Documents

Publication Publication Date Title
US7623552B2 (en) System and method for time synchronizing nodes in an automotive network using input capture
US7593429B2 (en) System and method for time synchronizing nodes in an automotive network using input capture
US20060083172A1 (en) System and method for evaluating the performance of an automotive switch fabric network
US7599377B2 (en) System and method for tunneling standard bus protocol messages through an automotive switch fabric network
US7310327B2 (en) Method and apparatus for time synchronizing an in-vehicle network
Samii et al. Level 5 by layer 2: Time-sensitive networking for autonomous vehicles
US7324892B2 (en) Parameter coordination in a vehicular communication network
CN111264039B (zh) 用于识别以太网消息的有错误的时间戳的方法和用于机动车的控制单元
US7170853B2 (en) Vehicle active network topologies
US20060020717A1 (en) Vehicle active network and device
US6885916B2 (en) Data packet for a vehicle active network
JP2008113457A (ja) 多数のバスのサイクルタイムを同期させる方法と装置及び対応するバスシステム
WO2006044122A2 (fr) Systeme et procede de diffusion en continu de donnees sequentielles a travers un reseau a matrice de commutation d'automobile
WO2006044140A2 (fr) Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile
WO2003021893A1 (fr) Reseau actif pour vehicules a redondance de donnees
WO2008029318A2 (fr) Coupleur de groupes dans un réseau à déclenchement temporel
JP2000224213A (ja) 通信ネットワーク、および該通信ネットワークを構成するマスタ装置、スレーブ装置、多重化装置、並びに交換装置
US11546074B2 (en) Clock topology in an ethernet network
WO2020020932A1 (fr) Découverte de topologie dans un réseau ethernet automobile
US20080306647A1 (en) In-vehicle network system and control method thereof
US20230092840A1 (en) Precision time protocol with multi-chassis link aggregation groups
WO2003021867A2 (fr) Reseaux actifs de vehicules relies
US11094187B2 (en) Sum stream for actual states and control signals of a distributed control system
WO2006044139A2 (fr) Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree
WO2003021897A1 (fr) Reseau actif de vehicule a structure centrale

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase