WO2005122508A1

WO2005122508A1 - A network gateway

Info

Publication number: WO2005122508A1
Application number: PCT/IE2005/000067
Authority: WO
Inventors: Donal Anthony Heffernan; Shehryar Shaheen; Jeramiah G. Leen
Original assignee: University Of Limerick
Priority date: 2004-06-10
Filing date: 2005-06-10
Publication date: 2005-12-22
Also published as: IE20050393A1

Abstract

A gateway (1) interfaces with four time-triggered networks. It comprises a protocol controller (2) for interfacing with each network, and each controller (2) is connected to a network host processor (3) for protocol translation. There is a radial architecture with each network host processor (3) linked to a central core state machine (4) via a transmit interfaces (10), a transmit FIFO (11), a frame register (12), a receive interface (13), and a receive FIFO (14). The gateway (1) achieves real-time interfacing and routing because of its core hardware state machine control (4), and a bit by bit protocol translation at each network host processor (30) to the internal core frame format (Fig. 2). This bit by bit approach means that the leading translated bits are being packetized to the internal core frame format while the trailing bits are being translated.

Description

"A network gateway"

INTRODUCTION

Field of the Invention

The invention relates to interfacing between networks for applications such as vehicles and other such automation equipment, including at least one time triggered ("TT") network.

Prior Art Discussion

Messages in a time-triggered network are communicated by strictly adhering to an offline defined schedule of messages. Based on a Global Time, these messages are released when the Global Time reaches a point when a message has to be communicated. For transmissions, the messages are released when the Global Time reaches a certain pre-defined moment, and for receptions a message is expected to arrive when the Global Time reaches a certain moment i.e. the receive time for that frame. Clocks within a network are synchronized by means of clock synchronization algorithms.

In a situation where more than one type of TT network is employed in the various subsystems of the overall control system there would be a need to communicate in real time across different networks. The inter-network communication mechanism needs to ensure that message deadlines are met for inter-network traffic so as not to violate the temporal properties of safety critical messages.

The conventional approaches for data communication gateways are based on some of the following models: shared memory approach, shared medium approach, fully interconnected approach, space division approach. Each one of these approaches is briefly summarised as follows:

Shared Memory Approach In the shared memory switching approach incoming packets are converted from serial to parallel form, and written sequentially to a dual port RAM (random access memory). A memory controller defines the order in which packets are read out of the memory, based on packet headers with internal routing tags. Outgoing packets are demultiplexed to the outputs and converted from parallel to serial form. This approach is an output queuing approach, where the output buffers all physically belong to a common buffer pool.

This approach, however, suffers from a few drawbacks. The shared memory must operate N times faster than the port speed because packets must be read and written one at a time. As the access time of memory is physically limited, the approach is not very scalable. The product of the number of ports times port speed (NV) is limited. In addition, the centralized memory controller must process packet headers and routing tags at the same rate as the memory. This is difficult for schemes which support multiple priority classes and complicated packet scheduling with multicasting/ broadcasting features.

Shared Medium Approach

Packets may be routed through a shared medium, like a ring, bus or dual bus. Time- division multiplexed buses are a popular example of this approach. Arriving packets are sequentially broadcast on the TDM bus in a round-robin manner. At each output, address filters pass the appropriate packets to the output buffers, based on their routing tags. The bus speed must be at least NV to eliminate input queuing.

The outputs are modular, which makes address filters and output buffers easy to implement. Also the broadcast-and-select nature of the approach makes multicasting and broadcasting straightforward.

However, because the address filters and output buffers must operate at the shared medium speed, which is N times faster than the port speed, this places a physical limitation on the scalability of the approach. In addition, unlike the shared memory approach, output buffers are not shared, which requires a greater amount of buffers for the same packet loss rate.

Fully Interconnected Approach

In this approach, independent paths exist between all N-squared possible pairs of inputs and outputs. Hence, arriving packets are broadcast on separate buses to all outputs and address filters pass the appropriate packets to the output queues.

Unfortunately, the quadratic growth of buffers limits the number of output ports for practical reasons.

Space Division Approach

A crossbar switch is the simplest example of a matrix-like space division fabric that physically interconnects any of the N inputs to any of the N outputs. A crossbar switch can be used to achieve very high data rates of the order of Gbps, using input/output buffering and a bi-directional arbitration algorithm. Multistage interconnection networks (MLNs), which are tree-like structures, were developed to reduce the N squared crosspoints needed for circuit switching, multiprocessor interconnection and, more recently, packet switching.

Thus, while a number of gateway architectures are known in the art, none are particularly suitable for interfacing with time-triggered control networks. There is, more particularly, a requirement for a gateway which:-

- guarantees timely and reliable delivery of all frames across the gateway; and/or

- ensures real time communication.

SUMMARY OF THE INVENTION According to the invention there is provided a gateway for interfacing between communication networks including at least one time-triggered network, wherein the gateway comprises: a plurality of network interfaces, each having a port for interfacing with an associated one of said communication networks, and a hardware state machine controller for routing messages within the gateway between the network interfaces in real time.

In one embodiment, each network interface comprises a host processor for real time bit-by-bit translation between the protocol of the associated network and a gateway internal format.

In one embodiment, the host processor packetizes leading translated bits to the gateway internal format while trailing bits are being translated.

In another embodiment, each network interface comprises a receive interface device for receiving internal-format bits.

In one embodiment, each network interface comprises a receive FIFO buffer for receiving internal-format frames from the receive interface device and for routing them to a register.

In one embodiment, each network interface comprises a transmit device for transmitting internal-format frames to the host processor as the host processor is translating them.

In one embodiment, each network interface comprises a register for receiving messages from another network interface and a transmit FIFO for buffering messages between the register and the transmit device. In a further embodiment, the registers are interconnected in a routing ring, the registers read frames from the receive FIFO buffers, and the registers route the frames in the routing ring, and write the frames to the transmit FIFO buffer which is the destination for the frame before translation to the protocol of the associated network.

In one embodiment, the host processors insert a source identifier, a destination identifier, and a data field in each internal-format message, and the registers write messages to the transmit FIFO buffers according to the destination identifiers under state machine control.

In one embodiment, the data field contains a frame sequence identifier.

In one embodiment, the FIFO buffers operate according to a circular buffer model, each having a head index, a tail index, and a frame count.

In one embodiment, the head index and the frame count are incremented upon writing to the FIFO buffer, and for every frame read the tail index is incremented and the frame count is decremented.

In one embodiment, the gateway operates without an internal clock, as it is self- synchronized to external traffic.

In one embodiment, the gateway operates at a speed greater than the product of the number of ports and the port speed.

In one embodiment, the gateway further comprises a processor for executing a scheduling matrix, and for controlling the network interfaces and the controller to transfer messages between the networks in a time deterministic manner.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:- Fig. 1 is a diagram illustrating the architecture of a gateway of the invention;

Fig. 2 is a diagram illustrating core frame format;

Fig. 3 is a diagram illustrating a FIFO circular buffer mechanism of the gateway;

Fig. 4 is a diagram of a gateway transmit side interface;

Fig. 5 is a set of plots showing transmit protocol timing;

Fig. 6 is a diagram showing a gateway receive side interface;

Fig. 7 is a set of plots for receive protocol timing; Fig. 8 is a diagram showing an example inter-network traffic schedule;

Fig. 9 is a diagram showing an example inter-network message schedule; and

Fig. 10 is a diagram illustrating a hardware frame generator/analyser to test the gateway.

Description of the Embodiments

Referring to Figs. 1 to 3 a gateway 1 of the invention is shown interfacing with four time-triggered networks. It comprises a protocol controller 2 for interfacing with each network, and each controller 2 is connected to a network host processor 3. There is a radial architecture with each network host processor 3 linked to a central core state machine 4 via: a transmit interfaces 10, a transmit FIFO 11, a frame register 12, a receive interface 13, and a receive FIFO 14.

The gateway 1 achieves real-time interfacing and routing because of its core hardware state machine control 4, and a bit by bit protocol translation at each network host processor (NHP) 3 to the internal core frame format (Fig.2). This bit by bit approach means that the leading translated bits are being packetized to the internal core frame format while the trailing bits are being translated. Note, this internal core frame format (Fig 2) will typically carry just two bytes of data along with a frame sequence number, in its data field.

Referring to Fig. 1, this core frame is passed from the NHP 2 via the RX/IF 13 to the RXFIFO (ring buffer) 14. The frame register 12 will pick up the core frames from the RXFIFO 14 as they become available and the round-robin action of the core will transfer the core frame to its correct destination at defined in the DST ID (destination identifier) of the core frame (Fig 2).

The bit by bit translation achieves very fast protocol translation because it avoids buffering. If a given network protocol does not, for any reason, lend itself to such a bit by bit (or even byte by byte) translation, then it is possible for the NHP to buffer a full frame before frame packetization. In that case there would be a single frame delay in the translation process and such a delay could be accounted for in the overall scheduling of the system.

The interfacing schedules are statically scheduled in advance according to a higher- level schedule matrix.

The gateway 1 operates in real time with round robin equal priority routing of frames, to realise a shared medium solution. The shared medium approach for packet routing is the most suitable for inter-network communications in time-triggered networks. This is due to the fact that full internal non-blocking operation of the switch can be guaranteed as long as it operates at a speed greater than the product of the number of ports and the port speed in packets per second. Scalability is simple. In the gateway core the shared medium is the ring of four frame- ide registers 12 that operate in a round robin manner according to a hardware state machine. Full internal non-blocking operation is guaranteed as long as the shared medium's switching speed is greater than NV where N is the number of ports and V is traffic rate in packets per second. The central self-routing ring operates at a speed greater than NV. Also the use of sufficiently fast processors as network host processors 3 ensures fast frame conversion from network to gateway format and vice versa.

In time-triggered networks all messages are statically scheduled at system design time, where the network schedule is realised as a scheduling matrix. The gateway can operate under this message scheduling matrix, where messages are seamlessly transferred between different types of networks in a time deterministic manner, thus maintaining the temporal integrity of the system.

The gateway converts from one type of protocol to another, in strict real-time. By strict real time, in this sense, it is meant that an incoming serial frame, on the bus of one type of network, can be converted 'on the fly' to the internal packet frame foπnat and translated to a different type of network frame which is transferred out serially to its bus. This is an important feature for time-triggered networks as a fundamental requirement from time-triggered networks is that the time is predictable.

The gateway allows different types of time triggered networks to interoperate in a real-time deterministic manner. It also allows such interoperation between time- triggered networks and non-time triggered networks. For example, a FlexRay type time-triggered network could interoperate an event-driven CAN type network.

The gateway can operate without any internal gateway clock or clocks, because it is self synchronised to the external traffic. This is achieved within the constraints of the overall traffic throughput where the aggregate speeds of all ports are calculated in advance and accounted for in the calculation of overall matrix scheduling. Network nodes can be synchronised at the application level by the inclusion of a time frame in the protocol to carry timing information between the different types of networks, across the gateway.

Optionally, synchronised internal clocks can be used to provide more flexibility in the system message scheduling.

In more detail, the central routing core is based on a round robin scheme. Round robin routing ensures equal priority routing of messages. The central routing core consists of the shift register 12 that rotate inter-network messages amongst them and drop off messages at their intended ports according to their destination address.

The registers 12 read frames from the receive FIFOs 14, rotate them among themselves and write to the transmit FIFO 11 according to the destination address on the frame. As shown in Fig. 2, the frame format has three distinct fields: Source ID Destination ID Data Field

The Source ID field is 4 bits wide, where each bit represents a network port. If more than 4 ports were to be supported then the core frame could be redefined as required. The destination ID is also 4 bits wide and each bit here represents the destination port address and the Data Field carries the Frame Data. The encoding and decoding of these source and destination IDs is the responsibility of the network host processors 3. The destination ID is decoded inside the gateway core whereas the source ID is decoded in the network host processor for it to form the correct transmit frame.

The FIFOs 11 and 14are modelled on a circular buffer model which has the following three indexes: Head index Tail Index Frame Count Upon initialisation all three indexes are set to zero. Upon writing into the buffer the Head Index is incremented and the Frame Count is incremented too. For every write to the FIFO the Head Index is incremented and the Frame Count is incremented as well. The Frame Count cannot exceed a maximum count and upon reaching that the FIFO is marked full and it cannot be written to. For every frame read the Tail Index is incremented and the Frame Count is decremented. The Frame Count ensures that the Tail Index does not overtake the Head Index, nor does it allow the Head Index to go beyond a maximum limit. Fig. 3 shows the concept of the circular buffer.

For the Transmit/Receive Interface processes, the control signals of the gateway interface protocol support the exchange of data between the host processors 3 and the gateway core. The transmit interface 10 is shown in Fig. 4. It comprises three control signals and an 8-bit data port. Upon receiving a Frame Start Out signal on the transmit Interface a frame is read out of the Tx FIFO and stored in the framejregister of the transmit Interface block. Upon reception of a Port Ready pulse the transmit_counter of the transmit Interface block is incremented and the MSB (most significant byte) of the frame is sent out of the port to be read by the host processor 3. Once the full frame is transmitted, then on the reception of a Frame End Out pulse on the transmit Interface the Tail Index of the Tx FIFO 11 is incremented for the next frame to be transmitted. Transmit protocol timing is shown in Fig. 5. In this example BYT 1 is the core frame's packet sequence number and BYT 2 and BYT 3 are the two data bytes, which have been packetized from the incoming TT frame.

The receive interface 13 works quite similarly to the transmit interface 10. It also has three control signals and one 8-bit wide reception port along with a framejregister and a receive_counter. Reception on the receive interface begins with the arrival of a Frame Start In pulse which increments the Head Index of the Rx FIFO. The host processor 3 then outputs the MSB (most significant byte) of the frame on the 8 -bit wide reception port and pulses the Ready to Read port, on which the byte is put into the MSB of the framejregister and the receive_count in incremented. Once the complete frame is received in this way, upon reception of a Frame End In pulse the received frame is written into the current Rx FIFO location, pointed to by the Head Index. Receive protocol timing is shown in Fig. 7.

The host processors perform the protocol conversion from network-format to the format of the gateway core and vice versa. In three of the four time-triggered networks there is a notion of message IDs. However TTP/C is an exception. In TTP/C the equivalent of message IDs can be the time slot numbers. The basic approach for making inter-network communication possible is to assign a set of IDs and time slots in each network for inter-network communication.

For messages going out from one network to the other, the host processor 3 decodes the identifier or time slot of that message and encapsulates the data in the frame format of the gateway core and sends it out according to the transmit protocol.

For messages coming into the network, from other networks, the host processor decodes the source ID of the gateway core frame and encapsulates the data in the network frame format with the ID associated with the originating network of the incoming message.

The host processor 3 also performs the necessary protocol conversion and frame packetization to break down a network frame into a number of gateway frames and add a packet sequence number. The receiving host processor uses these packet sequence numbers to arrange gateway frames in order to extract the transmitted network frame.

Inter-Network Traffic Schedule

In order to keep inter network traffic within the time boundaries, the scheduling of messages for inter-network communications in each network has to have some constraints in place. Fig. 8 shows a time-triggered network is used as a small reference example for explaining the scheduling of messages for real-time inter-network communications, in the context of the gateway design. In Fig. 8 the generic time-triggered network has four network nodes. Three of the network nodes are 'Normal Network Nodes', implying that they are coupled to a sensor or an actuator in the control network. The 'Network Host Processor Node' encompasses all of the functionality of the 'Normal Network Node' and is connected to the Gateway Core. The additional functionality in the 'Network Host Processor' node is the algorithms and functions for protocol conversion from gateway to network format and vice- versa.

Fig. 9 shows the broader picture of the overall message schedule for inter-network messages for the example, in time-triggered networks the communication on the bus in general is divided in cycles and rounds. All cycles are of same length but the message sequence that makes up a round may or may not be the same. A fixed number of cycles make up a round after which the pattern of cycles is repeated again. This is a generic form in which messages are communicated in time-triggered networks. Fig. 9 shows the message communication schedule of each node in each cycle of the message communication round. The numbers in Fig. 9 represent a message ID or Slot number, the Tx' or the 'Rx' shows if the node will transmit or received in the listed message ID or slot number. The dashed line represents no action.

The technique employed for inter network communications is to assign fixed message IDs for inter network communications. These IDs or Slot numbers are highlighted in Fig. 8 and Fig. 9.

In the example of Fig. 9 one round is made up of three cycles. The pattern is repeated after every three cycles. Nodes in time-triggered networks know a priori when a certain message ID has to be transmitted and also when a certain message ID is expected to arrive.

In cycle 1 the Normal Network Node 1 transmits Slots/IDs 1, 2 and 3 and receives IDs 4, 5 and 6. The Network Host Processor Node receives IDs 1, 2 and 3 and transmits IDs 4, 5 and 6. It should be recalled that each ID is assigned with messages going to or coming from other time-triggered networks through the gateway core. In cycle 2 the Normal Network Node 2 transmits Slots/IDs 1, 2 and 3 and receives IDs 4, 5 and 6 and the network host processor receives and transmits the same sequence as it did in cycle 1.

In cycle 3 the third node follows the same transmit and receive pattern as Node 1 and

2.

It is clear from the above description that each node will communicate its internetwork messages in its own cycle and the network host processor will continue to operate the same way in all the cycles.

The rate of inbound and outbound traffic will remain predictable and constant due to the fact that the host processor continues to operate in the same manner in all communication cycles. This also ensures that the gateway core will always be able to operate in a full non-blocking way as traffic parameters will remain within a known maximum limit.

The architecture can be realized through RTL coding in a HDL. For the prototype implementation the RTL coding of the gateway core, FIFOs, and associated interfaces were programmed in VHDL, The inventors have implemented this architecture in an FPGA.

Test Bench Verification

For verifying the architecture a test-bench in VHDL was developed that acted like a virtual frame generator/analyser. A hardware frame generator/analyser was also developed that was used for verifying the OSEK based implementation of the architecture. Fig. 10 is a block diagram of the hardware frame generator/analyser. In concept the VHDL test-bench and the hardware frame generator/analyser are the same, as their basic function is to send and receive frames to and from the gateway core. Before the architecture of the host processors 3 could be verified, the switching core had to be verified to ensure that it is bug free and operates according to specification. The functionality of the switching core was verified using a separate test bench that had only the switching core instantiated in it. This test-bench also had VHDL procedures that would write frames to the switching core and also read frames from it. These procedures generated frames conforming to the gateway core format. Thus, the proper routing of the frames within their time boundaries was checked using a waveform viewer.

Once the gateway core was verified the complete design i.e. with the network host processor and the UART, was instantiated in the main test-bench. In the test-bench, frames conforming to the gateway format were generated and analysed in serial format. The functionality of the gateway was thus verified in software by simulating the VHDL core along with its test-bench.

Verification through a fast FPGA prototype

Once the simulations were completed the core was synthesized for a Xilinx Spartan-II FPGA. To check the proper functioning of the architecture in hardware the four UARTS embedded within the design were used to interface to a PC with 4 serial ports. Frame Generation and analysis software was developed for the PC that would send and receive frames to and form the gateway.

The test software can generate frames conforming to the gateway format via a PC's serial port. The user can define with millisecond resolution the period of frame transmission. This functionality emulates the principle of message transmission in time-triggered networks i.e. message transmission on a common time base. The software is also capable of retrieving received frames according to a user-defined timebase. This functionality emulates the principle of frame reception in time- triggered networks i.e. message reception on a common timebase.

The software can be configured to generate varying frame patterns with different header and data fields. Frame analysis functionality is also built in the software, where a transmit counter keeps a track of the number of frames sent and receive counters keep a track of numbers of frames received from each of the four gateway ports. The receive counters only increment if the new frame data is different from the previous data.

The gateway was synthesized for a Xilinx Spartan-II FPGA and was tested with a master clock frequency of 40 MHz. Frames generated by the test software were triggered by a 20 ms timer and the receive timer was set at 3ms. The test application was set up to detect 128 correctly routed multicast frames. The use of multicast frames ensured that a worst-case scenario, i.e. when all frames sent are destined for all the ports, could be checked in real hardware. The speed of data for these tests is relatively slow, as compared to real networks, but the testing has validated the logic of the concept and the prototype design.

The results of the tests confirmed that the architecture could handle time-triggered messages in a reliable manner with minimum latencies, without loss of frames. For testing of the gateway core for real-time operation the following parameters were used:

The Baud Rate for the UARTS was 38400 Bps (26 micro sec for 1 bit) 1 frame = 10 bits (8+l+l)*4 = 40 bits 1 frame Length = 40 * 26 = 1040 micro sec = 1.040 ms 2 frames in 2.080 ms

The input frame rate for full non-blocking operation under worst-case conditions (all multicast frames) should be 4 times slower than what the output port can handle due to the fact that one frame is addressed to all four ports including the port of frame arrival. However in the reference NHP implementation two frames are retrieved every time the UART buffer is half full (8 bytes equivalent to 2 gateway frames - Xilinx UART buffer has a total of 16 bytes). Therefore the tolerable frame rate with the present NHP implementation has to be 8 times slower than the maximum frame rate at the output ports in order to ensure deterministic operation of the gateway core. The minimum frame period for full non-blocking operation with present NHP implementation:

> 8*2.080 = 16.64 ms ~ 17 ms

Under such a configuration anything greater than a 17 ms frame period would be tolerable by the Gateway Core for reliable operation. Therefore a frame rate with a period of 20 ms was selected and the results were as expected, i.e. that the gateway Core functioned in full non-blocking manner without loss of frames.

The results show that the gateway architecture can support the desired traffic throughput without loss of frames once the message schedules in individual networks are set up as explained in the section Inter-Network Traffic Schedule.

It will be appreciated that the invention provides a gateway which achieves, with a simple architecture, real time and complete interfacing between networks including time triggered networks.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims

1. A gateway for interfacing between communication networks including at least one time-triggered network, wherein the gateway comprises: a plurality of network interfaces (2, 3, 10, 13), each having a port for interfacing with an associated one of said communication networks, and a hardware state machine controller (4, 12) for routing messages within the gateway between the network interfaces in real time.

2. A gateway as claimed in claim 1, wherein each network interface comprises a host processor (3) for real time bit-by-bit translation between the protocol of the associated network and a gateway internal format.

3. A gateway as claimed in claim 2, wherein the host processor packetizes leading translated bits to the gateway internal format while trailing bits are being translated.

4. A gateway as claimed in claim 3, wherein each network interface comprises a receive interface device (13) for receiving internal-format bits.

5. A gateway as claimed in claim 4, wherein each network interface comprises a receive FIFO buffer (14) for receiving internal-format frames from the receive interface device (13) and for routing them to a register (12).

6. A gateway as claimed in any of claims 2 to 5, wherein each network interface comprises a transmit device (10) for transmitting internal-format frames to the host processor (3) as the host processor (3) is translating them.

A gateway as claimed in claim 6, wherein each network interface comprises a register (12) for receiving messages from another network interface and a transmit FIFO(l l) for buffering messages between the register (12) and the transmit device (10).

8. A gateway as claimed in claim 7, wherein the registers (12) are interconnected in a routing ring, the registers (12) read frames from the receive FIFO buffers, and the registers route the frames in the routing ring, and write the frames to the transmit FIFO buffer (11) which is the destination for the frame before translation to the protocol of the associated network.

9. A gateway as claimed in claim 8, wherein the host processors insert a source identifier, a destination identifier, and a data field in each internal-format message, and the registers (12) write messages to the transmit FIFO buffers (11) according to the destination identifiers under state machine control.

10. A gateway as claimed in claim 9, wherein the data field contains a frame sequence identifier.

11. A gateway as claimed in claims 8, 9, or 10, wherein the FIFO buffers (11, 14) operate according to a circular buffer model, each having a head index, a tail index, and a frame count.

12. A gateway as claimed in claim 11, wherein the head index and the frame count are incremented upon writing to the FIFO buffer, and for every frame read the tail index is incremented and the frame count is decremented.

13. A gateway as claimed in any preceding claim, wherein the gateway operates without an internal clock, as it is self-synchronized to external traffic.

14. A gateway as claimed in any preceding claim, wherein the gateway operates at a speed greater than the product of the number of ports and the port speed.

15. A gateway as claimed in any preceding claim, further comprising a processor for executing a scheduling matrix, and for controlling the network interfaces and the controller to transfer messages between the networks in a time deterministic manner.

16. A gateway substantially as described with reference to the drawings.