Who's afraid of control in the field? Part 1.

Endress+Hauser Australia Pty Ltd
By Eugenio F Da Silva Neto & Peter Berrie
Friday, 13 May, 2005


The possibility of placing control function blocks in field devices is an important feature of Foundation Fieldbus technology, but what does it mean in practice? This paper takes a look at the advantages and limitations of control in the field, with illustrations from a recently completed installation.

Control in the field is no more than the execution of control function blocks in field devices. A control loop is set up by linking together the inputs and outputs of the constituent function blocks, exactly as if the control was running in the controller. The only difference is that the control blocks themselves will be 'attached' to field devices. Depending on the host system configurator, it may be as simple as dragging and dropping the function block to a field device rather than a linking device or controller (Figure 1).

As the control strategy is built up in the foreground, a list of all the links is compiled in the background. In addition to those between function blocks, links are also added to enable the parameters in each of the function blocks employed to be viewed by the host system. When the project is downloaded to the real network, every link is mapped onto a communication channel or so-called virtual communication relationship (VCR). A VCR is like a telephone line that allows two or more devices to talk to each other. In reality, three types of VCR are used by Foundation Fieldbus: publisher-subscriber, client-server and report distribution. Publisher-subscriber VCRs are used for links between blocks and are scheduled. Client-server VCRs are used for the unscheduled transfer of view data. Report distribution, also known as source-sink, is used to distribute trend and alarm information.

Communication on the fieldbus is controlled by the link active scheduler (LAS). This normally resides in the controller or linking device, but may also be located in a field device. The LAS directs the scheduled traffic by means of the so-called compel data (CD) schedule. This lists all the publishers with the exact instant and period they should be given permission to publish. The LAS synchronises control by working successively though the list, compelling each block to publish in turn. All devices requiring the published value (subscribers) are updated at the same instant in time. In the periods between scheduled traffic, the LAS handles system requests for view data, write commands or broadcasts administrative data. The time taken to refresh the process data of the complete system is determined by the macro cycle, which comprises the CD schedule plus an additional fixed period for unscheduled traffic. It should be noted that depending on macro cycle length and the amount of unscheduled traffic, it can take more than one macro cycle to update HMI data.

Optimising macro cycles

One way to optimise control is to reduce the macro cycle by cutting the scheduled traffic on the bus. This means reducing the links required to execute the control.

Figure 2 shows an example of a PID control loop, where a flowmeter is used to control the valve positioner. There are three methods by which the control can be done:

  1. When the PID loop is located in the controller, three external links are required:
    • to send data from the transmitter AI block to the PID block;
    • to send the result of the PID execution to the actuator AO block;
    • to send the back calculation data from the actuator AO block to the PID block.
  2. When the PID loop is located in the transmitter, two external links are required:
    • to send the result of the PID execution to the actuator AO block;
    • to send the back calculation data from the actuator AO block to the PID block.
  3. When the PID block is located in the actuator, only one external link is required:
    • to send data from the transmitter AI block to the PID block.

For a single loop, the savings are relatively small compared to the execution time of the blocks, especially when it is considered that loop execution is quicker in the controller. When several loops are running simultaneously, however, the execution time becomes much less significant, and the number of links becomes the decisive factor in optimising the macro cycle. Moreover, reducing the number of external links increases the loop integrity. In this respect, method 3 offers the highest integrity. From the example above it can be seen that there is an immediate advantage in placing control in the field, but are there any limitations?

Function blocks

One obvious limitation is the number and type of device function blocks available to the system. The more there are, the better they can be used to optimise the performance of the system. Most function blocks address continuous control; flexible function block technology, however, offers the possibility to seamlessly integrate continuous and discrete control (hybrid). For sequential control, there are definite weaknesses because on one hand timing is critical and on the other there is, as yet, not much support for sequential logic.

But it makes no sense to overburden a device with function blocks that will probably not find application, as this places an unnecessary load on device memory. Foundation Fieldbus offers a solution in instantiation, allowing function blocks to be created ad hoc or to be downloaded to the devices from the system library. Thus, the user has the freedom to distribute them anywhere in the field and has the flexibility to decide where the control should be. Unfortunately, not all host and device manufacturers support instantiation, and up until very recently, its mere declaration in the device configuration file (.CFX) was sufficient to cause interoperability problems. Thankfully, the Fieldbus Foundation have recognised this problem and provided a solution.

To guarantee maximum flexibility and scalability, it is also important that the same blocks are operating in the controller and devices. Where fixed blocks are in use, it must be guaranteed that they are identical throughout the system. This ensures uniform configuration and standard parameters. Although the list is getting longer, less than half of the blocks included in the FF specification are currently included in the interoperability tests. More will be included later but for the present, the remainder, plus any manufacturer specific or custom blocks, should be carefully examined with regard to device replacement strategies. If you are unsure of interoperability, ask the manufacturers whether their function blocks operate with the selected host. Most have excellent fieldbus laboratories and test in a multi-vendor environment.

Virtual communication relationships (VCRs)

As described earlier, a VCR is like a telephone line, and a device must have one line for each external link. Devices may offer fixed numbers of VCRs of a given type or may offer complete flexibility of use. Some devices support very few VCRs, a limiting factor if several links are required. This is the case in more sophisticated control strategies that cater for device redundancy, alarming or cascade control with block recovery/override facilities. While not being a knock-out criterion for control in the field, devices offering as many VCRs as possible certainly increase loop integrity and the flexibility of system design.

Multi-variable optimisation

The function block parameters of a field device are made available to the host in four standardised views. The whole view is transmitted, even if only one parameter is required. The host data base is updated by unscheduled communication in a client-server relationship, each view taking around 50 ms to transmit. When control blocks are executed in the field, the view traffic increases - a situation that can be exacerbated if the parameters selected for monitoring are in different views. If the control task dictates a short macro cycle, therefore, it may take more than one cycle to refresh the view data.

The unscheduled traffic can be significantly reduced, and hence response time improved, if the host system supports another Foundation Fieldbus specification, multi-variable optimisation (MVO). A device supporting this feature will bundle together view parameters from several function blocks into a single object. This can then be transferred in one transaction, greatly reducing the traffic on the bus. This results in a significant improvement in refresh time.

Horror scenarios

Having determined the advantages and limitations of control in the field, what about the fears?

Every control engineer has his own particular horror scenarios, but some come up more often than others. It is part of the risk analysis to assess what action, if any, should be made in response to such situations; the result might be a system similar to that shown in Figure 3. As a teaser, we include here one of four common fears, With the other three following in part 2 of the article next month. The consequences of each are discussed and possible solutions presented.

Zombies

A device dies on me in the middle of the night. I loose the loop.

This can occur in any system. The actual consequences will depend on the role of the device in the control loop. With some roles, it is possible to design a recovery strategy; with others the device must be replaced.

  1. When the device dies, function blocks awaiting input from the dead device will flag bad status, and the associated loops will assume the programmed fail-safe mode.
  2. For devices providing input to a loop, it is possible to automatically recover to a redundant counterpart by using the input selector block.
  3. Devices running control blocks must be replaced, because at the moment most host systems do not provide function block redundancy. The loop will flag bad status and any outputs will assume the programmed fail-safe mode. If the control block is in the actuator itself, the mechanical override of the valve will cause it to assume the fail-safe mode selected.
  4. All function blocks used in the dead device must also be present in its replacement. If non-standard function blocks are in use, then the replacement device must correspond exactly to the dead one. Depending on the configuration tool, it is a simple matter to set up the new device and partially download the control strategy. The loop will then run again.

Eugenio F da Silva Neto and Peter Berrie

Related Articles

Collaborative robots: the smarter way forward

Robots that can work side by side with humans are changing the way manufacturing is done.

AOG bringing the best of the best to Perth in 2015

With more than 620 companies queuing up to participate in this year's annual Australasian Oil...

Understanding data storage technologies

With the growing amounts of data being stored by industrial organisations today, understanding...


  • All content Copyright © 2024 Westwick-Farrow Pty Ltd