suitable for real-time applications. In this paper, we add a layer of Real-Time Communication Control (RTCC) protocol on top of Ethernet. The RTCC pro

Transcription

1 A Hard Real-Time Communication Control Protocol Based on the Ethernet WANG Zhi-Ping 1, XIONG Guang-Ze 1, LUO Jin 1, LAI Ming-Zhi 1,and Wanlei ZHOU 2 1 Computer Science and Engineering College, University of Electronic Science and Technology, Chengdu , The P.R. China 2 School of Computing and Mathematics, Deakin University, Clayton, VIC 3168, Australia wanlei@deakin.edu.au Abstract. In this paper, we present an Ethernet-based protocol called RTCC that provides a good basis for distributed hard real-time applications without requiring any modications to existing Ethernet hardware. Two novel mechanisms, the command / response multiplex transmission and a bus table, are introduced in RTCC in order to schedule the channels. Performance measurements from experiments on a 10 Mbps Ethernet indicate that RTCC has a satisfactory determinism. 1 Introduction A real-time system is one in which the correctness of the system depends not only on the logical results, but also on the time at which the results are produced. In hard real-time systems, results must be produced within an ordained timing constraint, otherwise, the results will lose their usability. For safety-critical systems, incorrect operations can lead to the loss of life or other catastrophes. With the increasing use of distributed hard real-time systems (such as command and control systems, image processing and transmission, and industrial process control, etc.), the ability of computer networks to handle hard real-time message trac is becoming more and more important. Two requirements, high bandwidth and determinism, are critical to any hard real-time applications [8]. Many existing networks, however, have either low bandwidth, or are non-deterministic, and therefore do not meet the requirements of the development of distributed hard real-time systems [1, 2, 6]. Ethernet is the most popularly used network nowadays. It is fast (10Mbps, 100Mbps or 1000Mbps Ethernet), simple and widely available. Ethernet meets the IEEE standard, in which thechannel access is random, since it is for a CSMA/CD LAN. This property leads to the unpredicable timing when sending and receiving data on the network. Therefore Ethernet is non-deterministic, which is often inappropriate for real-time work. However, the advantages of Ethernet (popularity, high-speed, and simplicity) justify the need to make it

2 suitable for real-time applications. In this paper, we add a layer of Real-Time Communication Control (RTCC) protocol on top of Ethernet. The RTCC protocol meets the requirements of hard real-time communication well.it also has a good real-time performance and meets the requirements of reliability for hard real-time systems. By using the RTCC protocol, an upper layer protocol can provide high-speed, reliable and hard real-time services to applications without any modication to the original Ethernet hardware. The rest of the paper is organized as follows. In Section 2, we introduce the architecture of our RTCC protocol. The detailed components of the RTCC protocol are described in Section 3. Section 4 presents the result of performance measurement and analysis. Section 5 concludes the paper. 2 RTCC Protocol Architecture For traditional networks, maximizing throughput or minimizing the average message delay are the most important performance criteria. In the hard real-time domain, however, the main focus is on satisfying the timing constraints of individual messages. In general, time constraints of messages are period, deadline, and so on. To meet the time constraints, hard real-time messages must be properly scheduled for transmission. For the purpose of understanding its real-time performance, it is convenient to consider an MAC protocol as consisting of two processes: an access arbitration process and a transmission control process [5]. The access arbitration process determines when a node can send a message over the channel. The transmission control process determines how long a node can continue to send messages over the channel. Ideally, any protocol for hard real-time communication should combine both an appropriate access arbitration process and an appropriate transmission control process. Many researchers, however, have tended to concentrate more on one process than the other. For example, the work on synchronous message transmission with the IEEE protocol has emphasized the access arbitration process. The work on synchronous bandwidth allocation for the Timed Token protocol [6], however, has emphasized the transmission control process. By comparing Ethernet and other network communication protocols, we have found that Ethernet nodes ask communication media positively, while it is the general case that real-time networks can only send data after the usage right of communication media is passively granted (e.g., a token or a command is received), so that conict of network access will never happen. Hence, neither Token-Ring [1] nor Timed Token protocol [6] enjoys ideal real-time performance. We propose an Ethernet-based communication protocol called Real-Time Communication Control (RTCC) protocol that provides a good basis for distributed hard real-time applications without the need to modify the existing Ethernet hardware. The RTCC protocol sits on top of the existing Ethernet MAC protocol, providing high speed and hard real-time communication network services to the upper application layer. The main advantage of the RTCC

3 protocol is that it transforms the popular Ethernet MAC protocol into a protocol that meets the requirements for hard real-time applications. Through the use of the RTCC protocol, applications can achieve hard real-time performance services without requiring any modication of existing Ethernet hardware. Figure 1 depicts this architecture. Fig. 1. The network model The RTCC protocol adopts the main-sub command / response multiple access transmission mode. Nodes are categorized into twotypes in RTCC protocol. One is Bus Controller (BC), the other is Remote Terminal (RT). There is only one BC, and the rest are all RTs. The startup of message transmission and management of Bus are tasks of BC. The length and the receiver of the data will be sent by the RT immediately. Obviously the access arbitration process and transmission control process are all accomplished by BCinRTCC. By integrating the two processes and ensuring they work in phases, not only the sending time of a node's data can be assured, but also the bus time that is used by a node will be controlled. Five components are dened in RTCC. They are frames, messages, bus table, error control and ow control, and network services for the upper layer. Their details are described in the next section. 3 The RTCC Protocol Components 3.1 Frames Three types of frames are dened in RTCC. They are command frames, data frames and response frames (Figure 2). Command frames can only be sentbythe BC to an RT, requesting the relevant RT to execute an operation. Command frames can be further categorized into data-send command frames and mode command frames. Both BC and RT can send data frames. Response frames can only be sent byanrt to the BC, as the response to a command frame from the BC, indicating current states of an RT.

4 Fig. 2. RTCC frame format 3.2 Messages RTCC refers messages as a sequence of transmission that includes command frame, response frame, data frame and state response intervals. A message is the basic unit in the transmission of the network. The transmission process of a message indicates a whole process of data transmission. There are seven classes of messages dened in RTCC. They are classied into two types: pointto-point messages and broadcast messages. Based on command frames, they can be categorized into data transmission messages and mode command messages as well. A message is called a mode command message when the command frame is a mode command frame, or data transmission message when the command frame is a data-send command frame. There are ve data transmission messages in all: data transmission: BC! RT, RT! BC, RT! RT, and data broadcast: BC! RTs, RT! RTs. There are two mode command messages, which are used for the management of the network. In the process of message transmission, if the message is point-topoint, once a data or command frame is received, an RT will send the response frame to BC at the rst time. However if the message is broadcast, RTs do not send state frames, but the BC will poll individual RTs using the mode command. The above mechanisms are used to guarantee good predictability and high reliability, critical to a hard real-time protocol. State messages sent back from RT enable the BC to nd errors or exceptions of RTs, so corresponding retrievals can be admitted and the reliability of the whole system is assured. Figure 3 shows the message formats of the RTCC protocol. There are periodic and aperiodic messages. In distributed hard real-time systems, periodic messages

5 are used for the transmission of periodic data streams or communication between periodic tasks of dierent nodes, while aperiodic messages transmit burst data or realize communication between aperiodic tasks. They are dened below: Denition 1. S i (T i d i D i W i ) is a periodic message in RTCC protocol. D i T i + d i T i d i 1 W i 1498 bytes. Denition 2. A i (d i D i W i ) is an aperiodic message in RTCC protocol. D i d i 1 W i 1498 bytes. In denition 1 and denition 2, T i represents the period of the message, namely the interval of the message stream's transmission. d i represents the time interval from the startup to the end of the message, i.e., the delay of the message transmission. D i represents the deadline of the message. W i is the length of data in the message, i.e., the data length the message is able to transmit. Excepting for the lack of certain periods, aperiodic messages are the same as period messages. Fig. 3. Message format We give the following formulas regarding to the performance of the protocol. Utilization of messages is represented by U. And the utilization of a periodic message S i is: U Si = d i =T i (1) If the average arrival rate of an asynchronous message A i is i, then the demand utilization of asynchronous messages is dened as U Ai = i =d i (2)

6 Besides U, another important performance criterion of messages is runtime overhead L. It is dened as L i =(d i ; W i 8=Ethernet Bandwidth)=d i 100 (3) Where W i 8 is the number of bits in a message. 3.3 Bus Table The transmission of messages on the bus is performed by the execution of bus table instructions on BC. The bus table is installed on BC only, which includes a group of optimized communication instruction blocks and relevant messages. The number of source and destination nodes, the port number of nodes, the maximum delay of instruction's execution and other relevant control messages are all dened in every instruction block. Repeated appearance of an instruction is permitted in the bus table. BC executes every instruction block in the bus table sequentially. According to every execution of an instruction, there is a transmission of a message. The instructions in the bus table are circularly executed by BC, then every message gets one chance of transmission at least, and the message's real-time transmission on the bus table is assured. Virtually the bus table is a scheduling table of the network, a key feature of real-time communication services provided by RTCC to the upper layer. The bus table can be realized in two modes: dynamic and static. A static bus table enjoys good time certainty, and can be easily realized. Its weak points are its rigid control, and modifying one one instruction can result in rearranging the whole bus table, and a new schedulability test is needed. As to dynamic mode, the bus table is arranged according to current system states. Although exible and ecient, its predictability is hard to ensure. Generally static bus tables are adopted in hard real-time communications. In the following we only discuss the static bus table. Denition 3. T (fs1 S2 S m g fa1 A2 A n g l) is the static bus table in RTCC protocol. It contains m periodic messages and n aperiodic messages, and the time length for scheduling all messages is l. The arrangement of a bus table is an NP-complete problem [11]. Dierent approaches could be adopted according to the application's requirements, such as polling or Earliest Deadline First [3] (EDF). Generally speaking, there are the following requirements for distributed hard real-time systems to network communication: 1. to assure the period and deadline of periodic messages 2. to assure the deadline of aperiodic messages and 3. to be able to process soft real-time or non-real-time messages. An algorithm for bus table arrangement is proposed here, which can ensure all the above requirements. The concrete steps of the algorithm are:

7 1. 8A i 2 T, if it is a hard real-time message, the Periodic Server [5] is used to assure its predictability, say, tochange it into periodic message S j T j D j ; d j 2. length of bus table l MAX(T i ) 3. 8S i 2 T, the interval in the bus table is the period of the message T i 4. assuring the transmission of hard real-time periodic messages rst, use EDF scheduling to transmit other messages in the idle time of bus table. We use the above algorithm to schedule the bus table: The following assertion concerns the utilization of the communication netwotk. Assertion. If the bus table T could be scheduled, then the utilization of network U should satisfy the following inequation: U = U S + U A 1 where U S = i=1 m d i U A = T j=1 n d: (4) i Parameters W and T of a message aect the arrangement a bit more. In general, the smaller W is, the easier the arrangement of the bus table becomes. By adopting the pinwheel scheduling of Sr's periodic transfer technology to transfer the period of all the messages into harmonic numbers [4], it will greatly enhance the schedulability. 3.4 Error Control and Flow Control Error control and re-transmission are realized by the response frame's receipt by the BC. By analyzing the executing process of instructions in the bus table, we have the following conclusion. Under the most complex situation, the BC should receive the response frame twice to assure the transmission of data is correct. So the maximum delay ofevery instruction set in the bus table (i.e., the time interval of every instruction's execution) is divided into two sections (t1 + t r )or three sections (t1 + t2 + t r ), here t1 and t2 are the time limit of waiting, and t r is the time left. The BC sends every frame and sets the clock at the same time. If the response frame is not received in t1 or t2, or incorrect response is received, or the response frame indicates that the receiver received the frame incorrectly, the BC transmits once more, or BC requests the RT to transmit once more, or returns a failure message to assure the correct execution of the next instruction. If the time of re-transmission is less than tr, the BC will startup re-transmission, otherwise the BC returns the error message. Re-transmission can reduce the code error ratio in the MAC layer [7]. RTCC presumes that the underlying network is reliable, so the time of re-transmission should not be too long, otherwise predictability is aected. Timely error information is also necessary in hard real-time systems. Flow control approaches in traditional networks, such as the stop-wait protocol and the sliding window protocol are not applicable in real-time networks, because they cannot assure the predictability of network data transmission. The

8 RTCC protocol adopts the non-feedback ow control approach [10] for real-time communication. Through precisely setting of sending and receiving speeds, this approach enables a receiver to take old data before new data is arrived all the time. 3.5 Network Services for Upper Layer The bus table builds real-time channels between nodes, from a sending port of one node to a receiving port of another node. One node can connect to more than one sending and receiving real-time channel. A real- time channel is equivalent to a message dened in RTCC. Each channel has its own time constraints. It is independent of other real-time channels, similar to an exclusive physical circuit. RTCC provides two basic functions for upper layer accessing real-time channels, rtccsend and rtccrecv. Upper layer software can call the two functions to transmit data directly or extend the network functions based on them, such as transmitting data of more than 1498 bytes, providing synchronous and asynchronous communication functions, etc. The two functions are dened as follows: { rtccsend(sendportnum, pbuffer, size, overwriteflag): Send data to a sending port sendportnum. Where pbuer is the address point of sending data size is equal or less than the length of data that the real-time channel can send at one time and overwriteflag stands for the written ag. If overwriteflag is TRUE, the new data can overwrite the data that has not been delivered. If it is FALSE, the new data can not overwrite the undelivered data, and the error return value indicates that the old data is not sent yet. { rtccrecv(recvportnum, pbuffer, size): Get the data from the receiving port. Where pbuer is the address point of receiving buer size is the length of received data. 4 Performance Measurement and Analysis The experimental setup of the RTCC protocol contains three Intel EV386EX embedded computers (clock rate is 25MHz, PC/104 bus). One is assigned as the BC, and the other two are assigned as RT. Each computer has a UM9008 type 10M Ethernet card that connects to a DE809-TC type HUB. The averages of message delays were measured through experiments. The delay ofpoint-to-point mode command messages is 103s. And the delay of broadcast mode command messages is 52s. All of the values measured have a deviation of 9s from the average values. The variation has no distinct relation with the dierence of data size of messages. The results show that the real-time channels have good real-time features. To the best of our knowledge, other implementations of realtime communication protocols on Ethernet are generally soft real-time (such as RETHER [9]). Therefore it is dicult to compare them with RTCC. Figure 4(a) shows the comparison of RTCC and the hard real-time communication protocol MIL-STD-1553B in terms of delays of messages as the data size of

9 messages increasing. Figure 4(b) displays the runtime overhead of messages of these two protocols. Table 1 lists some main performance criteria of several types of commonly used bus real-time networks. It can be found from table 1 that RT-Ethernet (an Ethernet using the RTCC protocol) has a good real-time performance, a higher bandwidth, and a larger data size a message is able to send at one time. So it should have a better potential to be widely adopted. Table 1. Features of Real-time Networks MIL-STD BITBUS ARCnet RT-Ethernet -1553B (RTCC) Speed (bps) 1M 62.5K-2.4M 2.5M 10M Determinism best Common Common Good Length (km) <0.09 <13.2 <6.7 <2.5 Max nodes Frame 1-32(16bits) (bits) 1-253(8bits) (8bits) Applictions Military, Industry Industry Monitor systems, aerospace, control control, Monitor systems, aviation Info systems Image processing, medical equipments Fig. 4. RTCC vs. 1553B: (a) Delay of Messages (b) Time Overhead 5 Conclusions The Ethernet-based RTCC protocol proposed in this paper uses command / response multiplex transmission and a bus table to schedule real-time messages. Through analysis and experiments we have shown that RTCC has a good realtime performance, is a simple protocol, and meets the requirements of real-time communications well. RTCC also meets the requirement of reliability for hard real-time systems. RTCC has been used in a national essential project of China in the aviation area and a monitoring system for patients in danger successfully.

10 Further work has been planned. That includes (1) Extending RTCC protocol to support multi-segment Ethernet (connected through bridges or routers), and (2) Studying the possibility of applying the RTCC in distributed soft real-time systems (such as distributed multimedia systems). References 1. ANSI/IEEE Standard 802.4: Token-Passing Bus Access Method and Physical Layer Specications ANSI Standard X3T9.5/88-139, Rev 4.0. FDDI Media Access Control (MAC) George, L. and Minet, P., "A solution preserving consistency of replicated objects with hard real-time constraints," Proceedings of the ISCA 12th International Conference on Parallel and Distributed Systems, Fort Lauderdale, FL, , Han, C. C. and Lin, K. J., "Scheduling distance-constrained real-time tasks," Proceedings IEEE Real-Time Systems Symposium, NewYork, , Malcolm, N. and Zhao, W., "Hard real-time communication in multipleaccess networks," Journal of Real-Time Systems, 8(1): 35 77, Malcolm, N. and Zhao, W., "The timed token protocol for real-time communication," IEEE Computers, 27(1): 35 41, Tanenbaum, A. S., Computer Networks. Prentice Hall, Tindell, K., Burns, A. and Wellings, A. J., "Analysis of hard real-time communication," Journal of Real-Time Systems, 9, , Venkatramani, C. and Chiueh, T., "Design, implementation, and evaluation of a software-driven real-time Ethernet protocol," Proceedings of the SIG- COMM'95 Conference, ACM, 27 37, Wang, Z. P., Xiong, G. Z., and Liu, J. D., "On the ow control problem of 1553B real-time network," Computer Science (in Chinese), 26(7): 80 82, Zhao, H., "Study of real-time connections and communications in eldbus networks," Journal of Computer Research & Development (in Chinese). 34(5): , 1997.