Abstract: Fieldbus control systems are a novel type of distributed control system, integrating control, computer, and digital communication technologies. Foundation Fieldbus, with its technological advantages, holds great promise as a mainstream development trend. Its most significant feature is the application of function blocks to achieve fully distributed control.
Keywords: fieldbus, function block, scheduling, application process, virtual field device
The Function Block Schedules in FF SystemABSTRACTION: Fieldbus-Control system is a kind of new Distributed-Control system, and a kind of integrated technology based on Automation-Control, Computer and Digital Communication. With great advantage in technology, Foundation Fieldbus technology is coming to be the major one. And its main feature is to implement distribute control by using function blocks.
KEYWORDS: Fieldbus, Function Block, Schedule, Application Process, Virtual Field Device
1 Introduction
Fieldbus , which emerged and developed in the late 20th century, is a communication network for interconnecting intelligent devices in fields such as process automation, manufacturing automation, and building automation. As the foundation of factory digital communication networks, it connects production process sites and control equipment, as well as with higher levels of control and management. Fieldbus control systems are open, secure, low-cost, and novel fully distributed control systems. They are a comprehensive technology integrating control, computer, and digital communication technologies, becoming a hot topic in automation technology development and leading to profound changes in automation system architecture and equipment.
Standardization of fieldbus technology started relatively late, resulting in the current coexistence of multiple fieldbus technologies. Among them, those with strong capabilities and influence include Foundation Fieldbus (FF), LonWorks, Profibus, HART, and CAN. Each has its own unique characteristics and has developed its own advantages in different application areas. Among these, Foundation Fieldbus, with its advanced technology and strong member companies, has become a highly competitive fieldbus technology.
Foundation Fieldbus systems consist of interconnected digital intelligent field devices and control/monitoring equipment. Together, they provide I/O and control/automatic processing. Each field device performs a part of the system's functionality, including implementing one or more time-critical applications, such as acquiring sensor data and executing control algorithms. Each field application is implemented by a set of device functions called a Function Block (FB). These applications are called Function Block Application Processes (FBAPs).
2. Definition and structural characteristics of function blocks
Function blocks represent basic automation functions. Each function block processes input parameters and, based on its internal parameters, executes a specific algorithm to produce usable output parameters. Therefore, a function block consists of inputs, outputs, internal parameters, and the algorithm that applies these parameters. Function blocks are identified using a tag (FB Tag) and an object dictionary (OD) index. The function block tag provides a symbolic reference to the function block and should be unique within a system. The object dictionary index is used for fast access to the function block. The object dictionary index is only useful within the resource containing the function block. Function block parameters define the inputs, outputs, and internal parameters used for function block operations. These parameters can be accessed over a network, and input and output parameters exchange data through connections between function blocks. Internal parameters are used to define private parameters of the function block; although they are network visible, they do not participate in function block connections. Function block parameters are identified using a device description (DD) Member ID and an object dictionary index. The DD Member ID corresponds to a tag, which must be unique throughout the system; the object index is used to access a function block parameter through the FMS service. The description of parameters can be extended using DD (Design Components). Function block definitions and associated DD descriptions are combined into a set of parameters that generally depend on the application domain, device function, and vendor definition.
Different types of devices may have different function blocks depending on the functions they perform. Typical function blocks include analog input (AI), analog output (AO), and PID control function blocks. Each function block has specific parameters and algorithms to achieve a specific function.
A function block application structure defines the internal components of a function block application and specifies the interfaces of these components within an application or between multiple applications. This structure can be designed as follows:
• Design and execute function block applications
• Configure and integrate function blocks into field devices
• Interoperability between functional blocks during system runtime.
Some or all components in a device can be predefined by the manufacturer. Component parameters can be modified through device configuration. Additionally, the device must support standard function block services (including read/write services for function block parameters). Through these services, components such as function blocks and transform blocks can be accessed or modified.
3. Execution and Scheduling of Function Blocks
The execution of a function block is activated by an event input. This event could be:
• Scheduling: Scheduling defines when a function block is first triggered to execute.
• End of function block execution: The completion of a function block within the same device may trigger the execution of other function blocks.
• Vendor definition: The execution of a function block can be defined by the manufacturer.
In Foundation Fieldbus, the most common element is the scheduled execution function block. To ensure the correctness and real-time performance of the scheduled execution of a function block, it must meet the following characteristics:
• Each functional block in the system uses the same time, namely the system time. Only a unified time standard can guarantee the accuracy of the execution time of each functional block.
• The measuring equipment samples periodically to ensure the accuracy of the input parameters for continuous control.
• Input and control parameters should remain consistent during function block execution.
• The time interval between the generation and application of output parameters must be less than the execution time of the control loop. This time interval includes the time spent transferring data between function blocks and the time spent waiting for the function block to start execution after the data transfer is complete.
These characteristics require adjustments to the execution of function blocks in the following three aspects:
First, time synchronization must be ensured throughout the entire system to guarantee the synchronous execution of functional blocks.
Second, it is necessary to ensure that the output parameter is generated before other functional blocks need this parameter.
Third, it is necessary to ensure the synchronization of function block scheduling and data transmission on the bus to ensure that output parameters are transmitted at the appropriate time.
These three aspects are achieved through clock synchronization, function block scheduling, and network transmission scheduling, respectively.
In the FF system, application clock synchronization is achieved through clock publishing managed by the system. The time publisher in the system management periodically publishes application clock synchronization messages to field devices. These messages include the application clock time (AP time) and the link time (LS time). The system management kernel (SMK) samples the link time and application clock time, combining them into an application clock message for transmission. Receiving devices use this message to adjust their local application time, achieving application clock synchronization. The scheduling of function block execution is also managed by the system management kernel, achieved through configuring the FB Start parameter in the system management information base.
The definition of FB Start is as follows:
struct
{
unsigned long start_time_offset;
unsigned short fb_object_index;
unsigned long vfd_ref;
}
FB_START_ENTRY;
`start_time_offset` represents the start time of the function block execution, and this parameter is a time deviation relative to the macro cycle. Its unit is 1/32 millisecond. The macro cycle refers to the execution time of the function block application across the entire network. The scheduling of function blocks and data transmission are periodically scheduled based on the macro cycle. Its unit is also 1/32 millisecond.
fb_object_index represents the data dictionary index of the function block associated with this FB Start item, i.e., the starting index of the function block to be executed. This parameter is used to identify the function block to be executed.
vfd_ref indicates the VFD number associated with this FB Start, that is, which VFD the function block to be executed is in.
Data transmission scheduling is handled by the Link Activity Scheduler (LAS). After configuration, a scheduling table is generated in the LAS device. This scheduling table has a specific format, and the LAS schedules data transmission by reading this table. Specifically, it sends a Force Token (CD) message to a specific device at a specific time to force the field device to send the real-time data to be transmitted. This timing is strictly accurate, ensuring that the correct data is transmitted at the required time. Upon receiving the CD, the field device immediately publishes the data in its buffer to the bus. The data in the buffer is written after the function block is executed.
The following example uses a typical PID control loop to illustrate the scheduling of function blocks in an FF system.
Figure 1. A typical PID control loop
Figure 1 shows a typical PID control loop. The AI and PID function blocks are located in one device, while the AO function block is in another. The control process is as follows: the output (OUT) parameter of the AI function block is sent to the input (IN) parameter of the PID block; the output (OUT) parameter of the PID block is sent to the cascaded input (CAS_IN) parameter of the AO block; and the back-calculation output (BKCAL_OUT) parameter of the AO block is sent to the back-calculation input (BKCAL_IN) parameter of the PID block. This completes a PID closed-loop control.
The resulting scheduling is shown in the following diagram:
Figure 2. Scheduling of the PID control loop
In Figure 2, the Loop Time (i.e., macro cycle) is 1 second. The blue box represents the execution time of the function block, and the red box represents the time when the function block publishes data on the bus after execution. Since the AI function block and the PID function block are in the same device, the parameter transmission for this part is implemented through the local interface and is not visible on the bus. Therefore, this part of the data transmission is not shown in the figure.
After configuration, the device (Device A) containing the AI and PID function blocks should have two FB Start entries. One corresponds to the execution of the AI function block, where start_time_offset should be 0 and fb_object_index is the starting index of the AI function block. The other corresponds to the execution of the PID function block, where start_time_offset should be 640 (20ms). That is, at the beginning of a macro cycle (offset zero), Device A's SMK scheduler begins execution of the AI function block, derives the output value, and sends it to the local PID function block. Twenty milliseconds after the start of the macro cycle, Device A's SMK scheduler begins execution of the PID function block, applies the input value from the AI, calculates the output value, and places it in a buffer, awaiting the data transmission schedule token (CD). The LAS, based on the schedule table, issues a forced data transmission token (CD) at 40 milliseconds after the start of the macro cycle to publish the data in Device A's buffer to the network. Device B has only one AO function block to execute, so only one FB Start item is generated during configuration to correspond to the execution of the AO function block, and its start_time_offset should be 1280 (120 milliseconds). After receiving data from the PID function block of Device A, the AO function block of Device B starts execution at 120 milliseconds after the start of the macro cycle, scheduled by Device B's SMK, and generates output data to operate the actuator. At the same time, it generates a back-calculation output (BKCAL_OUT) value and puts it into the local buffer, waiting for the data transmission scheduling token (CD). Meanwhile, LAS, according to the scheduling table, issues a forced data transmission token (CD) at 140 milliseconds after the start of the macro cycle to publish the data in Device B's buffer to the network. The PID function block in Device A uses this back-calculation value and the AI output value to adjust the output value after execution, thus completing a PID closed-loop control.
4. Conclusion
Function blocks and their scheduling in Foundation Fieldbus are fundamental to Foundation Fieldbus applications and are also one of the characteristics and innovations of Foundation Fieldbus systems. Understanding function block scheduling allows for a deeper understanding of the concepts of openness and interoperability in Foundation Fieldbus.
In addition, the connection of function blocks is achieved through the link object in VFD, which is not explained in detail in this article due to space limitations.
5 References
1. Fieldbus Foundation, FoundationTM Specification: System Architecture. 1999
2. Fieldbus Foundation, FoundationTM Specification: System Management. 1999
3. Fieldbus Foundation, FoundationTM Specification: Network Management. 1999
4. International Standard, IEC 61158-4. Second Edition. 2000
