Patent ID: 12212639

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Communications System1

FIG.2shows a communications system1which includes first and second sections21,22for implementing the lowest protocol layers for first and second communications protocols, such as controller area network (CAN) and Ethernet, which are connected to first and second sets of bus lines31,32.

The first section21includes a physical layer module41, a protocol engine module51and a message handler61. The protocol engine module51and message handler61are implemented in hardware in a network interface module71(FIG.3).

The second section22includes a physical layer module42, a protocol engine module52and a message handler62. The protocol engine module52and message handler62are implemented in hardware in a network interface module72(FIG.3).

The message handlers61,62are interconnected by a package or message forwarder8which can take the form of a layer-2 switch or a layer-3 router. The message forwarder8is preferably implemented in hardware comprising appropriate hardware logic, hardware registers etc. The message forwarder8does not carry out any protocol conversion. The message forwarder8is also connected, via a unified network stack9, to higher layers10. The unified network stack9and higher layers10are implemented in software.

The physical layer module41,42passes incoming frames121,122to the protocol engine51,52which can remove frame components, such as the frame check sequence (FCS), and generates packages131,132. The protocol engine51,52may add information, such as a timestamp, to the packages131,132.

The protocol engine51,52passes the packages131,132to the message handler61,62which generates common-format packages14. As will be explained in more detail later, the message handler61,62can pass the common-format packages14to the message forwarder8for switching or routing the common-format packages14to another message handler61,62and/or to the unified network stack9. Thus, packages can be forwarded not only between message handlers61,62, but also to higher layers10.

If there are more than two message handlers61,62, then the message forwarder8can switch or route packages to more than one message handler61,62, as well as to the higher layers10, if necessary. The message forwarder8may unicast or multicast messages.

Referring also toFIG.3, the physical layer modules41,42take the form of PHY transceivers41,42. The protocol layers51,52, message handlers61,62, message forwarder8, unified stack9and higher layers10are implemented in a control unit16in the form of a microcontroller or system-on-a-chip. The control unit16comprises network interface modules71,72(or “communication controllers”) which provide the protocol engines51,52and message handlers61,62. The control unit16comprises a central processing unit subsystem17which includes at least one central processing unit (CPU)18, memory19and an on-chip interconnect (not shown). The physical layer modules41,42can also be implemented in the microcontroller or system-on-a-chip.

The CPU18is able to configure the network interface modules71,72and the message forwarder8. The CPU18may also be able to access message handler61,62, bypassing the message forwarder8, so as to be able to read, write and process frames more directly. Thus, the message forwarding mechanism need not be used for all frames. For example, message forwarding can be used to route frames automatically for certain, predetermined types of frames. Notwithstanding the fact that the message forwarder8can be bypassed, the CPU18may still use the common format, although it may also be able to handle data in a specific media format, such as CAN.

The CPU18may run a software-based message handler20. This can allow the CPU18to prepare common-format messages14which can then be sent either directly, or via the message router8, to one or more message handlers61,62.

Message Handlers61,62

As mentioned earlier, a message handler61,62receives data packages131,132from a respective protocol engine51,52, such as a CAN protocol engine, and generates common-format packages14.

Referring also toFIG.4, each data package131,132includes a protocol-dependent address22and payload23.

The format of the address22and how the address22is used depends on the communications protocols. For example, Ethernet uses 48-bit media access control (MAC) addresses to identify destination nodes for unicasting or multicasting packets. CAN uses 11- or 29-bit message identifiers to identify message content for multicasting messages. FlexRay uses a temporary relation to identify message content for multicasting messages.

Priority control can be included in the address, in the payload23or signalled in other ways. For example, in Ethernet, priority information is included in the payload, whereas in CAN, message priority is included in the message identity. In FlexRay, message priority is based on repetition in pre-defined cycles.

The message handler61,62extracts the protocol-dependent address22from a data package131,132and prepares a common-format header24and payload25. The common-format header24includes a common-format address26.

The message handler61,62maps the protocol-dependent address22into a common-format address26. Preferably, address and message identification are split into different fields. This can help to simplify routing of the common-format package14.

The message handler61,62encapsulates the data package131,132received from the protocol engine51,52into the payload25of the common-format message14. Thus, the common-format message14can carry information for all supported data link layers, such as CAN message ID as well as a common-format address. If the common-format message14uses a layer-2 or layer-3 protocol which does not allow tunnelling of all fields (such as baud rate bit of CAN) such that it results in missing information, then the message handler61,62may be configured to fill-in the missing information, for example, configured by software running on the CPU18.

Referring also toFIG.5, when a message handler61,62receives a common-format package14from the message forwarder10, it discards the header26and extracts the data package131,132from the payload25. The message handler71,72then forwards the package131,132to the protocol engine51,52.

As explained earlier, the message forwarder8may forward a common-format package14to more than one target. The one or more targets may include more than one message handler61,62. The one or more targets may include the CPU18.

The common-format package14provides a common addressing format which allow identification of a target node (not shown) outside the control unit16(FIG.3) or a target service (not shown) running on the CPU18. The common addressing format preferably also provides a quality of service (QoS) level. The common addressing format provides a minimum set of information which allows switching or routing to be performed.

The common-format package14provides a container which allows a communication protocol, such as Ethernet, CAN or FlexRay, to map its message back into its protocol-specific message format.

The common-format package14can be any suitable type of layer-2 or layer-3 data container. Preferably, the common-format package14take the form of Audio Video Transport Protocol (AVTP) Control Format (ACF) messages defined according to IEEE 1722 using the 64-bit stream ID as the common-format address26and 8-level QoS according to IEEE 802.1Q for signalling priority levels. This allows a layer-2 Ethernet switch to be used a message forwarder8.

ACF messages using stream ID as the common-format address need not be used. Other types of data container can be used, such as a layer-3 datagram (i.e. an “IP packet” or simply “packet”) using the IP address as the common-format address (e.g. based on IPv4 or IPv6) or a layer-2 datagram (i.e. “frame”) which uses the MAC address as the common-format address.

FIG.6shows a data package131, taken from a CAN data frame, which is passed from the protocol engine51to the message handler61.

FIG.7shows how the data package131shown inFIG.6is converted into a common-format package14.

As shown inFIG.6, data in some of the fields, such as RTR, IDE and DATA (i.e. payload data), are obtained by copying data from the data package131. Data are added to other fields according to pre-defined schemes which may be based on acceptance filter lists (AFLs) or look-up tables. Data are added to other fields dependent on data found in fields in the data package131. Although the message handler61is implemented in hardware, it can be configured by the CPU18.

The IEEE 802.1 and 802.1Q headers are not required, but are helpful because IEEE 1722 messages are typically encapsulated in Ethernet packages.

Referring toFIG.8, a vehicular communications network31is shown. The network31includes a plurality of different busses31,32,33, such as CAN and Ethernet. The network includes a plurality of control units32which may take the form of microcontrollers connected to the busses31,32,33. At least some of the control units32are control units16which include network interface modules71,72(FIG.3) and message forwarder8. The vehicular communications network31is deployed in a vehicle33.

Referring toFIG.9, an industrial communications network41is shown. The network41includes a plurality of different busses31,32,33, such as CAN and Ethernet. The network includes a plurality of control units42which may take the form of microcontrollers connected to the busses31,32,33. At least some of the control units42are control units16which include network interface modules71,72(FIG.3) and message forwarder8. The industrial communications network41is deployed in a plant, machinery or system43, such as a manufacturing or processing system.

The message handlers61,62can have one or more benefits.

The message handlers61,62can help to provide uniformity in the way messages are forwarded regardless of bus type and whether the message arrived on a communications bus or is generated by the CPU. It can also provide configurable flexibility, for example, allowing messages to be forwarded to multiple targets. Furthermore, the use of a common network stack reduces the degree of layer-3 software stack adaption when adding a new protocol. Moreover, a common set of functions are available, regardless of protocol, such as an abstract QoS mechanism (for example, mapped to IDs on CAN, to 802.1Q PCP on Ethernet and to scheduling on FlexRay), an abstract node addressing mechanism (for example mapped to IDs on CAN, to MAC, VLAN, AVTP or IPv4 on Ethernet) and a unified timestamping mechanism (for example, based on 802.1AS). Additionally, it can simplify software maintenance when changing protocol (for example, porting a CAN-based control unit to Ethernet).

Modifications

It will be appreciated that many modifications may be made to the embodiments hereinbefore described.

The control units may include more than two network interface modules. Two or more of the network interface modules may be of the same type, for example, CAN controllers. Thus, the control unit may be connected to more than two types of bus. The message forwarder may be connected to more than two network interface modules. Thus, the control unit may be connected to more than two buses of the same type. The message forwarder may be connected to more than two network interface modules. Thus, the message forwarder may switch or route common-format messages between three or more message handlers.