WO2006044139A2 - Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree - Google Patents

Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree Download PDF

Info

Publication number
WO2006044139A2
WO2006044139A2 PCT/US2005/034863 US2005034863W WO2006044139A2 WO 2006044139 A2 WO2006044139 A2 WO 2006044139A2 US 2005034863 W US2005034863 W US 2005034863W WO 2006044139 A2 WO2006044139 A2 WO 2006044139A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
offset
nodes
timestamp
switch fabric
Prior art date
Application number
PCT/US2005/034863
Other languages
English (en)
Other versions
WO2006044139A3 (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/014,936 external-priority patent/US7593429B2/en
Application filed by Motorola, Inc. filed Critical Motorola, Inc.
Publication of WO2006044139A2 publication Critical patent/WO2006044139A2/fr
Publication of WO2006044139A3 publication Critical patent/WO2006044139A3/fr

Links

Classifications

    • 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

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 using an input capture mechanism.
  • 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
  • FIGS. 4A-4C are flow diagrams illustrating one embodiment of a synchronization dialogue 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.
  • each node of the switch fabric may include a processor, a memory, a clock, a transceiver, and an input capture.
  • the memory is adapted to store and retain timer offsets associated with communication links with neighboring nodes.
  • the transceiver is adapted to transmit and receive synchronization messages between the node and neighboring nodes.
  • the input capture is adapted to capture timestamps associated with the transmission of synchronization messages.
  • 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.
  • These 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
  • the vehicle devices 24a-d need not be discrete devices. Instead, 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 Communication Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, 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 Communication Standard, the Local Interconnect Network (LIN) protocol, the FLEXRAY Communications System Standard, 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.
  • the term 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, a data transceiver 46a,b to transmit and send data, and an input capture 48a,b function.
  • 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 synchronization dialogue in conjunction with the data transceiver 46a,b and the input capture 48a,b, 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 initiating a synchronization dialogue with the second node 30b (arrow 50).
  • the synchronization dialogue will prompt the input captures 48a,b on each node to arm.
  • the second node 30b will respond with an acknowledgement ready message that it is ready to proceed with the synchronization dialogue (arrow 52).
  • the first node 30a will then send a reference synchronization message to the second node 30b (arrow 54).
  • the input capture 48a,b mechanisms on each node 30a,b will respectively capture a timestamp that will represent the time that the synchronization message left the first node 30 and a timestamp that will represent the time that the synchronization message was received at the second node 30b.
  • the respective timestamps at each node 30a,b are shared with each other (arrow 56).
  • Each node 30a,b will then calculate a timer offset value between the two nodes and store the offset value in an offset table or database. Later, each node 30a,b may broadcast the timer offset values that it calculated with neighboring other nodes to the entire network 22 (arrow 58).
  • FIGS. 4A-4C 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 FIGS. 4A-4C 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 first node 30a and the second node 30b.
  • the first node 30a and the second node 30b may operate within a plurality of states and roles. In this example, the roles are defined as an initiator and a receiver.
  • the node may function differently depending on the state of the node. This allows the nodes to have a common software platform but perform different functions and roles during the synchronization dialogue process.
  • the first node 30a and the second node 30b upon startup and during normal operation of the network 22, will enter and remain in a state called SYNC_MODE_INACTIVE.
  • a node such as the first node 30a
  • the node will exit the SYNC-MODE-INACTrVE state and begin traversing through a series of states that will walk the node through the synchronization dialogue process.
  • a node When a node exits the SYNC_MODE_INACTIVE state, all outgoing messages not related to synchronization are held in an outgoing software buffer and not transmitted until the node re-enters the SYNC_MODE_INACTIVE state. As shown in box 102 of FIG. 4A, in one embodiment where a node wants to be an initiator (such as the first node 30a), the node may enter a SYNC_MODE_NOW state.
  • the first node 30a When the first node 30a is in the SYNC_MODE_PENDING state (and designated as the initiator), it may then perform a series of tasks including transmitting a message to the neighboring second node 30b. This is shown in box 108 of FIG. 4A where the first node 30a transmits an initial synchronization message (discovery _sync_initiate) to the second node 30b.
  • the initial synchronization message may include fields such as a priority of the message and an identification of the first node 30a.
  • the first node 30a After transmitting the initial synchronization message to the second node 30b, the first node 30a may then transition from the SYNC_MODE_PENDING state to the SYNC_MODE_READY state as shown in box 110.
  • the second node 30b will receive the initial synchronization message from the first node 30a.
  • the second node 30b will then exit the SYNC_MODE_INACTIVE state and enter the SYNC_MODE_PENDING state as shown in box 114.
  • the second node 30b When the second node 30b is in the SYNC_MODE_READY state (and designated as the receiver), it may then perform a series tasks including transmitting a message to the initiating first node 30a. This is shown in box 120 of FIG. 4A where the second node 30b transmits an acknowledge ready message (discovery ⁇ _syncjready) to the first node 30a. After transmitting the acknowledge ready message to the first node 30a, the second node 30b may then transition from the S YNC_MODE_READY state to the SYNC_MODE_ARMED state as shown in box 122 (FIG. 4B).
  • the first node 30a will receive the acknowledge ready message from the second node 30b.
  • the first node 30a may then exit the SYNC MODE READY state and enter the SYNC MODE ARMED state as shown in box 126.
  • the nodes will arm their respective input captures 48a,b (the input captures are shown in FIG. 3). This will enable the nodes to capture a timestamp associated with the transmission of a reference synchronization message over the communication link 32, as explained further below.
  • the first node 30a When the first node 30a is in the SYNC_MODE_ ARMED state (and designated as the initiator), it may then perform a series of tasks including transmitting a reference synchronization message to the neighboring second node 30b. This is shown in box 132 of FIG. 4B where the first node 30a transmits a reference synchronization message (discovery _sync) to the second node 30b.
  • the first node 30a will store a value of a timestamp from its clock 44a in memory 42a (the input capture, clock, and memory are shown in FIG. 3). After storing the timestamp value in memory 42a, the first node 30a may then transition from the SYNC_MODE_ARMED state to the SYNC_MODE_POST state as shown in box 136.
  • the input capture 48b of the second node 30b will store a value of a timestamp from its clock 44b in memory 42b. The capture may be on the edge of the bus transition when the message is sent.
  • the second node 30b may then transition from the SYNC_MODE_ARMED state to the SYNC_MODE_POST state as shown in box 142.
  • the second node 30b is in the SYNC_MODE_POST state (and designated as the receiver), it may then perform a series of tasks including transmitting a synchronization post message to the initiating first node 30a. This is shown in box 144 of FIG.
  • the second node 30b transmits a synchronization post message ⁇ discovery _sync_posf) to the first node 30a.
  • the synchronization post message may include fields such as the timestamp value captured in memory 42b associated with the transmission of the reference synchronization message.
  • the second node 30b may then transition from the SYNC_MODE_POST state to the SYNC_MODE_COMPLETE state as shown in box 146.
  • the first node 30a will receive the synchronization post message from the second node 30b.
  • the first node 30a may then exit the SYNC_MODE_POST state and enter the SYNC_MODE_COMPLETE state as shown in box 150.
  • the first node 30a is in the
  • the first node 30a may then perform a series of tasks including computing an offset value and storing the offset value in an offset table in its memory 42a.
  • the first node 30a may compute the offset value based on the difference in time between the input capture value stored in its memory with the input capture value received from the second node 30b in the synchronization post message.
  • the first node 30a may then store the computed offset in its memory 42a as illustrated in box 154.
  • the first node 30a may then transmit a synchronization complete message to the neighboring second node 30b. This is shown in box 156 of FIG. 4C where the first node 30a transmits a synchronization complete message ⁇ discovery _sync_complete) to the second node 30b.
  • the synchronization complete message may include fields such as the timestamp value stored in memory 42a associated with the transmission of the reference synchronization message.
  • the synchronization complete message may include the offset value computed by the first node 30a.
  • the first node 30a may then reset all variables and transition from the SYNC_MODE_COMPLETE state to the SYNC_MODE_INACTIVE state as shown in box 158.
  • the second node 30b will receive the synchronization complete message from the first node 30a. If the synchronization complete message includes the timestamp value associated with the transmission of the reference synchronization message, then the second node 30b may then perform additional tasks such as computing an offset value and storing the offset value in an offset table in its memory 42b. With reference to box 162 in FIG. 4C, the second node 30b may compute the offset value based on the difference in time between the input capture value stored in its memory with the input capture value received from the first node 30a in the synchronization complete message. The second node 30b may then store the computed offset in its memory 42b as illustrated in box 164.
  • the second node 30b may then reset all variables and transition from the SYNC_MODE_COMPLETE state to the SYNC MODE INACTIVE state as shown in box 166.
  • the first node 30a may then proceed to do a similar process with any other immediate neighboring nodes.
  • the first node 30a will store in its memory each computed offset with its immediate neighboring nodes.
  • the first node 30a may then further be configured to broadcast its stored offsets with each node 30b-h in the network 22. Each node in the network 22 may then retain the timer offsets discovered by other nodes in the network 22. In one embodiment, as illustrated in FIG.
  • 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. 6, this can be done by summing the individual offsets of node segments stored in its offset table 70 along a particular communication path. For instance, referring to FIG. 2, if node 30a desires to know the timing offset between node 30a and 30g (along path 34), the node will use the offsets computed and received between the communication links of 30a-30b, 30b-30c, and 30c-30g.
  • 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 synchronization dialogues. It also allows the system to use less accurate crystals or ceramic resonators to reduce costs. It further allows the system to wait for longer periods between synchronization dialogues.

Landscapes

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

Abstract

Le réseau comprend une pluralité de noeuds reliés par des liaisons de communication, pour la transmission de données entre eux. Chaque noeud de la matrice de commutation peut comprendre un processeur, une mémoire, une horloge, un émetteur-récepteur et une saisie d'entrée. La mémoire est adaptée pour mémoriser et retenir des décalages d'horloge associés aux liaisons de communication avec des noeuds voisins. L'émetteur-récepteur est adapté pour émettre et recevoir des messages de synchronisation entre le noeud et les noeuds voisins. La saisie d'entrée est adaptée pour saisir une marque temporelle associée à la transmission de messages de synchronisation. Le processeur est configuré pour calculer les décalages d'horloge associés aux liaisons de communication avec les noeuds voisins sur la base des marques temporelles saisies par la fonction de saisie d'entrée. Les décalages calculés peuvent alors être diffusés et mémorisés par les noeuds pour l'usage ultérieur en paquets de données de synchronisation temporelle dans le réseau à matrice de commutation.
PCT/US2005/034863 2004-10-14 2005-09-29 Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree WO2006044139A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US61876804P 2004-10-14 2004-10-14
US60/618,768 2004-10-14
US11/014,936 2004-12-17
US11/014,936 US7593429B2 (en) 2004-10-14 2004-12-17 System and method for time synchronizing nodes in an automotive network using input capture

Publications (2)

Publication Number Publication Date
WO2006044139A2 true WO2006044139A2 (fr) 2006-04-27
WO2006044139A3 WO2006044139A3 (fr) 2006-08-10

Family

ID=36203380

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/034863 WO2006044139A2 (fr) 2004-10-14 2005-09-29 Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree

Country Status (1)

Country Link
WO (1) WO2006044139A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013079365A1 (fr) * 2011-11-30 2013-06-06 Continental Automotive Gmbh Procédé de synchronisation d'horloges dans des nœuds d'un réseau de bord d'un véhicule automobile et nœud configuré pour la mise en œuvre du procédé
EP3166242A1 (fr) * 2015-11-05 2017-05-10 Robert Bosch Gmbh Contrôle de synchronisation d'horloge dans un réseau ethernet
CN109450582A (zh) * 2018-11-01 2019-03-08 百度在线网络技术（北京）有限公司 传感器时间戳同步测试方法、装置、设备、介质及车辆
CN114124276A (zh) * 2020-08-31 2022-03-01 华为技术有限公司 一种分布式***中的时钟同步方法、装置及***

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5195091A (en) * 1991-07-09 1993-03-16 At&T Bell Laboratories Adaptive synchronization arrangement
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
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 (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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 (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013079365A1 (fr) * 2011-11-30 2013-06-06 Continental Automotive Gmbh Procédé de synchronisation d'horloges dans des nœuds d'un réseau de bord d'un véhicule automobile et nœud configuré pour la mise en œuvre du procédé
US9331838B2 (en) 2011-11-30 2016-05-03 Continental Automotive Gmbh Method for synchronizing clocks in nodes of a vehicle network and node designed to perform the method
EP3706340A1 (fr) 2011-11-30 2020-09-09 Continental Automotive GmbH Procédé de synchronisation d'horloges dans des n uds d'un réseau de véhicules et de mise en uvre du procédé de configuration des n uds
EP3166242A1 (fr) * 2015-11-05 2017-05-10 Robert Bosch Gmbh Contrôle de synchronisation d'horloge dans un réseau ethernet
CN107046450A (zh) * 2015-11-05 2017-08-15 罗伯特·博世有限公司 基于以太网的网络中的时钟同步监测
CN113824523A (zh) * 2015-11-05 2021-12-21 罗伯特·博世有限公司 基于以太网的网络中的时钟同步监测
CN109450582A (zh) * 2018-11-01 2019-03-08 百度在线网络技术（北京）有限公司 传感器时间戳同步测试方法、装置、设备、介质及车辆
CN114124276A (zh) * 2020-08-31 2022-03-01 华为技术有限公司 一种分布式***中的时钟同步方法、装置及***

Also Published As

Publication number Publication date
WO2006044139A3 (fr) 2006-08-10

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
EP3016306B1 (fr) Procédé et appareil permettant de réaliser une synchronisation temporelle de réseau embarqué à l'aide d'un grand maître redondant
US7599377B2 (en) System and method for tunneling standard bus protocol messages through an automotive switch fabric network
US11251891B2 (en) Method for identifying an incorrect time stamp of an ethernet message and control unit for a motor vehicle
US7324892B2 (en) Parameter coordination in a vehicular communication network
JP3539349B2 (ja) 通信装置
EP2822228B1 (fr) Appareil de réseau industriel et procédé de communication de données
US20040213295A1 (en) Method and apparatus for time synchronizing an in-vehicle network
US7721030B2 (en) Method and device for connecting sensors or actuators to a bus system
JP2008113457A (ja) 多数のバスのサイクルタイムを同期させる方法と装置及び対応するバスシステム
WO2006044122A2 (fr) Systeme et procede de diffusion en continu de donnees sequentielles a travers un reseau a matrice de commutation d'automobile
US11546074B2 (en) Clock topology in an ethernet network
EP3827562A1 (fr) Découverte de topologie dans un réseau ethernet automobile
JP2000224213A (ja) 通信ネットワーク、および該通信ネットワークを構成するマスタ装置、スレーブ装置、多重化装置、並びに交換装置
WO2006044140A2 (fr) Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile
WO2006044139A2 (fr) Systeme et procede de synchronisation temporelle de noeuds dans un reseau automobile au moyen d'une saisie d'entree
JPH11234318A (ja) クロック再生装置
US11094187B2 (en) Sum stream for actual states and control signals of a distributed control system
CA2943875A1 (fr) Methode de communication de donnees asynchrones dans un reseau de donnees ethernet fonctionnel en temps reel
CN101795191B (zh) 电子的数据处理***的两个通信网络的同步
JP4524932B2 (ja) リング型ネットワークにおけるノード間のタイミング同期方法、及びそのノード
JP2008022158A (ja) 車載データベース分配ノード、電子制御ユニットおよび車載データベースシステム
KR101156097B1 (ko) 이더넷 파워링크에서의 마스터 이중화 방법

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