MESSAGE HANDLER

Abstract

A message handler (61, 62) is described. The message handler is configured, in response to receiving a data package (131, 132) which is formatted according to a given communications protocol, such as CAN or Ethernet, and which comprises package - directing data (22; FIG. 4) and payload data (23; FIG. 4), to generate package (14) having a predetermined data format, for example a layer-2 or layer-3 package, which comprises a header (24; FIG. 4) and payload data (25; FIG. 4). The header comprises an address generated in dependence upon the package-directing data and wherein the payload comprises the data package. The package (14) having a predetermined data format may be an IEEE 1722 frame.

Claims

1. A message handler configured, in response to receiving a data package which is formatted according to a given communications protocol and which comprises package-directing data and payload data, to generate a package having a predetermined data format which comprises a header and payload data, wherein the header comprises an address generated in dependence upon the package-directing data and wherein the payload comprises the data package.

2. A message handler according to claim 1, wherein the package having the predetermined data format is a layer-2 or layer-3 package.

3. A message handler according to claim 1, which is configured to copy data from a first field in the package-directing data into a corresponding field in the header.

4. A message handler according to claim 1, which is configured to add predetermined data to a second field in the header.

5. A message handler according to claim 1, which is configured to add calculated data to the header in dependence upon data from the first field and/or from a second field to a second field in the header.

6. A message handler according to claim 1, which is configured, in response to receiving a package having a predetermined data format which comprises a header and payload data, to extract a data package which is formatted according to a given communications protocol and which comprises package-directing data and payload data.

7. A message handler configured, in response to receiving a package having a predetermined data format which comprises a header and payload data, to extract a data package which is formatted according to a given communications protocol and which comprises package-directing data and payload data.

8. (canceled)

9. A message handler according to claim 1, wherein the package having the predetermined data format is a layer 2 frame.

10. A message handler according to claim 1, wherein the package- having the predetermined data format is an IP packet.

11. (canceled)

12. A message handler according to claim 1, wherein the given communications protocol is the controller area network flexible data rate protocol.

13. A message handler according to claim 1, wherein the given communications protocol is the FlexRay protocol.

14. A message handler according to claim 1, wherein the given communications protocol is the media oriented systems transport protocol.

15. (canceled)

16. (canceled)

17. A network interface module which is hardware-implemented and which comprises: a protocol engine; and a message handler according to claim 1 and which is configured to exchange data packages formatted according to a given communications protocol with the protocol engine.

18. A central processing unit sub-system comprising: a central processing unit; memory; a computer program stored in memory or other storage which, when executed by the central processing unit, causes the central processing unit to execute a message handler according to claim 1.

19. (canceled)

20. A control unit comprising: a first message handler according to claim 1 configured to handle data packages formatted according to a first communications protocol; a second message handler according to claim 1 configured to handle data packages formatted according to a second communications protocol; and a message forwarder configured to exchange packages having the predetermined data format between the first and second message handlers.

21. A control unit according to claim 20, wherein the message forwarder is a layer-2 switch and/or a layer 3-router.

22. A control unit according to claim 20, wherein the first and second communication protocols are different.

23. A control unit according to claim 20, further comprising: a third message handler according to claim 1, configured to handle data packages formatted according to a third communications protocol.

24. A control unit according to claims 20, further comprising: a central processing unit sub-system; and wherein the message forwarder is configured to exchange between the central processing unit sub-system and the first and/or second message handlers.

25. (canceled)

26. (canceled)

27. A communications system comprising: at least two sets of buses lines; and at least one control unit according to claim 20 connected to the buses.

28. (canceled)

29. (canceled)

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Certain embodiments of the present invention will now be described, by way of example, with reference to FIGS. 2 to 8 of the accompanying drawings, in which:

[0037] FIG. 1 is a schematic block diagram of a communications system in which data can be exchanged between buses in software;

[0038] FIG. 2 is a schematic block diagram of a communications system in which data can be exchanged between buses in hardware;

[0039] FIG. 3 is a schematic block diagram of a control unit;

[0040] FIG. 4 illustrates conversion of a communications protocol-dependent package into a common-format package;

[0041] FIG. 5 illustrates conversion of a common-format package into a communications protocol-dependent package;

[0042] FIG. 6 illustrates a CAN frame including a CAN-dependent package;

[0043] FIG. 7 illustrates an AVTP common message;

[0044] FIG. 8 is a schematic diagram of a vehicular communications network and a vehicle; and

[0045] FIG. 9 is a schematic diagram of an industrial communications network and robots.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Communications System 1

[0046] FIG. 2 shows a communications system 1 which includes first and second sections 2.sub.1, 2.sub.2 for 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 lines 3.sub.1, 3.sub.2.

[0047] The first section 2.sub.1 includes a physical layer module 4.sub.1, a protocol engine module 5.sub.1 and a message handler 6.sub.1. The protocol engine module 5.sub.1 and message handler 6.sub.1 are implemented in hardware in a network interface module 7.sub.1 (FIG. 3).

[0048] The second section 2.sub.2 includes a physical layer module 4.sub.2, a protocol engine module 5.sub.2 and a message handler 6.sub.2. The protocol engine module 5.sub.2 and message handler 6.sub.2 are implemented in hardware in a network interface module 7.sub.2 (FIG. 3).

[0049] The message handlers 6.sub.1, 6.sub.2 are interconnected by a package or message forwarder 8 which can take the form of a layer-2 switch or a layer-3 router. The message forwarder 8 is preferably implemented in hardware comprising appropriate hardware logic, hardware registers etc. The message forwarder 8 does not carry out any protocol conversion. The message forwarder 8 is also connected, via a unified network stack 9, to higher layers 10. The unified network stack 9 and higher layers 10 are implemented in software.

[0050] The physical layer module 4.sub.1, 4.sub.2 passes incoming frames 12.sub.1, 12.sub.2 to the protocol engine 5.sub.1, 5.sub.2 which can remove frame components, such as the frame check sequence (FCS), and generates packages 13.sub.1, 13.sub.2. The protocol engine 5.sub.1, 5.sub.2 may add information, such as a timestamp, to the packages 13.sub.1, 13.sub.2.

[0051] The protocol engine 5.sub.1, 5.sub.2 passes the packages 13.sub.1, 13.sub.2 to the message handler 6.sub.1, 6.sub.2 which generates common-format packages 14. As will be explained in more detail later, the message handler 6.sub.1, 6.sub.2 can pass the common-format packages 14 to the message forwarder 8 for switching or routing the common-format packages 14 to another message handler 6.sub.1, 6.sub.2 and/or to the unified network stack 9. Thus, packages can be forwarded not only between message handlers 6.sub.1, 6.sub.2, but also to higher layers 10.

[0052] If there are more than two message handlers 6.sub.1, 6.sub.2, then the message forwarder 8 can switch or route packages to more than one message handler 6.sub.1, 6.sub.2, as well as to the higher layers 10, if necessary. The message forwarder 8 may unicast or multicast messages.

[0053] Referring also to FIG. 3, the physical layer modules 4.sub.1, 4.sub.2 take the form of PHY transceivers 4.sub.1, 4.sub.2. The protocol layers 5.sub.1, 5.sub.2, message handlers 6.sub.1, 6.sub.2, message forwarder 8, unified stack 9 and higher layers 10 are implemented in a control unit 16 in the form of a microcontroller or system-on-a-chip. The control unit 16 comprises network interface modules 7.sub.1, 7.sub.2 (or “communication controllers”) which provide the protocol engines 5.sub.1, 5.sub.2 and message handlers 6.sub.1, 6.sub.2. The control unit 16 comprises a central processing unit subsystem 17 which includes at least one central processing unit (CPU) 18, memory 19 and an on-chip interconnect (not shown). The physical layer modules 4.sub.1, 4.sub.2 can also be implemented in the microcontroller or system-on-a-chip.

[0054] The CPU 18 is able to configure the network interface modules 7.sub.1, 7.sub.2 and the message forwarder 8. The CPU 18 may also be able to access message handler 6.sub.1, 6.sub.2, bypassing the message forwarder 8, 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 forwarder 8 can be bypassed, the CPU 18 may still use the common format, although it may also be able to handle data in a specific media format, such as CAN.

[0055] The CPU 18 may run a software-based message handler 20. This can allow the CPU 18 to prepare common-format messages 14 which can then be sent either directly, or via the message router 8, to one or more message handlers 6.sub.1, 6.sub.2.

Message Handlers 6.SUB.1., 6.SUB.2

[0056] As mentioned earlier, a message handler 6.sub.1, 6.sub.2 receives data packages 13.sub.1, 13.sub.2 from a respective protocol engine 5.sub.1, 5.sub.2, such as a CAN protocol engine, and generates common-format packages 14.

[0057] Referring also to FIG. 4, each data package 13.sub.1, 13.sub.2 includes a protocol-dependent address 22 and payload 23.

[0058] The format of the address 22 and how the address 22 is 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.

[0059] 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.

[0060] Priority control can be included in the address, in the payload 23 or 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.

[0061] The message handler 6.sub.1, 6.sub.2 extracts the protocol-dependent address 22 from a data package 13.sub.1, 13.sub.2 and prepares a common-format header 24 and payload 25. The common-format header 24 includes a common-format address 26.

[0062] The message handler 61, 62 maps the protocol-dependent address 22 into a common-format address 26. Preferably, address and message identification are split into different fields. This can help to simplify routing of the common-format package 14.

[0063] The message handler 6.sub.1, 6.sub.2encapsulates the data package 13.sub.1,13.sub.2 received from the protocol engine 5.sub.1, 5.sub.2 into the payload 25 of the common-format message 14. Thus, the common-format message 14 can carry information for all supported data link layers, such as CAN message ID as well as a common-format address. If the common-format message 14 uses 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 handler 6.sub.1, 6.sub.2 may be configured to fill-in the missing information, for example, configured by software running on the CPU 18.

[0064] Referring also to FIG. 5, when a message handler 61, 62 receives a common-format package 14 from the message forwarder 10, it discards the header 26 and extracts the data package 13.sub.1, 13.sub.2 from the payload 25. The message handler 7.sub.1, 7.sub.2 then forwards the package 13.sub.1, 13.sub.2 to the protocol engine 5.sub.1, 5.sub.2.

[0065] As explained earlier, the message forwarder 8 may forward a common-format package 14 to more than one target. The one or more targets may include more than one message handler 6.sub.1, 6.sub.2. The one or more targets may include the CPU 18.

[0066] The common-format package 14 provides a common addressing format which allow identification of a target node (not shown) outside the control unit 16 (FIG. 3) or a target service (not shown) running on the CPU 18. 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.

[0067] The common-format package 14 provides a container which allows a communication protocol, such as Ethernet, CAN or FlexRay, to map its message back into its protocol-specific message format.

[0068] The common-format package 14 can be any suitable type of layer-2 or layer-3 data container. Preferably, the common-format package 14 take 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 address 26 and 8-level QoS according to IEEE 802.1Q for signalling priority levels. This allows a layer-2 Ethernet switch to be used a message forwarder 8.

[0069] 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.

[0070] FIG. 6 shows a data package 131, taken from a CAN data frame, which is passed from the protocol engine 5.sub.1 to the message handler 6.sub.1.

[0071] FIG. 7 shows how the data package 13.sub.1 shown in FIG. 6 is converted into a common-format package 14.

[0072] As shown in FIG. 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 package 13.sub.1. 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 package 13.sub.1. Although the message handler 6.sub.1 is implemented in hardware, it can be configured by the CPU 18.

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

[0074] Referring to FIG. 8, a vehicular communications network 31 is shown. The network 31 includes a plurality of different busses 3.sub.1, 3.sub.2, 3.sub.3, such as CAN and Ethernet. The network includes a plurality of control units 32 which may take the form of microcontrollers connected to the busses 3.sub.1, 3.sub.2, 3.sub.3. At least some of the control units 32 are control units 16 which include network interface modules 7.sub.1, 7.sub.2 (FIG. 3) and message forwarder 8. The vehicular communications network 31 is deployed in a vehicle 33.

[0075] Referring to FIG. 9, an industrial communications network 41 is shown. The network 41 includes a plurality of different busses 3.sub.1, 3.sub.2, 3.sub.3, such as CAN and Ethernet. The network includes a plurality of control units 42 which may take the form of microcontrollers connected to the busses 3.sub.1, 3.sub.2, 3.sub.3. At least some of the control units 42 are control units 16 which include network interface modules 7.sub.1, 7.sub.2 (FIG. 3) and message forwarder 8. The industrial communications network 4.sub.1 is deployed in a plant, machinery or system 43, such as a manufacturing or processing system.

[0076] The message handlers 6.sub.1, 6.sub.2 can have one or more benefits.

[0077] The message handlers 6.sub.1, 6.sub.2 can 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

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

[0079] 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.