Patent Application
20180343326
The present disclosure relates generally to computer networks, and, more particularly, to a Controller Area Network (CAN) over Internet Protocol (IP) layer architecture and implementation.
Serial networks, such as a Controller Area Network (CAN) bus, are in wide use today across a number of different industries. For example, CAN bus is the predominant networking technology in many vehicles, particularly automobiles. Despite the prevalence of serial networks, such as CAN, in certain industries and products, other networking technologies, such as Ethernet and the Internet Protocol (IP), are heavily dominant in the Information Technology (IT) sector, having caused a strong desire from other industries to migrate non-Ethernet and non-IP networks to standard IT-based technologies for reasons that include speed of innovation, supported bandwidth, device availability, and the like.
The automobile industry has been evolving towards Automated Driver Assistance Systems (ADAS) and self-driving, which requires Ethernet/IP-based networking to support high throughput applications such as video, radar, LIDAR, and infotainment. At the same time, many control systems are still designed with serial interfaces like CAN and cannot move to Ethernet immediately and in mass.
The embodiments herein may be better understood by referring to the following description in conjunction with the accompanying drawings in which like reference numerals indicate identically or functionally similar elements, of which:
According to one or more embodiments of the disclosure, a device between a Controller Area Network (CAN)-based network and an Internet Protocol (IP)-based network receives a CAN message from a node in the CAN-based network. The CAN message comprises a CAN message identifier and a data field. The device determines an IP header based on the CAN message identifier and the CAN message. The device converts the data field of the CAN message into an IP message that includes the determined IP header. The device sends the IP message via the IP network to one or more eligible destinations for the IP message.
A computer network is a geographically distributed collection of nodes interconnected by communication links and segments for transporting data between end nodes, such as personal computers and workstations, or other devices. Many types of networks are available, ranging from local area networks (LANs) to wide area networks (WANs). LANs typically connect the nodes over dedicated private communications links located in the same general physical location, such as a building or campus. WANs, on the other hand, typically connect geographically dispersed nodes over long-distance communications links, such as common carrier telephone lines, optical lightpaths, synchronous optical networks (SONET), synchronous digital hierarchy (SDH) links, and others. In many cases, the Internet Protocol (IP) is used to convey traffic via a network.
Serial networks are another type of network, different from an IP network, typically forming a localized network in a given environment, such as for automotive or vehicular networks, industrial networks, entertainment system networks, and so on. For example, those skilled in the art will be familiar with the on-board diagnostics (OBD) protocol (a serial network which supports a vehicle's self-diagnostic and reporting capability, including the upgraded “OBD II” protocol), the controller area network (CAN) (or CAN BUS) protocol (a message-based protocol to allow microcontrollers and devices to communicate with each other in applications without a host computer). Unlike an IP-based network, which uses a shared and open addressing scheme, a serial communication network, such as a CAN-based network, generally uses localized and/or proprietary communication standards, where commands or data are transmitted based on localized device identifiers, such as parameter identifiers (PIDs), message identifiers (e.g., CAN MSGIDs), localized station addresses, and so on.
In further embodiments, network interface(s) 210 may include the mechanical, electrical, and signaling circuitry for communicating data over links coupled to the serial network 115. Notably, one or more of network interface(s) 210 may be configured to transmit and/or receive data using a serial communication protocol, such as CAN. In additional embodiments, one or more of network interface(s) 210 may be configured to transmit IP-based communications, such as via an IP-based network.
The memory 240 comprises a plurality of storage locations that are addressable by the processor 220 and the network interfaces 210 for storing software programs and data structures associated with the embodiments described herein. The processor 220 may comprise hardware elements or hardware logic adapted to execute the software programs and manipulate the data structures 245. An operating system 242, portions of which is typically resident in memory 240 and executed by the processor, functionally organizes the device by, among other things, invoking operations in support of software processes and/or services executing on the device. These software processes/services may comprise an illustrative gateway process 248, as described herein. Note that while gateway process 248 is shown in centralized memory 240 alternative embodiments provide for the process to be specifically operated within the network interface(s) 210.
It will be apparent to those skilled in the art that other processor and memory types, including various computer-readable media, may be used to store and execute program instructions pertaining to the techniques described herein. Also, while the description illustrates various processes, it is expressly contemplated that various processes may be embodied as modules configured to operate in accordance with the techniques herein (e.g., according to the functionality of a similar process). Further, while the processes have been shown separately, those skilled in the art will appreciate that processes may be routines or modules within other processes.
As noted above, in general, serial networks, such as a CAN-based networks, are not directly compatible with Ethernet/IP-based networks. In particular, a CAN-based network does not include a network layer in its implementation. As such, there is no addressing information in the CAN frames. Rather, a CAN Message Identifier (MsgID) is the identifying information provided at the application layer and is used for receiving and requesting information between CAN hosts. Information is broadcast over a CAN bus, which may create a concern for security. Similarly, quality of service or service level agreement is not defined by CAN and when a node/device receives multiple messages, it is free to choose the processing order rather than one defined by quality of service parameters. Interworking serial networks with Ethernet/IP-networks enable high throughput applications such as video, radar, LIDAR, infotainment, and the like, to be available as part of the same inter-vehicle network (IVN).
CAN to IP Internetworking
The techniques herein provide an architecture and methodology for interworking a serial network, such as a CAN-based network, with an IP-based network. In some aspects, the techniques herein allow for secure serial data frame and remote frames to be supported between any host on the serial or IP network segments.
Specifically, according to one or more embodiments of the disclosure as described in detail below, a device between a CAN-based network and an IP-based network receives a CAN message from a node in the CAN-based network. The CAN message comprises a CAN message identifier and a data field. The device determines an IP header based on the CAN message identifier and the CAN message. The device converts the data field of the CAN message into an IP message that includes the determined IP header. The device sends the IP message via the IP network to one or more eligible destinations for the IP message.
Illustratively, the techniques described herein may be performed by hardware, software, and/or firmware, such as in accordance with the gateway process 248, which may include computer executable instructions executed by the processor 220 (or independent processor of interfaces 210) to perform functions relating to the techniques described herein.
Operationally, in various embodiments of the present disclosure, for the interworking of serial networking, such as CAN-based networking, with IP-based networking, an interworking layer may be created in which CAN communication packets and IP packets are interconverted. The interworking layer may be created at the gateway where the CAN-to-IP and/or IP-to-CAN conversions may be performed. For example, since CAN is a broadcast network, broadcast capabilities may be recreated in the IP network via multicasting of CAN messages into IP packets using, e.g., multicast addresses and other fields of an IP header generated from the serial message identifier, such as the CAN msgID.
IP-based network 302 may also include any number of IP hosts 310 configured to communicate via IP-based network 302. In some embodiments, IP-based network 302 may also be connected to any number of other networks/gateways 312. For example, IP-based network 302 may be connected to other IP-based networks, such as the Internet, and/or to other CAN-based networks via IP-CAN gateways that operate in a similar to that of gateway 306 (e.g., by providing an interworking layer between the local CAN-based network and IP-based network 302.
Gateway 306 may be any form of computing device such as, e.g., a device 200 described previously with respect to
As would be appreciated, the number of gateways 306 connected to IP-based network 302, as well as the number of CAN nodes 308 connected to any given gateway 306 may vary and that the configuration shown is illustrative only. In addition, the functions described with respect to a particular one of gateways 306a-306b may also be performed by that of the other gateway 306, in some embodiments. For example, in cases in which the first gateway 306 performs a CAN-to-IP conversion, while the other gateway 306 performs a corresponding IP-to-CAN conversion, it is to be appreciated that the first gateway 306 could also be configured to perform IP-to-CAN conversions, as well.
In some embodiments, gateway 306a may convert CAN data frame 402 into an IP message for sending to one or more eligible destinations within IP-based network 302 (e.g., IP host 310, gateway 302b, etc.). Notably, gateway 306a may convert CAN data frame 402 into an IP/User Datagram Protocol (IP/UDP) packet 408 to be multicast to one or more destinations through IP-based network 302. As such, gateway 306 may determine an IP/UDP header 410 that uses the following illustrative addressing scheme:
In this way, the CAN data frame 402, which is effectively broadcast within the local CAN-based network of node 308a, with CANID 404 and data field 406, may be converted by gateway 306a into a multicast IP/UDP packet 408 with header 410 and data field 406 to be communicated through IP-based network 302 to any number of destinations. As would be appreciated, the header information described herein is illustrative only and other variations of the described headers may be used, in further embodiments.
In some embodiments, gateway 306a may also employ a security mechanism, to control which destinations within IP-based network 302 are authorized to receive packet 408. For example, in the case of a vehicle, by controlling the multicast destinations for packet 408, gateway 306a can prevent unauthorized vehicle subsystems from receiving packet 048.
As noted above, header 410 of IP/UDP packet 408 may be generated by gateway 306a to include IP/UDP address and port information derived at least in part from CAN ID 404. In other words, based on the knowledge that node 308a sent CAN data frame 402, gateway 306a may determine the eligible destination(s) for the message outside of the local CAN-based network of node 308a. In some embodiments, header 410 may also include other fields, such as quality of service (QoS) fields that ensure that packet 408 satisfies one or more service level agreements (SLAs) associated with this type of message within IP-based network 302. This parameter may be set by default by gateway 306a, be specified by a user, be based on an input file to gateway 306a, or derived from CANID 404 and/or data field 406. For example, if node 308a is in a relatively high bandwidth CAN-based network, gateway may populate the fields of header 410 to ensure that packet 408 receives a corresponding level of service within IP-based network 302.
Assume now that gateway 306b is an eligible destination for packet 408 and receives packet 408 from IP-based network 302. In turn, gateway 306b may perform the opposite conversion, thereby converting packet 408 back into CAN data frame 402 for transmission within the local CAN-based network of node 302b. For example, based on header 410 of packet 408, gateway 306b may determine CANID 404 and convert packet 408 into CAN data frame 402 with CANID 404 and data field 406. Thus, even though CAN nodes 308a-308b are on different CAN-based networks that are separated by IP-based network 302, they may communicate with one another through the operations of their respective gateways 306.
To illustrate the remote frame scenario, assume that node 308a generates and sends a remote frame 422 into its local CAN-based network. Remote frame 422 may, in this case, comprise a CANID, which is used to notify node 308b to send its requested data into the network. For example, if node 308b is a sensor, remote frame 422 can be used to request a sensor reading from node 308b. In turn, gateway 306a may determine that node 308a is requesting data from node 308b, which is on a different CAN-based network, based on the CANID included in remote frame 422.
To send remote frame 422 to node 308b, gateway 306a may generate an IP/UDP packet 424 that includes an IP header with the following addressing scheme:
Similar to the scenario in
Once converted, gateway 306a may send packet 424 to gateway 306b, which uses the header and address information of packet 424 to convert packet 424 back into a CAN remote frame 422. In turn, gateway 306b then sends remote frame 422 into its local CAN-based network, which is received by node 308b.
In response to receiving remote frame 422, node 308b may include its data, such as a sensor reading or the like, within data field 428 of CAN frame 424, which is a CAN data frame. Similar to the operations described with respect to
The scenarios presented in
As shown in
Other parameters of header 444 could include, for example, QoS parameters, similar to those described previously.
Once gateway 306a receives packet 442, it may assess the header 444 to determine an appropriate CANID 450. In turn, gateway 306 may convert packet 442 into a CAN data frame 448 that includes data field 446 from packet 442 and also includes the determined CANID 450. The converted CAN data frame 448 is then sent into the local CAN-based network associated with CAN node 308a, thereby allowing CAN node 308a to receive the message sent by IP host 310.
At step 515, as described in more detail above, the device may determine an IP header based on the CAN message identifier and the CAN message. Such a header may, for example, include a multicast IP address that is selected based on the CAN message identifier. In some embodiments, the device may determine and potentially select the multicast address to control which other devices are authorized to receive the associated packet. Further header information may include QoS parameters that control the level of service afforded to the IP packet bearing the header.
At step 520, as detailed above, the device may convert the data field of the CAN message into an IP message that includes the IP header determined at step 515. For example, the device may include the information from the data field of the CAN message in an IP packet that bears the information as part of its payload.
At step 525, the device may then send the IP message to one or more eligible destinations via the IP-based network, as described in greater detail above. Notably, using the address information in the IP header of the IP message, the message may be sent via multicast to one or more destinations, such as other CAN-IP gateways, thereby allowing the IP message to be converted back into a CAN message and transmitted within another CAN-based network. Procedure 500 may then end at step 530.
It should be noted that while certain steps within procedure 500 may be optional as described above, the steps shown in
The techniques described herein, therefore, allow for the interworking of serial networks, such as CAN-based networks, with IP networks. All of the serial network capabilities may be used, including data broadcast (push) and data requests (pull). The techniques further allow for network policy and other network security tools (firewall/IDS/IPS) to be applied in the IP network to create a more secure IVN network. In this way, serial networked vehicles may be enabled to more gracefully migrate from CAN hosts to Ethernet/IP hosts over time.
While there have been shown and described illustrative embodiments that provide for converting between serial network messages, such as CAN messages, and IP network messages, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the embodiments herein. For example, while certain embodiments are described herein with respect to using certain types of serial and IP networks (such as an IVN), the techniques are not limited as such and may be used for other functions, in other embodiments. In addition, while certain protocols are shown, such as CAN, other suitable protocols may be used, accordingly.
The foregoing description has been directed to specific embodiments. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the components and/or elements described herein can be implemented as software being stored on a tangible (non-transitory) computer-readable medium (e.g., disks/CDs/RAM/EEPROM/etc.) having program instructions executing on a computer, hardware, firmware, or a combination thereof. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the embodiments herein. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the embodiments herein.
