Romilly's HART® and Fieldbus Web Site

Fieldbus: Frequently Asked Questions

Copyright © Romilly Bowden 1999, 2000.

This page is an attempt to answer some of the questions you have asked about Fieldbus. Unless specifically stated otherwise, emphasis is on the 31.25kbps "H1" low speed version of the IEC61158-2 and FOUNDATION Fieldbus protocols.

If your question isn't answered here, you could mail it to fbfaq2@romilly.co.uk, and I'll do my best to respond.

Or better still, post your question, or any comment, on the Message Board; that way, you may get useful replies from others as well as myself.

If you disagree with any of these answers, or care to expand any of them, please say so, and together we'll improve the page.

Important disclaimer

Please note that the information given here is given in good faith, based on my understanding of the IEC61158 and FOUNDATION Fieldbus protocols. But I could be wrong! Also, please note that some answers depend on a device manufacturers' implementation choices, as well as on the protocol specifications. Before making any important decisions based on this information, therefore, YOU MUST CHECK DETAILS WITH YOUR SUPPLIER!

Physical layer questions

General questions

Why is the H1 bus speed 31.25kbps, not something different, suitable for closed loop digital control?

The H1 bus speed is not appropriate for machinery control, but it is certainly good for closed loop control in process automation, where control cycle times of 0.25 to 1.0 seconds are commonly used. A very rough estimate says you could get 50 transactions per second. If you leave half of these for unscheduled messages, you could have 4 samples per second for up to 6 control loops, or 1 sample per second for up to 20 loops (which is probably more than you would want to put on a single bus segment).

The exact figure of 31.25kbps was chosen as a binary fraction of a 1MHz crystal oscillator (divide by 32).


What sort of waveform is used in Manchester coding? Is it square or trapezoidal? How it is generated?

Logically, Manchester coding produces a square wave. For H1, IEC61158-2 specifies a current signal of about +/- 9mA into a 50-ohm load. But to reduce the bandwidth of the transmitted signal, IEC61158-2 specifies a trapezoidal waveform with rise and fall times between 0.12 and 0.25 of a bit time.

If the device is bus-powered, it simply modulates its DC current draw with this signal. Non-bus-powered devices may take 10mA, simply to provide a base for this modulation. It is allowed for a device to take less than 10mA, then ramp up to 10mA when it wants to transmit. In practice, at this time, all bus-powered devices take more than 10mA.


Is the digital signal susceptible to noise?

Yes, but not so much as an analogue signal. The fieldbus pair is balanced about ground, and (using good cable) is twisted, and shielded. All these features reduce the level of induced signals into (or out from) the bus. Unlike analogue signalling, low levels of interference have no effect whatever on the accuracy of digital transmission. Interference test criteria are specified in the IEC61158-2 standard, and suggest undetected error rates of only 1 message in 4 months, even with rather severe interference levels. (Refer to the specification, for details of these tests.)


Can you reuse the 4-20 mA wiring of an existing plant?

Yes, certainly. Although existing wiring was not designed to carry high-speed digital information, the H1 signal is robust enough to be carried on typical existing wiring. However, there are two extra considerations:

The distance limit is a result of the cable's characteristic impedance being unspecified, so reflections may occur at the ends of the cable, even though terminators are used. (For short cables, any reflection is not much delayed from the original signal, so does not cause serious distortion of the waveform.)


Do IEC61158-2 and ISA S50.02 allow redundancy in the H1 bus?

Yes. But up until now, manufacturers have chosen not to implement this option.


What kind of redundancy is possible for fieldbus system?

According to the IEC61158 specifications, redundancy is possible in H1 bus segments. However, manufacturers have chosen not to implement this capability, on the grounds of cost, bearing in mind that the number of devices on a single segment may be fairly limited in critical process applications (maybe only 4 or 6 - one or two control loops-worth).

If devices were to offer redundant fieldbus connections, there would also be discussion about how far up the protocol stack the redundancy should go within the device; even to the level of duplicating the internal microprocessor and maybe the sensor or actuator. It is very difficult to resolve these questions in a way satisfactory for a wide range of applications. It can be argued that if a particular measurement or actuator is so vital, it is better to simply add a complete duplicate device, and connect it to a different fieldbus segment.

(Note that failures within a fieldbus device should not prevent continued communication by other devices on the segment.)

It was always expected that the high-speed H2 buses would use redundant cabling, since the amount of data carried is much greater, and therefore more important to protect against loss. The HSE (high-speed ethernet) bus now proposed instead of H2 will normally be redundant, just as in commercial networks.


What are the various modes of redundancy for different topologies of fieldbus system?

The use of redundancy in a fieldbus system may be influenced by its topology, but much more by the nature of the application. In particular, the user might want to consider redundant power supplies (particularly if one power supply feeds several bus segments). Host system fieldbus I/O channel hardware could be redundant (providing two independent paths to the same bus cable), for increased reliabilty on each segment. Similarly, gateways between segments could be made redundant, if their continued operation is regarded as critical.

In a fieldbus using control in the field, an important function is the LAS (link active scheduler) which controls bus traffic. The host (if there is one) normally provides this LAS function. To survive loss of the host system, it would be worth ensuring that a back-up LAS function is available in one or more of the field devices.


Can separately-powered and bus-powered devices be mixed on the same segment of an H1 bus in an Intrinsically Safe (IS) system?

Yes, no problem. The separately-powered devices would use explosion-proof or other safety methods, but would also provide a protected IS connection point for the fieldbus.


How is half-duplex communication possible, when two instruments in a segment want to send data simultaneously in opposite directions?

The rules for access to the bus prevent two devices ever transmitting at the same time. Even when two devices have something to say, they must each wait until they are asked for a specific item of data, or receive the token from the LAS to allow an unscheduled message.


How can you connect or disconnect a fieldbus instrument from the bus without affecting the performance of the rest of the instruments? What sort of disturbance is introduced during addition or disconnection of an instrument? How can it be detected?

Just do it. (Try not to short out the bus with your screwdriver - that is a BAD THING to do!) IEC61158-2 specifies that connecting or disconnecting a device may disturb the bus electrically for not more than 10ms. That means that one message might be corrupted. Each message includes a 16-bit error-check-polynomial code, which virtually guarantees detection of the corruption by the receiver. (Depending on the type and use of the message, the receiver might ask for a repeat, or might simply ignore the message and wait for it next time around. Where the sender needs to know about this, an "acknowledged" message type can be used, and the receiver would simply not acknowledge the lost message.


What will happen if the trunk or a spur is short-circuited?

Bus-powered devices will lose power, so will not function. (Valve actuators should automatically adopt a safe position.) On return of power, they should restart automatically, with or without operator intervention as desired by the user.

Communication will be lost (even to non-bus-powered devices). On removal of the short circuit, the network will recover automatically.

The power supply should include current limiting, so it would not be damaged, and will recover when the short is removed.


Why has the H2 bus standard with 1Mbps and 2.5Mbps been withdrawn? Is it only to make it compatible with 100 Mbps fast ethernet and TCP/IP?

Basically, yes! The intention is to take advantage of the commercial development of ethernet, which has produced very low-cost, high-performance hardware. (But watch out for the distance limits on ethernet, unless you use fibre-optic cable.)

TCP/IP will be the basis of the HSE fieldbus, but is not adequate as it stands; enhancements are needed to support the desired predictability of performance.

What is the difference between a sensor bus and a fieldbus? Can control instruments (transmitter or control valve) be placed on a sensor bus?

The term "sensor bus" is used for simpler buses, where the main function is simply the transfer of a single variable representing a measurement or output valve position. On/off (contact) I/O is well handled, also simple transducers.

A full "fieldbus" is designed to allow the transfer of much more, and more complex, information, including data structures with more than just a single variable, and device management functions. Any device needing extensive configuration for a particular application is better served by a fieldbus.

Transmitters and valves may fall into either category. A simple temperature transmitter or valve positioner can certainly be designed for a sensor bus. But the more complex functionality expected in a modern transmitter or valve (such as the inclusion of diagnostics, or control functions) really needs a full fieldbus.


What is the point of removing several layers of the OSI 7-layer system?

OSI layers 3 to 6 are missing in most fieldbuses (and in HART). These are the Network, Transport, Session and Presentation Layers. The services provided by these layers in a full protocol stack are concerned with features of a full wide area network, where (logical and physical) connections are made and broken, addressing and routing functions must cover multiple networks, data packets may be corrupted or lost, and data may be carried in multiple formats. In general, these services are not needed, or can be greatly simplified, in a fieldbus where a fixed set of devices is permanently connected to a single network.

Fieldbuses usually provide only a bare minimum of these features, and include them within those layers which are fully implemented. Different fieldbus protocols vary in the extent to which such functions are provided (particularly, support for multi-segment network addressing and segmented file transfer). Features which are not provided in the protocol stack may be implemented within the device or host application itself, but this is somewhat less satisfactory, since different implementations may not inter-operate properly.

Leaving out unwanted functionality results in simpler embedded software or hardware. Since each layer has to be specified both by its function and its interfaces with the layers above and below it, this also simplifies the protocol specification.


What are the different standards for different layers of fieldbus?


What is the difference between the standards IEC1158-2, IEC61158-2 and ISA S50.02?

There is no difference! IEC recently renumbered their standards, so 1158 became 61158. The ISA SP50 work has closely paralleled the IEC fieldbus project, and the resulting standards are identical in technical content. (The formats differ slightly, for editorial reasons.)


How are MTBF and MTTR calculated in a fieldbus system?

With some difficulty! You would have to distinguish between devices (no problem - standard techniques apply) and the communication path between devices. For the communication path MTBF, you would need to know which device failures could affect it, and their likelihood. You also have to decide whether continued communication with a host system is necessary, or whether the system can continue to operate without it. Common-point failures such as a non-redundant power supply might be the major item. With redundant power supplies, the chance of physical damage to the bus might be more important.

MTTR should be estimated on the basis of replacement of failed devices, rather than repair. If a spare device is available, this can be done within a few seconds (as far as the bus connection and communication functions are concerned; physical installation is likely to be the limiting factor).


Can switches or on-off valves be connected on the same bus as continuous measurement or control devices? If this is possible, how is the 0 and 1 signal encoded?

Yes, they can. In the IEC and FF protocols, discrete variables are encoded as 8-bit unsigned integers. I assume the value would be either 0 or 1. As for all measurements, an 8-bit status value is always sent with it.


Is it possible to place a thermocouple or RTD directly on fieldbus?

No. You would always need transmitter electronics to implement the communication protocol. (However, a head-mounted transmitter may well be possible.)


How can a PLC be integrated with a fieldbus system? Can the programming station for the PLC be the same (single device) as the engineering station for fieldbus?

For IEC or FF protocols, the expectation is that a PLC would be connected at the H2 or HSE (high speed ethernet) level, since it would probably be handling a large quantity of data. A fieldbus engineering station may be directly connected to an individual H1 bus segment, or (better) it may be integrated into a host ("DCS") device, serving many segments. When HSE is used, this same connection could also be used to program the PLC.

However, even if different software and communication paths must be used, with Windows NT or some similar multi-tasking operating system, there is no reason why a single user interface should not provide both functions.


Can a PLC be interfaced directly with H1 bus?

It is quite likely that PLCs will use H1 fieldbus as an I/O path to measurement and actuator field devices. I think it is less likely that a PLC would provide an H1 connection to a host, with the PLC itself acting as a field device. HSE (high speed ethernet) would usually be more appropriate at that level.


How can a fieldbus system be implemented in an existing HART system?

HART and FF have one great feature in common - they both use Device Descriptions (DDs). This makes it possible to mix HART and FF in one system and get equivalent capabilities for device configuration, diagnostics and instrument management.

Hardware for a mixed system needs some care. Either, a host must offer both types of I/O system, or the host can use only FF, with a HART-to-FF gateway to connect to the existing HART devices. But be careful of the speed difference! In some applications, HART communication is not fast enough to use for the control variables, especially if multidrop HART is used. A gateway may, therefore, have to include analogue I/O, with conversion to digital form for the fieldbus connection. In addition, it is not yet clear (at least, to me!) how a HART device should be "disguised" as an FF device by translating its data structures, preferably based on its HART DD. As far as I know, no HART-to-FF gateway yet exists.


How is 'scan time' defined in a field bus system?

Communication to and between input and output devices in an FF bus is controlled, millisecond by millisecond, by the LAS (link active scheduler). The sequence of communication activities, which the LAS manages, is set up by the system engineer during design or commissioning. A typical configuration tool will allow you to set up a cycle time for each control loop (whether it resides in the host, or in the field devices, or partly in each), and will automatically arrange the required communication paths and schedules.

Because of the way the LAS works, all cycle times on one bus segment must be fitted into a basic "macrocycle". Probably, in most cases, this will also be the overall scan cycle time for control loops on that segment.

Don't worry that the user has to understand all this - with good configuration tools, it will just look like a good modern DCS configuration. The tool will tell you, if you ask for a cycle time which is too short to contain the communication needed to support it.


How is speed affected when all instruments in a segment start talking to each other?

For scheduled traffic, including any used for control purposes, the timing is pre-configured and always occurs as expected, under the control of the LAS. This is completely unaffected by any unscheduled traffic. In fact, instruments don't just "start talking"! What happens is that the LAS gives each device a chance to talk, in turn, during the time, in each cycle, allocated for unscheduled messages. (If there isn't enough time before the next scheduled message, they have to wait until later.)


When are 'Scheduled' and 'Unscheduled' communications used?

Scheduled communications are repeated on a regular pre-configured cycle, and include those messages carrying measurements or outputs used for control purposes.

Unscheduled communications are fitted into idle times in the scheduled message cycle, and are used for almost everything else: operator display updates, tuning parameter and mode changes, process alarms, trend reports, configuration changes, diagnostics, time distribution. (Unscheduled messages can be prioritised; for example, alarms can be dealt with urgently.)


What are the points to take care of, when placing instruments in a particular H1 bus segment?

Consider


Who controls the traffic (token) on the bus?

The LAS (link active scheduler). In the event of its failure, a back-up LAS (if present) takes over automatically.


Where is the physical location of the LAS (Link Active Scheduler)?

This is a system designer's (and device manufacturer's) choice. If there is a host DCS, the LAS will usually be in the fieldbus interface card. If not, it can be in a field device (but only "link master" devices offer this capability).

If there is an additional back-up LAS, ready to take over in the event of failure, it could be in a separate unit, but will probably be included in a field device. This is particularly useful if the control function is executed in one of the field devices, so that the loop can work well without the host system. A valve controller is a good place to have a back-up (or only) LAS.


How can MCC status be accessed on a fieldbus system?

Any field device functionality you can imagine, can be implemented in a fieldbus device. Access to any particular item or items of data is defined in the Device Description (DD), which a host should use to interrogate the device and interpret the response.

Some common device types have "profiles", using a standard DD, to reduce the work involved in development, and to achieve a degree of interchangeability. But I don't believe an MCC profile has yet been published.


How do you calibrate a fieldbus instrument?

This is really no different to any other smart transmitter, except that now, you don't have to worry about the 4-to-20mA analogue signal! You just need to read out the measurement over the bus with a suitable host device.

You need a source of the process variable: pressure, temperature (or ohms or millivolts), pH, or whatever. Typically, when you connect a known process value to the sensor, you can send a special message to the device, including the value you read, and what it should be. The field device will then adjust a stored parameter to make it so. Two values, near the ends of the instrument's working range, are usually enough, though some devices may use a more complex multi-point calibration in the factory to adjust linearity corrections, or even a temperature cycle to adjust temperature correction.

Automatic calibrators will step through this process with only minimal user involvement.


What is the length of the fieldbus message? Is it different for discrete and continuous variables?

The total message length can vary from 11 to 276 bytes (called "octets" in the fieldbus world), depending on the message type and data content. There are no extra start and stop bits, so at 31.25kbps, each byte takes 256 microseconds. The whole message could therefore take anything from about 3 to 70 milliseconds. Reading a single variable, whether it is discrete or continuous, would be near the shorter end of this range. For efficiency, several variables can often be collected into a single message.


Is FUZZY LOGIC control introduced as a standard function block in fieldbus?

Not as far as I know. But proprietary forms of this function should be available (soon?) from major manufacturers.


How can cascade, ratio, split range, feedforward and override control be achieved through fieldbus?

The first set of standard FF function blocks include PID with remote setpoint input and feedforward input, Ratio, Bias/Gain (for split range output), and Signal Selector (for override control).


Can HTG (Hydrostatic Tank Gauging) be achieved using a single fieldbus instrument? If so, how?

It should be possible. Multivariable transmitters are well-supported by the IEC and FF protocols. A fieldbus HTG instrument might connect directly to multiple sensors (pressure, temperature) or might perhaps use a local multidrop HART bus to connect to standard HART transmitters. (These could also be powered from the fieldbus, through an embedded dc-to-dc converter in the HTG device.)


How can multiple variables be measured using a single fieldbus instrument?

No problem. A device can have as many sensors as the designer wishes. And further derived variables can be calculated from these if desired. Each measured or derived variable is represented by its own Analog Input block, and is thus available to read over the fieldbus. In particular cases, it may be useful to combine several measurements into a single data array for more efficient messages.


Can a control block (e.g. PID) be inserted in a transmitter instead of in a control valve? If so, how will performance be affected?

Yes, it certainly can. There isn't much difference in performance - there is one extra message per cycle, to balance the PID output value to any limits imposed by the Analog Output Block in the valve positioner (to avoid integral wind-up).

In a cascade control application, it is quite likely that the primary PID will be located in the transmitter for the primary variable.


Should an I/P converter be built into the (fieldbus compatible) control valve? If not, how would an I/P (from a different vendor) be tested as interoperable (if at all)?

There really is no "I/P converter" any more. I would expect the "digital-to-P" function to be built into the fieldbus valve controller, as long as the valve itself remains pressure-actuated. The controller might or might not be physically mounted with the valve itself. (It would probably need position feedback from the actual valve stem.)


What does the control hierarchy for a fieldbus system look like (with control in the field)?

Your choice! Mix and match if you like; you can put the regulatory control loops in the field if you wish, with advantages of performance and reliability. Complex control functions will stay in the DCS. Supervisory functions, data analysis and links to management systems stay where they are now, but perhaps take extra data directly from field devices by pass-through via the DCS.

The right level to put any function is the lowest at which all the necessary information is available. (For example, it's probably not useful to put an interactive controller out on a bus segment, if it needs data from devices on another bus segment.)

That's all for now - send more .... !

Please let me know if you find this page useful. I'll be happy to provide links to other Fieldbus FAQ sites too.


home        top of page        consultancy
 
            Home              Top of page              Consultancy