0 Introduction Foundation Fieldbus (FFH1) is a bidirectional, serial, fully digital industrial field-level network control system. FFH1 consists of two parts: the HSE part and the H1 part. The former is a fieldbus network built on standard 100Mbps Ethernet, primarily used for configuration, diagnostics, and other management functions; the latter is a fieldbus network built on a new token bus, primarily used for communication at the field instrument level, for performing the lowest-level loop control, alarms, and other functions. These two network parts are connected via link devices. The HSE part uses real-time information provided by the H1 part to manage the entire network system. Since the H1 part is located at the lowest level of the entire network control system and is directly used to complete field control tasks, the reliability and real-time performance requirements for this communication system are extremely high. Reliability is ensured through redundancy, data verification, and error correction mechanisms in the protocol stack software, while real-time performance mainly relies on the token mechanism of the H1 network communication. According to the communication schedule, the FFH1 token mechanism ensures that real-time data is sent to the network at a predetermined time. In contrast, standard Ethernet suffers from poor real-time performance because its CSMA/CD bus access mechanism makes it unpredictable when data frames will be sent to the network. This paper briefly introduces the network layer in which the token mechanism operates, focusing on the token management mechanism from the perspectives of both token administrators and token users. Finally, it analyzes two methods to improve network performance. In the development of the FF protocol stack software, this token management mechanism was implemented using a real-time operating system, thus ensuring real-time network communication and laying the foundation for implementing upper-layer functions. 1. Network Structure The entire FFH1 network can consist of multiple network segments connected by bridges. The network structure differs depending on the network layer. A token is a concept at the data link layer. Within a network segment, the physical topology can be bus, daisy-chain (generally not used), star, or a combination of bus and star topologies. Physical signals within a network segment are broadcast throughout the segment. However, at the data link layer, the logical structure of all these topologies is the same: a token bus structure. From the data link layer perspective, network devices can be divided into basic devices, master devices, and bridges. Only the first two are relevant to the token mechanism; that is, token transmission and use only occur within a single network segment. The master device can become the token management center, called the Link Activity Scheduler (LAS), through contention. The master device that fails to win the competition becomes a redundant backup of the LAS. All devices can be token users. Therefore, the network logical structure seen from the data link layer is shown in Figure 1. Figure 1: Network Logical Structure of H1 Network Segment Figure 2: Basic Principles of the Token Mechanism The FFH1 network segment adopts a centralized token management method. There is one and only one Token Manager (LAS) on a network segment. All devices on the network segment (including the LAS itself) can only send data to the network when they hold a token. Figure 2: Token Relationship Diagram There are three types of tokens on the network segment: scheduling tokens, authorization tokens, and acknowledgment tokens. When a certain token is in use, this token is called the dominant token on the current network segment, so the dominant token is the right to use the bus. These three tokens are not equal; one token generates another token, and the generated token is returned to the token that generated it after use. This relationship is shown in Figure 2. The scheduling token has the highest priority and can only be held by the LAS. This token is used to initiate periodic communication and generate the other two types of tokens. The authorization token is used for aperiodic communication and to generate response tokens. The response token is simply a device holding the other two types of tokens granting another device temporary communication rights; the device holding the response token can only send one frame. According to the scheduling table, when periodic communication is to be conducted, the scheduling token held by the LAS becomes the dominance token. The LAS sends a CD frame to the device that wants to publish data, and generates a response token within that device. This response token becomes the dominance token, and the device uses this response token to publish a data frame on the network. During aperiodic communication, that is, during the intervals between periodic communications, the LAS holding the scheduling token sends a PT frame to other devices, and generates an authorization token within that device. This token becomes the dominance token, and the device uses this token to send data within a specified time. During this period, the device can also issue response tokens to other devices (the frame used to generate the response token is not necessarily a CD frame; it could be an RQ frame, etc.), thus granting another device temporary communication rights. The entire process is shown in Figure 3. In Figure 3, the scheduling token is the dominance token during times 1, 4, and 6; the acknowledgment token is the dominance token during times 2 and 7; and the authorization token is the dominance token during times 3 and 5. The LAS token issuance mechanism: LAS is a token management center on a network segment, issuing authorization tokens (and acknowledgment tokens if necessary) and acknowledgment tokens. According to the scheduling table, at the start of a specified periodic communication, LAS issues an acknowledgment token to the designated device via a CD frame. Then, it begins monitoring the network. If no data appears on the network within a token recovery time, LAS reclaims the acknowledgment token and uses the scheduling token for the next activity. Between periodic communications, if there is sufficient time, LAS issues authorization tokens sequentially via PT frames according to the device address from smallest to largest. Then, it begins monitoring the network. If no data appears on the network within a token recovery time, LAS reclaims the authorization token and uses the scheduling token for the next activity. Otherwise, when a frame is transmitted on the network, the above process is repeated until the authorization token is returned. The entire process is shown in Figure 4. Figure 4 shows the monitoring process after LAS issues an authorization token. If it finds that the remaining time before the start of the next periodic communication is insufficient to issue an authorization token, it waits for the start of the next periodic communication. If necessary (when there is no data transmission on the network for too long), it broadcasts an IDLE frame to the network segment to indicate that LAS is still active. The entire token issuance process of LAS is shown in Figure 5. Figure 5 LAS Token Issuance Flowchart 4 Device Token Usage Mechanism A device that receives a token has the right to send data to the network. The device sends different data depending on the two types of tokens received. If the device receives a response token from LAS in a CD frame, the device sends the data in the buffer specified in the token to the network segment. If the device receives an authorization token from LAS in a PT frame, the device has control over the network segment for a specified period of time. During this period, the device's data link layer searches for data that is already queued. If it finds data with a priority (see Part 6 for a description of priority) that is higher than or equal to the token's priority, it sends this data frame to the network. If there is still time remaining after all data has been sent, the token is piggybacked back in the last data frame. If no matching data is available to send, the token is returned directly using an RT frame. If the allotted time is insufficient to send all requested data, as many data frames as possible are sent within the allotted time, and the token is returned using an RI frame, while requesting more time from the LAS. 5. Some Measures to Improve Network Performance The FF H1 data link layer can improve network performance through the following measures. 5.1 Priority Three priority levels are assigned to the non-periodic data to be sent by each device: highest, medium, and lowest. A priority level is assigned based on the urgency of the data. By dynamically changing the priority of the authorization token, higher-priority non-periodic data can have more opportunities to be sent to the network segment when communication is busy. As described above, data can only be sent if its priority is higher than or equal to the token's priority. Therefore, when the network is busy, increasing the token's priority can restrict the sending of low-priority data and give higher-priority data more sending rights. Network busyness can be determined as follows: Record the time V (ATRT) taken to complete the previous authorization token issuance cycle on the network segment. If this value is less than another value indicating network busyness, V (TTRT), it means the network is idle, and the token priority is reduced; when V (ATRT) is greater than V (TTRT), it means the network is busy, and the token priority is increased. The first token sent when LAS starts scheduling always has a medium priority, and the token priority is the same within a token issuance cycle. The whole process is shown in Figure 6. Figure 6 Token Priority Migration Figure 5.2 Token Holding Time When LAS issues an authorization token to a device, it specifies the time that the device can use the token, which is the token holding time. For communication stack users, the network time occupied for token issuance and return is a waste because no useful data is transmitted on the network during this time. For example, if a device has 50 frames of data to send, but the token holding time specified in the authorization token only allows one frame to be sent, then token sending and receiving will occupy a large proportion of network time, and it will take 50 tokens to complete the data frame transmission. If the token holding time granted to the device allows for 50 frames, then only one token is needed to complete the data transmission, greatly improving network utilization. FF H1 uses the RI frame to achieve this. When a device using an authorization token finds it has a lot of data to send and the token holding time is insufficient, it sends as many data frames as possible first, and finally returns the token to the LAS with an RI frame, requesting more token holding time. The next time the LAS issues an authorization token to the device, it will provide the requested token holding time to the device, provided there is sufficient remaining network time. Furthermore, since large amounts of data generally do not occur on the FF H1 network segment, only when domain uploads and downloads are performed to a device, this method prevents a single device from occupying network time for an extended period, severely impacting the non-periodic communication of other devices on the network segment. 6 Conclusion The various communication protocol stack layers above the data link layer do not concern themselves with when or how the bus is accessed; they always assume the bus is available and directly send data transmission requests. At the data link layer, the LAS and other devices on the network segment coordinate when and how data is sent using tokens. The protocol only specifies the basic token passing rules. The specific token parameters can be determined by the network configuration, such as how much V (TTRT) indicates that the network is busy. Even the protocol implementer can add some measures to improve network performance, as long as these measures do not affect the protocol consistency and device interoperability. This requires further research. References: [1] Fieldbus Foundation. Foundation Fieldbus Technical Overview[M]·FD043 Revision 3. 0., 2003· [2] IEC. Digital data communications for measurement and control Fieldbus for use industrial control system Part 4: Data Link Protocol Specification, IEC 61158-4[S].2003. [3] Fieldbus Foundation. FoundationTMSpecification Data Link Services Specification Subset [S]. 2001. [4] Fieldbus Foundation. FoundationTMSpecification Data Link Protocol Specification[S]. 2001. [5] Fieldbus Foundation. FoundationTMSpecification System Architecture [S]. 2003.