EP1632062A1 - Vehicle network and method of communicating data packets in a vehicle network - Google Patents
Vehicle network and method of communicating data packets in a vehicle networkInfo
- Publication number
- EP1632062A1 EP1632062A1 EP04754993A EP04754993A EP1632062A1 EP 1632062 A1 EP1632062 A1 EP 1632062A1 EP 04754993 A EP04754993 A EP 04754993A EP 04754993 A EP04754993 A EP 04754993A EP 1632062 A1 EP1632062 A1 EP 1632062A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- network
- communication
- configuration state
- network elements
- vehicle
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
- 238000000034 method Methods 0.000 title claims description 26
- 238000004891 communication Methods 0.000 claims abstract description 90
- 230000008878 coupling Effects 0.000 claims abstract description 5
- 238000010168 coupling process Methods 0.000 claims abstract description 5
- 238000005859 coupling reaction Methods 0.000 claims abstract description 5
- 239000004744 fabric Substances 0.000 claims description 8
- 230000008859 change Effects 0.000 claims description 6
- 230000001902 propagating effect Effects 0.000 claims 2
- 230000008569 process Effects 0.000 description 16
- 230000006870 function Effects 0.000 description 10
- 241001417501 Lobotidae Species 0.000 description 6
- 239000006163 transport media Substances 0.000 description 6
- 238000005516 engineering process Methods 0.000 description 4
- 238000012546 transfer Methods 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 235000008694 Humulus lupulus Nutrition 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 239000002609 medium Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 239000000725 suspension Substances 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 230000007723 transport mechanism Effects 0.000 description 1
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
- 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
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/04—Interdomain routing, e.g. hierarchical routing
-
- 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
Definitions
- the present patent relates to vehicles and particularly to communication networks within vehicles.
- Control of the devices in the vehicle to implement desired features may be divided into controllers by function (powertrain, braking, steering, etc.), by location (engine compartment, seat, door, etc.) or in combinations thereof.
- the controller for each of the functions/zones may share information with other controllers using a shared-access serial bus.
- the bus usually follows an industry standard such as J1850, CAN, LIN, Flexray, MOST and the like, well known to those of skill in the art. Multiple, independent busses may be used. In that case, one of the controllers may act as a gateway for information between the incompatible busses.
- An alternative architecture introduces the idea of dividing the vehicle into geographic regions and locating a single controller for all of the features in that region.
- This architecture may also include the concept of smart peripherals to reduce the number of interconnections in localized areas of the vehicle.
- the smart peripherals use simple serial communication busses such as LIN busses to relay information from sensors to the zone controller or to accept actuator commands from the zone controller.
- the zone controllers may be linked by a serial communication bus structure.
- junction block that can be located in various zones of the vehicle.
- the junction block provides a mechanical and electrical connection point for power, ground and communication for small devices that are used to interface between input and output devices.
- the junction block also provides over current protection devices for the small connected devices, and multiple power sources distributed at different levels within the system.
- FIG. 1 is a schematic representation of a vehicle incorporating a vehicle network.
- FIG. 2 is a schematic representation of a switch fabric forming a portion of a vehicle network.
- FIG. 3 is a schematic representation of a switch fabric forming a portion of a vehicle network and further illustrating communication paths within the network.
- FIG. 4 is a schematic representation of a switch fabric forming a portion of vehicle network and further illustrating disparate communication links.
- FIG. 5 is a block diagram of a network element that may be used in the networks shown in FIGs. 1-4.
- FIG. 6 is a schematic representation of a data packet.
- FIGs. 7-12 are schematic diagrams illustrating a network node discovery process that may be used with the networks illustrated in FIGs. 1-4. Detailed Description
- FIG. 1 illustrates a vehicle 100 including a network 102 to which various vehicle devices 104-110 are coupled.
- the devices may be sensors, actuators, processors and the like used in connection with various vehicle functional systems and sub-systems, such as, but not limited to, control-by- wire applications for throttle, braking, steering and suspension control, power accessories, communications, entertainment, and the like.
- the vehicle devices 104-110 may be coupled by interfaces 112-118, which may be any suitable interface for coupling the particular device to the network 102, and may be wire, optical, wireless or combinations thereof. It should be understood, however, that the interfaces are not required elements and that the devices 104-110 may be directly coupled to the network or may form portions of the network.
- the vehicle devices 104-110 may be adapted to provide one or more functions associated with the vehicle 100. These devices may be data producing, such as a sensor, data consuming, such as an actuator, processing or other devices, which both produce and consume data, or routing that transport data within the network. Of course, 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 device, and carried by the network 102, is independent of the function of the device itself. That is, the interfaces 112-118 may provide device independent data exchange between the coupled device and the network 102.
- the network 102 includes a switch fabric 130 defining a plurality of communication paths 132 between the devices.
- the communication paths permit multiple simultaneous peer-to-peer or point-to-point, one-to-many, many-to-many, etc. data packet communication between the devices 104- 110.
- data exchanged, for example, between devices 104 and 110 may utilize any available path or paths between the devices.
- a single path through the switch fabric 130 may carry all of the data packets representing a communication between the device 104 and the device 110, or several communication paths may carry portions of the data packets. Subsequent communications may use the same paths or other paths as dictated by the then state of the network 102.
- the network 102 is a packet data network which may comply with a transmission control protocol/Internet (TCP/IP), asynchronous transfer mode (ATM), Infiniband, RapidlO, or any other packet data protocol now known or later developed. It may also include bus structures that are operated in a packet transit mode, as will be described herein later. As such, the network 102 may use data packets, having fixed or variable length, defined by one or more applicable protocols.
- TCP/IP transmission control protocol/Internet
- ATM asynchronous transfer mode
- Infiniband Infiniband
- RapidlO RapidlO
- the network 102 may use data packets, having fixed or variable length, defined by one or more applicable protocols.
- the network 102 uses asynchronous transfer mode (ATM) communication protocol
- ATM asynchronous transfer mode
- the devices 104-110 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 J1850, CAN, LIN, Flexray, MOST or similar bus structures.
- legacy bus architectures such as J1850, CAN, LIN, Flexray, MOST or similar bus structures.
- the respective interface 112-118 may be configured as a proxy or gateway to permit communication between the active network 102 and the legacy device 104-110.
- FIG. 2 illustrates a network 200 that includes a plurality of network elements 202-212 communicatively coupled by communication links 214-230.
- a plurality of devices 238-250 are coupled at various locations, i.e., to several of the network elements 202-212 of the network 200 by corresponding communication links (not separately identified).
- the devices may be any vehicle device such as flashers 238-244, flasher control (stalk switch) 246, gas pedal 248, one or more gauges such as gauge 250 and the like.
- the communication links 214-230 may be robust transport media and may be adapted from serial communication architecture as will be described. That is, the communication links 214-230 may be capable of providing guaranteed, reliable message transfer between the network elements.
- Any given communication link 214-230 may be a single bi-directional link, a single uni-directional link or combinations of bi-directional and uni-directional links or any combination of link technologies.
- the links may be defined according to an existing, robust transport mechanism designed for the automotive environment such as CAN, LIN, FLEXRAY, J1850, and the like or may be defined according to transport protocols in development or that are later developed.
- the links may also be combinations of technologies, or specified in accordance with virtually any other protocol.
- the network 200 may incorporate at some level a system management function providing supervision, control, diagnostics and other related functionality. This functionality may be provide by way of a separate entity coupled to the network 200, or the functionality may be distributed within the network elements 202-212 or other suitable elements of the network 200.
- FIG. 3 illustrates the flexibility provided by the network 200. As an example of this flexibility, consider the task of communicating a signal from the flasher control 246 to the flasher 240.
- the network 200 is a packet based network, and permits any available communication path from a source point to a destination point to be used regardless of the communication media. As shown in FIG.
- the signal from the flasher control 246 may traverse a relatively direct path 302 between the flasher control 246 defined by the network elements 206 and 204 and the communication link 222 joining them.
- a path 304 via the network elements 206, 202 and 204 and the communication links 218 and 214 joining them may be used.
- Still a further path 306 via the network elements 206, 210, 212 and 204 and the communication links 224, 228 and 216 may be used.
- numerous communication paths may be defined.
- the availability of multiple paths allows the network to manage traffic to avoid congestion on one or more of the communication links 214-232 or at one or more of the network elements 202-212.
- the availability of multiple communication paths also permits fault tolerance in the event of failure of one or more network elements and/or communication links by permitting a communication path to be established bypassing the failed elements/links.
- a network 400 includes a plurality of network elements 402-412 communicatively coupled by communication links 414-430.
- a plurality of devices 438-450 are coupled at various locations, i.e., to several of the network elements 402-412 of the network 400 by corresponding communication links (not separately identified).
- Legacy devices 452-458 i.e., devices adapted to communicate according to existing communication protocols such as J1850, CAN, LIN, Flexray, MOST and the like, are also coupled to the network 400.
- devices 452 and 454 illustrated as door switches, may be coupled to network elements 402 and 404, respectively, by J1850 communication links 460 and 462.
- Devices 456 and 458, in this example door locks may be coupled to network elements 410 and 412, respectively, by CAN communication links 464 and 466.
- any of the communication links may be specified according to any suitable, preferably robust transport protocol.
- communication link 414 and 416 may be specified according to CAN protocol, while the remaining links may be specified according to TCP/IP, CAN, LIN, Flexray, and the like.
- the network element 500 in FIG. 5 includes operationally coupled one or more input/output ports, one shown as port 502, a processor 504 and a memory 506.
- the memory 506 incorporates a control program (not depicted) to direct the processor to function in a manner that facilitates communication of data packets through the associated network.
- the input/output port 502 is adapted to be coupled to the communication links to send and receive data packets from the network element 500. Because the network element 500 may be coupled to more than one transport media type, the processor operates in accordance with the control program to accept data packets sent via a first transport media, to modify the data packets as necessary for communication via a second transport media and to communicate the data packets over the second transport media.
- the network element may act as a proxy or gateway between the disparate communication media. It will be appreciated that alternate network elements may be used with enhanced functionality or simplified functionality as the application requires. For example, should the network element join connection links according to a single protocol, the processing capability for handling disparate protocols may not be required, and such a network element may be adapted to merely route the data packet according to the route information associated with the data packet.
- a data packet used for communication within the networks described herein may include a packet type identifier, routing information, source ID information, QoS information and payload. Illustrated in FIG. 6 is an exemplary data packet 600 that may be used in the networks.
- the data packet 600 may include a start of frame field 602, an arbitration field 604, a control field 606, a data field 608, a cyclical-redundancy check field 610 and an end of frame field 612.
- the arbitration field 604 may be adapted to contain a packet type identifier 614, a route pointer 616, port identifiers 618, 620 and 622, a source node identifier 624 and a priority tag 626.
- the packet type 614 identifies the type of data packet such as bearer, discovery, advertisement, fault, control and the like.
- the route pointer 616 if the data packet contains route information, points to the current hop and is decrement with each hop.
- the route pointer 616 may also contain other types of route information.
- the port identifiers 618-622 identify the ports, e.g., network elements, the data packet has traversed.
- the source node 624 identifies the information source.
- the priority tag 626 may be reserved for QoS requirements and may contain a code identifying a service level for the data packet.
- the control field 606 may contain control data particular to the transport media, e.g., it may contain CAN control data if the data packet originated from or is destined for a CAN compliant communication device.
- the data field 608 contains the data carried by the packet, i.e., the payload.
- the data packet 600 may be adapted to facilitate source routing, i.e., the route the data packet will take through the network is determined by the information source and this path information is contained within the data packet itself.
- the data packet 600 may also be adapted to facilitate destination routing, i.e., the route the data packet will take through the network is determined by each intermediate node and the next node information is contained within the data packet.
- the data packet 600 may be adapted from known communication packet structures, such as a CAN data packet.
- the arbitration field 604 is adapted to facilitate communication of data packets within the network 400 according to a number of different serial communication protocols.
- the arbitration field may also be adapted to contain routing information for communicating the data packet 600 through the network 400, i.e., information may be contained within the route pointer 616 field or otherwise contained within the arbitration filed 604.
- the routing information may be a fixed label which remains with the data packet throughout the network 400.
- Each network element of the network 400 then includes a table to direct the data packet through the network 400 according to the label.
- the packet may be source routed, and the arbitration field may then contain routing information for each hop through the network.
- the data packet 600, and particularly the arbitration information is modified at each hop so that it contains information for the next hop.
- other fields of the data packet 600 may be used to carry routing information, QoS information, or other types of information.
- the networks 200 and 400 may be implemented into existing applications by adapting the communication links 214-232 from existing robust communication medium.
- the communication links 214-232 may be specified according to the CAN protocol.
- the communication links 214-232 may be specified according to the LIN, Flexray, J1850, MOST or other protocols.
- the communication links 414-432 may be specified according to any suitable protocol such as CAN, LIN, Flexray, J 1850, MOST and the like.
- Each of these protocols may define an arbitration mechanism to provide for and permit flow control. Arbitration may be specified to give priority on the communication link to a message with the highest priority.
- Priority may be indicated within a data packet in a message header, such as the priority tag 626 of the data packet 600.
- the message header may contain zeros in the most dominant bits. If two network elements try to transmit on the same communication link at the same time, the message with the highest priority, e.g., the lowest value in the dominant bits, will win and the all others will release the communication link.
- node On initial startup of a network according to the embodiments described herein, such as networks 200 and 400, it necessary to identify all nodes of the network.
- the term "node” may refer to network elements, including but not limited to those network elements described in connection with networks 200 and 400, switches, routers and any and all coupled devices.
- the network may offer nodes capable of multicast, encryption or other capabilities. Nodes may be configured to receive information or to advertise availability of information. Discovery processes are known in connection with networks, and the commonly used Dijkstra algorithm may be employed to complete a network discovery process and calculate the routing table.
- Networks according to the embodiments described herein generally are not totally dynamic. Generally, the network only becomes dynamic upon detecting a failure, i.e., the network is not dynamic until something goes wrong, or when new hardware is added to the network. Therefore, a last known state of the network may be saved and an incremental discovery process may be employed upon detecting a network change. The incremental discovery process may be completed with little or no effect on overall network performance.
- FIGs. 7-12 illustrate one example of an incremental discovery process that may be used with networks such as those described herein.
- the example shown in FIG. 7-12 is intended to illustrate one possible type of incremental discovery process, and it should be appreciated that alternatives to the specific example described may be used.
- each node upon power up each node is configured to send a "Hello" message to all of its immediate neighbors on all ports coupled to the node.
- node 01 sends a hello message to each of nodes 02, 03, 05 and 07.
- the nodes 01 , 02, 03, 05 and 07 may be configured in a manner similar to that illustrated in FIG. 5, wherein the node may include an input/output port, a processor or some minimum form of intelligence to enable sending and receiving hello messages and comparing neighbor tables and a memory, in which its node number, a neighbor table and other routing information may be stored.
- the hello message may contain the node number and a copy of the node's local neighbor table.
- the node will continue to send these local, i.e.,1- hop, hello messages every N seconds, where N is an arbitrarily selected value such that the network is not burdened with hello messages but which is sufficiently frequent to allow early detection of network changes or potential failures.
- N is an arbitrarily selected value such that the network is not burdened with hello messages but which is sufficiently frequent to allow early detection of network changes or potential failures.
- N is an arbitrarily selected value such that the network is not burdened with hello messages but which is sufficiently frequent to allow early detection of network changes or potential failures.
- transmission error interrupts generated by the physical layer, e.g., "bus off' error, as is well known.
- a node Whenever a node receives a hello message from a neighbor, it looks at its local neighbor table to see if anything has changed, i.e., to see if there is a new neighbor sending to it a hello message.
- the network is initialized, which may occur during initial assembly of the vehicle but may occur at other times, there is no routing information stored. That is, each node's neighbor table is blank, and therefore, the nodes will notice something changing with each hello message received and processed.
- the receiving node Upon receipt of a hello message from a node at a port for which information is not stored in the local neighbor table, the receiving node updates its local neighbor table to include this information. As illustrated in FIG. 8, the node 02 updates its local neighbor table 900 to indicate that node 01 is connected at port 2.
- Nodes 02, 03, 05 and 07 also send hello messages that are received by node 01 as shown in FIG. 9. Receipt of these hello messages allows node 01 to generate its own local neighbor table 1000. Through this process of the nodes sending hello messages, each node is able to generate its local neighbor table.
- node On a normal start up, with a last-known-good local table stored in the node's memory, the node will be able to start effectively communicating immediately. Any network changes will begin to filter throughout the network as nodes discover new/missing neighbors and start broadcasting new neighbor tables (FIGs. 10 and 11 ).
- the node When there is a change in a node's neighbor table, the node then broadcasts its neighbor table for receipt by each other node in the network. Broadcasting of the neighbor tables allows the nodes to generate and store routing tables 1300 as shown in FIG. 12. Given all of the neighbor tables, generally shown as neighbor tables 1302 in FIG. 12, each node may then determine all of the node in the network 1304 and the number of hops 1306 required to reach each other nodes and the intermediary nodes 1308, 1310, 1312 that make up a path to the particular node.
- the discovery process may also include periodic checking to determine a status or health of the network. For example, a node may fail to receive a broadcast message containing a node's new neighbor table according to the process described above. This node may become effectively out of sync with the rest of the network until such time as it receives the broadcast message and is able to update its local neighbor table. For this reason, each node may be configured to periodically broadcast a packet containing a checksum for its neighbor table, from which each node is able to verify consistency. The check sum may be sent with other message traffic so that it does not consume bandwidth within the network.
- Synchronization may also become an issue in a fault condition.
- a fault condition may initiate a flurry of rediscovery activity, and it is possible as a result that a node may receive updates out of sequence, i.e., a less up to date table may arrive after the true latest table.
- Time stamping may be employed to guarantee each node has the latest information.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mechanical Engineering (AREA)
- Small-Scale Networks (AREA)
Abstract
Description
Claims
Applications Claiming Priority (5)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US47789703P | 2003-06-12 | 2003-06-12 | |
US10/464,320 US7272496B2 (en) | 2003-06-12 | 2003-06-18 | Vehicle network and method of communicating data packets in a vehicle network |
US10/463,988 US7570597B2 (en) | 2003-06-12 | 2003-06-18 | Discovery process in a vehicle network |
US10/464,387 US6934612B2 (en) | 2003-06-12 | 2003-06-18 | Vehicle network and communication method in a vehicle network |
PCT/US2004/018587 WO2004112332A1 (en) | 2003-06-12 | 2004-06-10 | Vehicle network and method of communicating data packets in a vehicle network |
Publications (2)
Publication Number | Publication Date |
---|---|
EP1632062A1 true EP1632062A1 (en) | 2006-03-08 |
EP1632062A4 EP1632062A4 (en) | 2006-12-20 |
Family
ID=33556635
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP04754993A Withdrawn EP1632062A4 (en) | 2003-06-12 | 2004-06-10 | Vehicle network and method of communicating data packets in a vehicle network |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP1632062A4 (en) |
KR (1) | KR100768418B1 (en) |
WO (1) | WO2004112332A1 (en) |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR100786814B1 (en) * | 2006-02-16 | 2007-12-18 | 주식회사 오토전자 | Integrated network system for automobile and gateway therefor |
US9373149B2 (en) | 2006-03-17 | 2016-06-21 | Fatdoor, Inc. | Autonomous neighborhood vehicle commerce network and community |
KR100752771B1 (en) * | 2006-04-27 | 2007-08-29 | 주식회사 팬택 | Intelligent communication system for intelligently determining priority of communication media |
KR101251371B1 (en) * | 2006-06-08 | 2013-04-05 | 현대자동차주식회사 | Flexray-CAN Gateway Structure and Message Mapping Method |
KR100802732B1 (en) * | 2006-10-25 | 2008-02-12 | 현대자동차주식회사 | A fot connecter structure for a most network |
KR101243372B1 (en) * | 2011-01-20 | 2013-03-13 | 전자부품연구원 | Node discovery method in MOST communication |
KR101500094B1 (en) | 2013-07-01 | 2015-03-06 | 현대자동차주식회사 | Message transmission/reception system and method for ethernet-based vehicle network |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5794164A (en) * | 1995-11-29 | 1998-08-11 | Microsoft Corporation | Vehicle computer system |
US6430164B1 (en) | 1999-06-17 | 2002-08-06 | Cellport Systems, Inc. | Communications involving disparate protocol network/bus and device subsystems |
US6356823B1 (en) * | 1999-11-01 | 2002-03-12 | Itt Research Institute | System for monitoring and recording motor vehicle operating parameters and other data |
US6885916B2 (en) * | 2001-08-31 | 2005-04-26 | Motorola, Inc. | Data packet for a vehicle active network |
-
2004
- 2004-06-10 KR KR1020057023820A patent/KR100768418B1/en not_active IP Right Cessation
- 2004-06-10 WO PCT/US2004/018587 patent/WO2004112332A1/en active Application Filing
- 2004-06-10 EP EP04754993A patent/EP1632062A4/en not_active Withdrawn
Non-Patent Citations (2)
Title |
---|
No further relevant documents disclosed * |
See also references of WO2004112332A1 * |
Also Published As
Publication number | Publication date |
---|---|
KR100768418B1 (en) | 2007-10-18 |
KR20060010834A (en) | 2006-02-02 |
WO2004112332A1 (en) | 2004-12-23 |
EP1632062A4 (en) | 2006-12-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7272496B2 (en) | Vehicle network and method of communicating data packets in a vehicle network | |
US7733841B2 (en) | Vehicle network with time slotted access and method | |
US6747365B2 (en) | Vehicle active network adapted to legacy architecture | |
US7027387B2 (en) | Vehicle active network with data redundancy | |
US7170853B2 (en) | Vehicle active network topologies | |
US6885916B2 (en) | Data packet for a vehicle active network | |
US20080192772A1 (en) | Low-Weight Hybrid Deterministic Highspeed Data Bus | |
US10375151B2 (en) | Method for operating a gateway in a hierarchical heterogeneous network by comparing offer messages and search messages received at the gateway regarding a service to determine if the messages relate to the same service and forwarding search messages that do not relate | |
WO2003021898A1 (en) | Vehicle active network with redundant devices | |
EP1425884A1 (en) | Vehicle active network using multiple communication paths | |
WO2005114434A1 (en) | Vehicle network with interrupted shared access bus | |
WO2003021867A2 (en) | Linked vehicle active networks | |
KR19990077415A (en) | Network system | |
WO2021005875A1 (en) | On-vehicle communication system, on-vehicle device, and vehicle communication method | |
KR100768418B1 (en) | Vehicle network and method of communicating data packets in a vehicle network | |
US20030045234A1 (en) | Vehicle active network with reserved portions | |
CN113892247A (en) | Relay device, vehicle, communication method, and communication program | |
WO2022255069A1 (en) | On-board communication device, on-board relay device, on-board communication system, and communication method | |
US20200296165A1 (en) | Method and device for operating a communication system | |
JP4297378B2 (en) | Bridge, transmitter, and information system | |
Yang et al. | Routing schemes for switch-based in-vehicle networks | |
KR101458625B1 (en) | A fault tolerant method for Ethernet backbone network and system using the method | |
Kim et al. | A method for improving the reliability of the gateway system by using OSEK and duplication scheme |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20051212 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): DE FR GB |
|
DAX | Request for extension of the european patent (deleted) | ||
RBV | Designated contracting states (corrected) |
Designated state(s): DE FR GB |
|
A4 | Supplementary search report drawn up and despatched |
Effective date: 20061117 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: CONTINENTAL AUTOMOTIVE SYSTEMS, INC. |
|
17Q | First examination report despatched |
Effective date: 20150212 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: EXAMINATION IS IN PROGRESS |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20161129 |