Over years of visiting end user sites, talking to system integrators, and internal conversations with others within our own company, tribal knowledge begins to accumulate of what works, what doesn’t and what can be improved. When working in a Foundation fieldbus (FF) context, we find some user companies swear by the technology and won’t consider anything else, while others cannot claim such positive experiences.
When considering what differentiates enthusiastic users from those who gave up, many of the same top 10 points emerge. This series of articles provides details for each point. Here are the Top 10, plus one. (Items 1-4 are discussed here.)
1. Wiring practice pitfalls
2. Terminators
3. Power supplies
4. Stick with tested and registered products
5. Incorrect DD/CFF fles
6. Using the link active scheduler
7. Device addressing
8. Choosing between publisher-subscriber and client-server communication
9. Traditional project management techniques may not apply
10. Mismatch of work processes
11. Misunderstanding the value proposition
5. Incorrect DD/CFF Files
Let’s say you have a malfunctioning pressure sensor and you decide to replace it with an older unit from inventory. Unfortunately, you discover that it has an older device description (DD) or capabilities file, also known as a common file format (CFF) file. (It’s worth noting that he device descriptor (DD) file allows operation of devices from different suppliers on the same fieldbus with single host system. The common file format (CFF) is an ASCII file which describes the functions and capabilities of a field device. The CFF file is used in conjunction with the DD file to enable a host system to configure the system off-line.) Conversely, you may want to replace an older unit with a newer model with a new DD of CFF file. Either scenario can cause problems, because if the files are different in the host system and the device, then the device will not commission or communicate.
Fortunately,
this legacy problem is being addressed and is disappearing. Suppliers
are tackling this issue by reading DD/CFF files from devices connected
to the host and self-selecting the correct files for the device during
commissioning. This allows for more plug-and-play functionality.
This means that when the device is added to a segment, the host automatically reads and performs some configurations to itself and/or the device to communicate correctly. In some cases, the host can self-generate a CFF by reading it from the device.
DD revision management is another issue addressed by automatically reading DD information from each device and keeping this information current on the host control system or asset management system. This functionality is often supported by the supplier via a software upgrade, but it may require manual effort.
6. Using the Backup Link Active Scheduler
The backup link active scheduler (LAS) is one of the unique capabilities of Foundation fieldbus, but it isn’t used as widely as one might expect. It manages data traffic control to achieve scheduled communication on the segment and it can keep the segment working even when the host system has failed.LAS functionality can reside in any one of the devices on a segment with link master capability. The scheduled communication cycle to run all the function blocks in all the devices on the segment is known as the segment’s macrocycle, which is the base time (0.5, 1 and 2 seconds are used most commonly) for scheduled communication.
As the number of devices and function blocks to be executed on the segment grows, so will the minimum macrocycle time. The time left over after deterministic communication is made available for responding to other types of requests for information from FF devices, such as diagnostic information or other messages.
Generally, the host system H1 module is automatically configured as the primary LAS. There may be a redundant module in the system that serves as the backup LAS, which works well when LAS redundancy on the H1 I/O modules is desirable. But what is the actual requirement for configuring a backup LAS? If it’s desirable that the segment should keep running despite loss of communication from the host system, then the LAS function needs to reside in one of the devices on the segment.
In some implementations, host redundancy is all that is necessary, as depending upon the configuration of the power and power isolator, a loss of an H1 I/O card will result in a loss of the host’s view of the process, rendering irrelevant LAS redundancy via a device.
Another requirement is power redundancy for a bulk power supply and power isolators. If power to the entire segment is lost, then the location of the LAS function doesn’t matter. However, if the configuration is such that the backup LAS can function without the main power supply because it has its own backup source of power, then that device needs LAS capabilities. Some vendors offer LAS capability within a device for an extra cost, so it’s important only to specify this feature as needed.
Rules for backup LAS in the Foundation fieldbus specification call for the lowest address on the segment to claim LAS first. Upon failure of that device, the next lowest address takes over and so on. Thus, most implementations make the host redundant H1 module the lowest address on the segment.
But, is a third backup configured in a device in addition to the host backup? In practice this is rarely done, either due to an unwillingness to buy such functionality in the device, or by not activating and providing a suitable address when putting the device on the segment. This is often a simple feature to implement and it ensures execution of devices on a segment without the host, and should thus be configured where applicable. Also, if control functionality is being run in a host system, then running a backup LAS in field device is useless.
7. Device Addressing
Are all the addresses for devices on a segment in the range that the system is scanning? Some systems scan a finite range in the link-master address range from 20-32 (0x14-0x20) and then at the basic address range 232-248 (0xE8 - 0xF7). This is done to increase performance for sink/source event reporting, and for on-demand communication of parameters to entities such as asset management systems. Knowing this can reduce the chore of finding why some devices don’t appear on the live list, which is the list of devices that reply to the host’s request as being on the segment.Many devices come from the factory with a default address. A technician may install the device on the segment without checking the address and then have to figure out why it doesn’t show up on the live list.
He or she often assumes the device is inoperable and uses a bench tool, such as a laptop with Foundation fieldbus interface card or handheld communicator, to scan the segment. Suddenly, the supposedly inoperative device shows up because that tool scans the entire range. This may prompt the technician to check the scan range of the host.
8. Choosing Between Publisher-Subscriber and Client-Server Communication
Foundation fieldbus supports publisher-subscriber and client-server communication. Some devices have multiple variables available and should use publisher-subscriber for the primary variable and client-server for any other information. This is done to reduce scheduled communication time for the segment since the other information may only be needed upon request and not need to be executed every macrocycle.Host systems should generally be configured to access all the variables required for real-time control and display via publisher-subscriber to guarantee update time. Additional data and diagnostic information can then be accessed via client-server on an as-needed basis.
http://insights.globalspec.com/article/171/10-steps-to-better-foundation-fieldbus-installations-part-2
No comments:
Post a Comment