KR20060010834A - Vehicle network and method of communicating data packets in a vehicle network - Google Patents

Abstract

A vehicle communication network (200) includes a plurality of network elements (202-212) and a plurality of communication links (214-230) communicatively coupling the network elements in a point-to-point configuration. At least a portion of the plurality of communication links are specified in accordance with a shared-access bus protocol. The plurality of communication links are arranged to communicate data packets between the network elements, and data packets are modified for transport via the plurality of communication links.

Description

VEHICLE NETWORK AND METHOD OF COMMUNICATING DATA PACKETS IN A VEHICLE NETWORK}

Cross-Reference of Related Applications

This application claims the benefit of Provisional Patent Application No. 60 / xxx, xxx, filed June 12, 2003, under 35 U.S.C §119 (e), the disclosure of which is expressly incorporated herein by reference.

The present invention relates to vehicles and, more particularly, to communication networks in vehicles.

Vehicle manufacturers have used serial communication (multiplexing) between controllers to share information and distribute control for some time. This greatly reduces the amount of vehicle signal wiring required to implement the comfort, convenience, and safety features required of modern consumer vehicles.

The control of the vehicle devices to implement the desired features can be divided into controllers by function (power transmission device, braking, steering, etc.), location (engine accessories, seats, doors, etc.) or combinations thereof. The controller for each of the functions / zones may share information with other controllers using a shared-access serial bus. The bus generally follows industry standards such as J1850, CAN, LIN, Flexray, MOST and the like, which are well known to those skilled in the art. Multiple independent buses may be used. In that case, one of the controllers can act as a gateway for information between incompatible buses.

An alternative architecture introduces the idea of dividing the vehicle into geographic areas and placing a single controller for all features in that area. 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 buses, such as LIN buses, to relay information from the sensors to the zone controller, or to accept actuator commands from the zone controller. The zone controllers can be linked by a serial communication bus structure.

Another alternative architecture includes a junction block that can be located in various zones of the vehicle. The junction block provides a mechanical and electrical connection point for power, grounding and communication to a small device used to interface between input and output devices. The junction block also provides current protection devices for small connection devices and multiple power supplies distributed at different levels within the system.

Current bus protocols are not easily scalable and are limited in bandwidth. X-by-wire functionality, multimedia infotainment, navigation, and other content-intensive applications provide significant improvements in bandwidth, speed, latency, jitter, defect errors, message integration, guaranteed delivery, usability, and survivability. Will require more quality of service (QoS) and bandwidth.

Thus, for an automotive environment that provides scalable scalability of capacity and redundancy at the same cost as existing bus architectures, new architectures such as switch fabric network architectures are required.

This disclosure will describe some embodiments that illustrate their broad implications. Reference is also made to the accompanying drawings.

1 is a schematic representation of a vehicle including a vehicle network.

2 is a schematic illustration of a switch fabric forming part of a vehicle network.

3 is a schematic diagram of a switch fabric forming part of a vehicle network and further illustrating communication paths within the network.

4 is a schematic diagram of a switch fabric forming part of a vehicle network and further illustrating heterogeneous communication links.

5 is a block diagram of a network element that may be used in the network shown in FIGS.

6 is a schematic diagram of a data packet.

7-12 are schematic diagrams illustrating a network node discovery process that may be used with the networks shown in FIGS.

The following description refers to a detailed description of a number of other embodiments of the invention, but it should be understood that the legal scope of the invention is defined by the words of the claims set forth at the end of this patent. Since the description of all possible embodiments is not substantial, the detailed description is to be construed as illustrative only and does not describe all possible embodiments of the present invention. Many alternative embodiments may be implemented using techniques developed after the filing date of this patent, which still falls within the scope of the present technology or claims that define the invention. In addition, the structures, features, and functions of the embodiments described herein are considered to be interchangeable, and all structures, features, or functions may be used with any of the embodiments described herein.

Also, as the term is used herein, the term ' The phrase "is defined to mean .." or similar phrases is intended to limit the meaning of the term clearly or implicitly beyond its ordinary or ordinary meaning, unless expressly limited to this patent. It is to be understood that such terms are not to be construed as limited to the scope based on any description set forth in any section (other than the language of the claims) of this patent. As long as is referenced in this patent in a manner consistent with a single meaning, it is described for clarity only so as not to confuse the reader, and such claims are not intended to be limited to a single meaning by implicit or otherwise.

1 shows a vehicle 100 including a network 102 to which various vehicle devices 104-110 are coupled. The devices include various vehicle functional systems such as throttle, braking, steering and suspension control, power accessories, communications, entertainment, and the like, and control-by-wire applications. Sensors, actuators, processors, and the like, used in conjunction with sub-systems, but are not limited to these. The vehicle devices 104-110 may be any suitable interface for coupling a particular device to the network 102, and may be wires, optical, wireless, or combinations thereof. Can be combined. However, it is to be understood that the interface is not a required element and that the devices 104-110 may be directly coupled to the network or form parts of the network. The vehicle devices 104-110 may be adapted to provide one or more functions associated with the vehicle 100. These devices can generate data like sensors, consume data like actuators, handle the generation and consumption of data, or route data within the network. Of course, the actuator, generally a data-consuming device, may also generate data for generating data indicating, for example, that the actuator has achieved a command state, or for example providing instructions for a function. In that case, the sensor may consume data. The data generated by or provided to the device and carried by the network 102 is independent of the function of the device itself. That is, the interfaces 112-118 may provide a device independent of data exchange between the combined device and the network 102.

Network 102 includes a switch fabric 130 that defines a number of communication paths 132 between devices. Communication paths are multiple simultaneous peer-to-peer or point-to-point, one-to-many between the devices 104-110. to-many, many-to-many, etc. data packet communication. During operation of the vehicle 100, for example, data exchanged between the devices 104 and 110 may use any available path or paths between the devices. In operation, a single path through the switch fabric 130 may carry all data packets representing communication between device 104 and device 110, or some communication paths may carry portions of data packets. . Subsequent communications may use the same paths or other paths indicated by the next state of the network 102. This flexibility provides reliability and speed advantages over bus architectures that are limited to single communication paths between devices, so failure of a single path or delays based on the path's congestion results in failure. In addition, communications between other of the devices 104-110 may occur simultaneously using communication paths within the switch fabric 130.

Network 102 is a packet that may conform to Transmission Control Protocol / Internet (TCP / IP), Asynchronous Transmission Mode (ATM), Infiniband, RapidIO, or any other packet data protocol now known or developed in the future. Data network. It may also include a bus structure that operates in a packet transfer mode, as described herein after. As such, network 102 may use data packets having a fixed or variable length and defined by one or more applicable protocols. For example, if the network 102 uses an asynchronous transfer mode (ATM) communication protocol, an ATM standard data cell can be used.

The devices 104-110 need not be separate devices. Instead, the devices may be systems or subsystems of a vehicle, and employ one or more legacy communication media, i.e., legacy bus architecture such as J1850, CAN, LIN, Flexray, MOST or similar bus structures. It may include. In such embodiments, each interface 112-118 may be configured as a proxy or gateway to allow communication between the active network 102 and the legacy device 104-110.

2 shows a network 200 that includes a number of network elements 202-212 that are communicatively coupled by communication links 214-230. Multiple devices 238-250 are coupled to some of the network elements 202-212 of network 200 by various locations, that is, corresponding communication links (not separately distinguished). Such devices may include flashers 238-244, flasher control (stalk switch) 246, gas pedal 248, one or more gauges such as gauge 250, and the like. It may be any vehicle device.

Communication links 214-230 may be a powerful transport medium and may be adapted from a serial communication architecture as described. That is, communication links 214-230 may provide guaranteed and reliable message delivery between network elements. Any given communication link 214-230 may be a single bidirectional link, a single unidirectional link or combinations of bidirectional and unidirectional links, or any combination of link technologies. The links can be defined according to existing powerful delivery mechanisms designed for automotive environments such as CAN, LIN, FLEXRAY, J1850, etc., or in accordance with delivery protocols under development or to be developed in the future. The links may also be specified according to any other protocol or combinations of techniques.

The network 200 may include system management functions that provide supervision, control, diagnostics, and other related functionality at some level. This functionality may be provided by a separate entity coupled to the network 200 or may be distributed within the network elements 202-212 or other suitable elements of the network 200.

3 illustrates the fluidity provided by the network 200. As an example of this flexibility, consider a task of communicating a signal from flasher control 246 to flasher 240. The network 200 allows any available path from the source point to the target point to be used independently of the communication medium. As shown in FIG. 3, the signal from the flasher control 246 is a relatively direct path between the flasher control 246 defined by the network elements 206 and 204 and the communication link 222 joining them. Pass 302). Alternatively, path 304 through network elements 206, 202, and 204 and the communication links 218 and 214 that join them may be used. Another path 306 through the network elements 206, 210, 212 and 204 and the communication links 224, 228, and 216 can be used. As this example, multiple communication paths can be defined. The availability of multiple paths allows the network to manage traffic to avoid congestion on one or more communication links 214-232 or on one or more network elements 202-212. The availability of multiple communication paths allows a communication path for bypassing failed elements / communications, thereby allowing for a failure tolerance on failure of one or more network elements and / or communication links.

Referring now to FIG. 4, network 400 includes a number of network elements 402-412 communicatively coupled by communication links 414-430. The multiple devices 438-450 are coupled to some of the network elements 402-412 of the network 400 by various locations, that is, corresponding communication links (not separately distinguished). Legacy devices 452-458, that is, devices adapted to communicate in accordance with existing communication protocols such as J1850, CAN, LIN, Flexray, MOST, etc., are also coupled to the network 400. For example, devices 452 and 454, shown as door switches, may be coupled to network elements 402 and 404 by J1850 communication links 460 and 462, respectively. Devices 456 and 458, in this example door locks, may be coupled to network elements 410 and 412 by CAN communication links 464 and 466, respectively. In addition, any communication links may be designated in accordance with any suitable, preferably strong delivery protocol. As shown in FIG. 4, communication links 414 and 416 may be designated according to the CAN protocol, while the remaining links may be designated according to TCP / IP, CAN, LIN, Flexray, and the like.

The structure of the network elements may be as shown in FIG. Network element 500 of FIG. 5 includes one or more input / output ports operatively coupled, one of which is shown as port 52, processor 504, and memory 506. Memory 506 includes a control program (not shown) that directs the processor to function in a manner that facilitates communication of data packets over an associated network. Input / output port 502 is adapted to couple to the communication links to send and receive data packets from network element 500. Since network element 500 may be coupled to one or more types of delivery media, the processor may receive data packets transmitted over the first delivery medium, modify the data packets needed for communication via the second delivery medium, Operates in accordance with a control program for communicating data packets via a second delivery medium. As such, the network element may act as a proxy or gateway between heterogeneous communication media. It should be appreciated that alternative network elements may be used with improved or simplified functionality as required by the application. For example, if a network element must combine connection links according to a single protocol, processing power for handling heterogeneous protocols may not be required, and such network element may only require a data packet in accordance with the route information associated with the data packet. It can be adapted to route.

The 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. Shown in FIG. 6 is an example data packet 600 that can be used in networks. The data packet 600 includes the start of the frame field 602, the adjustment field 604, the control field 606, the data field 608, the cyclical redundancy check field 610 and the frame field 612. May contain an end. The coordination field 604 may be applied to include 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. have. Packet form 614 identifies the type of data packet, such as delivery, discovery, advertisement, defect, control, and the like. If the data packet contains route information, route pointer 616 points to the current hop and decrements with each hop. Route pointer 616 may also include other forms of route information. Port identifiers 618-622 identify the ports through which the data packet passed, eg, network elements. Source node 624 identifies the information source. Priority tag 626 may be reserved for QoS prerequisites and may include a code that identifies a service level for a data packet. The control field 606 may include control data specific to the transmission medium and may include CAN control data, for example, if the data packet originates from or directed to a CAN compliant communication device. Data field 608 contains packets, ie data carried by the payload.

The data packet 600 may be adapted to facilitate source routing, ie, the route that the data packet will take over 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 target routing, ie, the route that the data packet will take over the network is determined by each intermediate node, and the next node information is included in the data packet.

Data packet 600 may be adapted from known communication packet structures, such as a CAN data packet. As shown in FIG. 6, the coordination field 604 is adapted to facilitate communication of data packets within the network 400 in accordance with a number of different serial communication protocols. The coordination field may also be adapted to include routing information for communicating the data packet 600 via the network 400, that is, the information may be included in the route pointer 616, or else in the coordination field 604. ) May be included. For example, the routing information may be a fixed label that remains as a data packet through the network 400. Each network element of network 400 includes a table that directs data packets through network 400 according to the label. Alternatively, the packet may be source routed and the coordination field may include routing information for each hop through the network. Another alternative is that the data packet 600, and in particular the coordination information, is modified at each hop to include information for the next hop. Of course, other fields of data packet 600 may be used to carry routing information, QoS information, or other forms of information.

Networks 200 and 400 can be implemented with existing applications by adapting communication links 214-232 from existing powerful communication media. In the implementations shown in FIGS. 2 and 3, communication links 214-232 may be designated according to the CAN protocol. Alternatively, communication links 214-232 can be designated according to LIN, Flexray, J1850, MOST or other protocols. In the implementation shown in FIG. 4, communication links 414-432 may be designated according to any suitable protocol, such as CAN, LIN, Flexray, J1850, MOST, and the like. Each of these protocols may define a coordination mechanism to provide and allow flow control. The coordination may be specified to give the message with the highest priority the priority for the communication link. The priority may be indicated in the data packet in the message header, such as the priority tag 626 of the data packet 600. For example, the message header may contain zeros in the most significant 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 major bits, will win, and all others will release the communication link.

As with networks 200 and 400, it is necessary to distinguish all nodes of a network at the initial start of the network according to the embodiments described herein. 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 combined devices. have. It also identifies message identifiers of interest to specific nodes, assigns logical addresses to each node, generates a translation table of identifiers for node logical addresses, generates a routing table from node to node, and node to node It is necessary to create one or more backup routes. Some levels of service may be associated with a so-called discovery process. For example, and as described in more detail, a network may provide nodes capable of performing multicast, cryptography, or other capabilities. The nodes may be configured to receive information or advertise the availability of the information.

Discovery processes are known in the context of networks, and the commonly used Dijkstra algorithm can be used to complete the network discovery process and calculate the routing table. However, these known processes assume an overall dynamic network to complete the entire discovery process upon power up or any fault detection. Depending on the scale of the network, this discovery process can take several minutes, so that the user can enter the vehicle and start the process and start it immediately, or a failure occurs while the vehicle is running and the discovery process It is not practical in terms of safety in an automotive environment where there may be a significant delay in completing the process. Having to wait a few minutes to complete the discovery process will be seen as a defect and unacceptable to users and manufacturers.

Networks according to the embodiments described herein are generally not dynamic throughout. In general, the network only becomes dynamic upon failure detection, that is, the network is not dynamic until something goes wrong or new hardware is added to the network. Thus, the last known state for the network can be stored, and an incremental discovery process can be employed in detecting network changes. The increasing discovery process can be completed with little or no impact on overall network performance.

7-12 illustrate an example of an increasing discovery process that can be used with the networks described herein. The examples shown in FIGS. 7-12 are intended to illustrate one possible form of increasing discovery process, and it should be appreciated that alternatives to the specific example described may be used.

Referring now to FIGS. 7-12, upon power up of each node, a "Hello" message is sent to all immediately adjacent nodes for all ports coupled to the node. As shown in FIG. 7, node 01 sends a hello message to each of nodes 02, 03, 05, and 07. Nodes 01, 02, 03, 05, and 07 may be configured in a manner similar to that shown in FIG. 5, wherein the node transmits and receives Hello messages, such that its node number, neighbor node table, and other routing information. May include an input / output port, a processor, or some minimal form of intelligence, to allow comparison of adjacent node tables with memory that may be stored.

The hello message may include a copy of the node number and the local neighbor node table of nodes. The node will continue to send these local, one-hop, hello messages every N seconds, where N does not burden the network with hello messages and detects initial detection of network changes or potential failures. It is a randomly chosen value that is often enough to allow. Through these repeated hello messages, new connections are discovered and failed or terminated connections are transport error interrupts caused by a physical layer, for example, a " bus off " error, as is well known. Is detected by.

Whenever a node receives a hello message from an adjacent node, it looks at the local neighbor node table to see what has been modified, that is, whether there is an adjacent node sending a hello message. At network initialization, there may be no routing information stored that may occur during the initial assembly of the vehicle but may occur at other times. That is, the neighbor node table of each node is empty so that the nodes will notice that they change according to each hello message received and processed. Upon receipt of a hello message from a node on a port for which no information is stored in the local neighbor node table, the receiving node updates its local neighbor node table to include this information. As shown in FIG. 8, to indicate that node 01 is connected to port 2, node 02 updates its local neighbor node table 900. Nodes 02, 03, 05, 07 also transmit hello messages received by node 01 as shown in FIG. Receipt of these hello messages causes node 01 to generate its own local neighbor node table 1000. Through the above process of nodes sending hello messages, each node can generate its local neighbor node table.

The last known good local table is stored in the node's memory, so that during normal startup, the node will be able to effectively start communicating immediately. As the nodes discover new / lost neighbor nodes and begin broadcasting new neighbor node tables, any network changes will begin to filter all of the networks (FIGS. 10 and 11).

When there is a change in a node's neighbor table, the node broadcasts the neighbor node table for reception by mutual nodes in the network. Broadcast of neighboring node tables allows nodes to generate and store routing tables 1300 shown in FIG. Given all neighbor node tables, shown generally as neighbor node tables 1302 in FIG. 12, each node is the number of hops 1306 required to reach all nodes, mutual nodes, of the network 1304. The intermediate nodes 1308, 1310, and 1312 constituting a path to a specific node may be determined.

The discovery process may also include periodic checks to determine the state or health of the network. For example, a node may fail to receive a broadcast message that includes the node's new neighbor node table according to the process described above. This node may not be effectively synchronized with the rest of the network until it can receive a broadcast message and update its local neighbor node table. For this reason, each node may be configured to periodically broadcast a packet that includes a checksum for a neighbor node table that can verify consistency. The checksum may be sent along with other message traffic such that bandwidth cannot be consumed within the network.

Synchronization can also be an issue at fault conditions. The fault condition may cause confusion in the rediscovery activity, and as a result, the node may receive updates other than the sequence, that is, after a certain last table, a non-current table may arrive. Time stamping may be employed to ensure that each node has up-to-date information.

Other modifications and alternative embodiments of the present invention will become apparent to those skilled in the art in light of the above description. This description is to be construed as illustrative only and is for the purpose of teaching those skilled in the art the best embodiment of the invention. The details of the structure and method may vary substantially without departing from the spirit of the invention and the exclusive use of all modifications falling within the scope of the appended claims is preserved.

Claims (14)

In a vehicle communication network, Multiple network elements; And A plurality of communication links that combine the network elements in a point-to-point configuration, wherein at least some of the plurality of communication links are designated according to a shared-access bus protocol Communication links, The plurality of communication links are arranged to communicate data packets between the network elements, The data packets are modified for transmission over the plurality of communication links. The method of claim 1, And the data packets comprise route information. The method of claim 1, And the data packets are modified to include route information. The method of claim 1, The data packets are modified to include quality of service information. The method of claim 1, The communication links and the network elements are configured as a switch fabric. A method of providing communications in a vehicle, comprising: Providing a plurality of network elements in a vehicle; Communicatively combining the plurality of network elements using a plurality of communication links, wherein at least some of the plurality of communication links are shared access communication links; Constructing a data packet for communication between the network elements; And Communicating the data packet between the network elements using the communication links. The method of claim 6, Constructing a data packet comprises adding route information to the data packet. The method of claim 6, Constructing a data packet comprises adding a quality of service information to the data packet. A method for configuring a network in a vehicle, the network comprising a plurality of network elements and a plurality of communication links communicatively coupling the plurality of network elements for point-to-point communication. In the configuration method, Storing a last known configuration state for the network; Determining a change in configuration of the network to establish a current configuration; Point-to-point forwarding the current configuration state over the network via the communication links; And Storing the current configuration state at each of the plurality of network elements. The method of claim 9, Storing the last known configuration state and the current configuration state comprises storing a neighbor node table and a routing table at each of the network elements. The method of claim 9, Determining a change in the configuration state of the network to establish a current configuration state comprises transmitting a message from each network element to each communication port of the network element to which the communication link is coupled. How to configure your network. In the vehicle, A plurality of communication links communicatively coupling the plurality of network elements and the plurality of network elements for point-to-point communication; Means for storing a last known configuration state for the network; Means for determining a change in the configuration state of the network to establish a current configuration state; Means for point-to-point forwarding the current configuration state over the network via the communication links; And Means for storing the current configuration state at each of the plurality of network elements. The method of claim 12, And said means for storing a last known configuration state and a current configuration state comprises means for storing a neighbor node table and a routing table at each of said network elements. The method of claim 12, The means for determining a change in the configuration state of the network to establish a current configuration state includes means for sending a message from each network element to each communication port of the network element to which the communication link is coupled, vehicle.

Images