Refinery expansion runs on fieldbus

Figure 1: Foundation fieldbus is organized in segments consisting of a trunk, segment protector (brick) and spurs going to the instruments. At the DCS end, a fieldbus interface module (FIM) and fieldbus power conditioner connect the DCS and power the segment. They usually handle multiple segments. Here, there are two segments.

By any measure, this was a very successful project. The automation system was singled out by the licensor's start-up team, which reported, "This unit experienced no significant problems with process instrumentation, which is quite different from the typical start-up; on many start-ups, getting the instrumentation to function correctly has been a major and continuing challenge."

In addition to the obvious goal of putting a state-of-the-art process control system in front of the operators, DHOUP started laying groundwork to improve reliability. Today, almost all equipment is “smart,” but it does little good if the diagnostic capabilities are locked up in the field. To be useful, the data from smart devices must get to reliability engineers. Therefore, a key project goal was to install the networks necessary to talk to the instruments, analyzers, rotating equipment, motor control centers and electrical heat tracing equipment that is the bulk of our smart equipment. Foundation fieldbus was identified as a key enabling technology.

Foundation Fieldbus: Our Keys to Success
There is an ongoing debate over the advisability of installing Foundation fieldbus. Proponents will cite increased capability, including diagnostics, lower cost and reduced time to deploy. Opponents cite increased upfront engineering challenges and cost, and long-term support issues as reasons to avoid it.

Our experience is that both camps have valid arguments. We believe that our implementation is a success, but we recognize that there were challenges to overcome, and ongoing challenges to success. Our story is in what we did to get here, and what we're doing to ensure continued success.

Figure 2: This faceplate and mini-trend shows a poorly performing valve. With Foundation fieldbus, all valve positions are historized with valve position to support ad hoc troubleshooting of control loop performance. We believe that this alone is worth the price of admission.

1. Go big. The benefits of implementing Foundation fieldbus scale with project size. The up-front engineering costs do not scale with project size as much. Regarding long-term support, Foundation fieldbus introduces training, workflow and spare parts issues that also do not scale with implementation scope; in fact, the issues can be worse with small implementations.

2. Embrace the technology. Foundation fieldbus is fundamentally different from conventional instrumentation. We actively explored its capabilities. This article describes some of our creative uses and their benefits.

3. Prepare for the challenges. These include new training requirements, new workflows, software management requirements, spare parts management and finding knowledgeable people. A proactive approach is necessary to prevent these issues from overwhelming the benefits of Foundation fieldbus.

4. Build a lab. Given the complexity of modern control equipment, we recommend building an instrument and control laboratory whether or not you have Foundation fieldbus instrumentation. However, we believe it would be nearly impossible to manage and test software, validate instruments and train without a dedicated space for the instrument and process control staff to work with the instruments.

In the interest of full disclosure, these lessons were learned from a previous, less-than-successful Foundation fieldbus project. DHOUP could not have been successful if the automation team was learning these lessons as the project progressed; they would have occurred too late to be useful. DHOUP's success validates that the lessons learned from the prior project were the correct lessons, and that the project execution plan developed from the lessons is worth sharing. Now let's talk details

What Is Foundation Fieldbus?
For those who may not already be familiar with Foundation fieldbus, here is a definition from the Fieldbus Foundation website:

"The open, non-proprietary Foundation architecture provides a communications protocol for control and instrumentation systems in which each device has its own ‘intelligence' and communicates via an all-digital, serial, two-way communications system."

That's nice as far as it goes, but what does it really mean? How is Foundation fieldbus different from conventional instrumentation?

1. Foundation fieldbus allows connecting multiple instruments to a single pair of wires. Figure 1 shows a sample architecture. Foundation fieldbus is organized in segments consisting of a trunk, segment protector (brick) and spurs going out to the instruments. At the DCS end, a fieldbus interface module (FIM) and fieldbus power conditioner connect the DCS and power the segment. The FIM and power conditioner usually handle multiple segments (Figure 1 shows two segments).

2. Digital communication allows instruments to report multiple measurements to the DCS. In Figure 1, the Coriolis meter is reporting flow, density and process temperature to the DCS on one pair of wires. Multiplexers can combine multiple measurements in the field; for example, the temperature multiplexer reports eight temperatures to the DCS.

3. Bidirectional communications allow valves to report their position in real time. Multifunction multiplexers, analog input (AI), analog output (AO), digital input (DI), digitial output (DO), connect conventional instruments or, as in Figure 1, PLCs to the DCS.

Figure 3: MPC requires a “check temperature” for all temperature control loops. Foundation fieldbus transmitter logic can be set up to use the average temperature, first good, maximum or minimum reading. A significant difference between the thermocouples is alarmed. 

5. Foundation fieldbus instruments can feature comprehensive diagnostics and report that information to the DCS in real time.

6. Foundation instruments can expose their configuration information to the DCS, enabling remote configuration of the instrument if permitted.

7. Foundation fieldbus instruments from multiple vendors can be mixed and matched, allowing users to select the best available instrumentation for their application.

8. Honeywell's Foundation fieldbus instruments can report information to multiple controllers (soft marshaling). For example, TI-1 from the temperature multiplexer could be used in a calculation by controller 1, TI-2 in controller 2 and TI-3 in controller 3.

9. A device descriptor file is required to tell the DCS how to communicate with a Foundation fieldbus instrument. The device descriptor file version must match the version of the instrument installed in the field; V. 5.2 of the device descriptor file for a pressure transmitter will not work with a V. 6.0 pressure transmitter.

Challenges and Lessons Learned
At each phase of the project, some things went well, some presented challenges and we learned. First, in general, it was a challenge to find people with Foundation fieldbus experience. To be blunt, we didn't have much luck, which meant we had to help our EPC and DCS vendor create their own experts. This was not unexpected, and DHOUP did plan and staff accordingly. Fortunately, our EPC and DCS vendor did have some very good personnel without whom this project would not have been as successful.

Client personnel with Foundation fieldbus experience should be embedded with the EPC and DCS vendor staffs to oversee work product and provide guidance as necessary. The DCS vendor will have Foundation fieldbus experts, but it's less likely that they will have someone to assign to your project, and getting access to the experts is difficult. Use them as much as possible, and be focused when you get the opportunity. EPC and DCS personnel must be better than average. Aggressively weed out personnel who can't or won't learn new technology, and take direction from client personnel.

Lessons in Design
A Foundation fieldbus system greatly reduces the design effort of the physical wiring. The ability to connect multiple instruments to a single trunk reduces overall wiring by 50% to 75%. There is no need to track and segregate AIs, AOs, DIs, DOs and thermocouples. Foundation fieldbus also eliminates the need for field termination cabinets, home-run cables and marshaling cabinets. The number of engineering drawings required to document the design is greatly reduced. Instead of, for example, 10 loop drawings, one for each instrument, there will be one segment drawing that includes the 10 instruments connected to that segment. There may be no need for cable schedules, field termination cabinet drawings or marshaling cabinet drawings.

Foundation fieldbus simplifies DCS design. There is only one type of I/O card: Foundation fieldbus. A four-segment card may connect up to 64 instruments. Sizing the DCS was very easy: Divide the estimated number of instruments by expected segment loading (call it eight), divide by the number of segments per I/O card (four) and add a few per your spare I/O policy. So 1,000 instruments will require 125 segments, which is 32 I/O cards (31.25), or, with 20% spare, 38 cards. Our DCS vendor recommends one controller for every 10 I/O cards, or four controllers. It really is this easy.

Our DCS vendor's soft marshaling capability further simplified system design. Physical design is completely independent of controller logic assignments. There is no need to assign instruments to specific controllers during the design of the physical wiring. Two instruments that will eventually be assigned to two controllers can be connected to the same segment, which means the instrument design team can gather all instruments located in close proximity on one segment without knowing or worrying about where the logic will eventually be loaded. We assigned logic to controllers based on functional grouping; e.g., feed preheat and charge heater. At the very end of software testing, we did a load leveling check, and moved logic between controllers as necessary. During design, we didn't worry about load leveling because we knew we could do it late in the project without impacting the physical design.

Late changes have less impact on a Foundation fieldbus system. When a new instrument is added, it's usually acceptable to connect it to the nearest brick. You don't worry about where the logic will be loaded. This will impact one engineering drawing, the segment drawing. Removing an instrument will also only impact one segment drawing. There is no need to chase through multiple drawings to assign or remove an instrument.

Figure 4: A very portable mini-DCS was taken to vendors’ shops and connected to safety system (SIS) local control panels to perform full function testing of all DCS logic and graphics. Connection and setup time would run between two to four hours, and we could be testing logic by noon on day one.

On the other hand, there are design challenges. Foundation fieldbus segments must be carefully engineered. Because a segment will have multiple instruments, you must verify that voltage drop and current load are within design limits. DHOUP performed a single “maximum acceptable” segment calculation, which defined the maximum trunk length, spur length and number of connected instruments. As long as individual segments fell within these design parameters, we did not have to perform individual segment calculations.

Communication bandwidth is limited, which limits the number of instruments that can be connected to a segment. Unsurprisingly, multiplexers consume a lot of bandwidth because they communicate multiple measurements. Based on our lab work, we established rules limiting the number of multiplexers that could be connected to one segment. Normally we permitted 10 instruments, but if there were two multiplexers, the limit was nine instruments. The numbers change as more multiplexers are added.

Optimizing communication schedules on some Foundation fieldbus systems may be an issue. Our DCS automatically optimizes the schedule and limits scheduled traffic, both of which will improve overall system performance or at least keep you from hurting yourself. The optimization is done in the background. We never think about it.

We limited the number of instruments on segments that included critical instruments. While it's unlikely that working on one instrument will take the entire segment down, it is possible. This limits the possibility that making a mistake while working on a low-value instrument will adversely impact unit operations. For the same reason, we limited the number of control valves on a segment.

It's recommended that the instruments and control valve that form a control loop be on one segment. While DHOUP didn't execute control logic in the instruments, if you ever do, the instrument and control valve must be on the same segment. (For more information, see the “Foundation Fieldbus System Engineering Guidelines” (AG-181), available at the Fieldbus Foundation website.)

The EPC design engineers required coaching to maximize the value of the installation. For example, it was suggested that all the temperature multiplexers be installed in one cabinet at the end of the unit, essentially making it one giant remote I/O cabinet. We suggested that this probably wasn't the best use of the technology. The intent is to place the multiplexer as close to the thermocouples as possible to reduce the inaccuracies that can occur when low-voltage wiring is run long distances.

Foundation fieldbus instruments aren't as widely available as conventional instruments, and versions don't exist for some measurements, requiring the use of conventional instruments. Searching for and vetting instruments for use on the project did take some time. Conventional-to-Foundation fieldbus multiplexers were a particular problem. Where conventional instruments were used, we installed Foundation fieldbus multiplexers to convert the signals. (Unlike with many projects, we chose not to install conventional I/O to support conventional instrumentation.)

Installing multiplexers in PLC and analyzer cabinets was not a problem; these cabinets have 24-Vdc power readily available. However, for the small number of conventional instruments mounted in the field, we had to install local 24-Vdc power supplies and wiring to support the multiplexers. We also had one vendor that stopped selling an instrument, and didn't provide an appropriate substitute — nor did any of its competitors sell appropriate substitutes.

Failure of a Foundation fieldbus segment will affect multiple instruments. Problems can't be diagnosed with simple electrical tools, therefore segment diagnostics are highly recommended. We purchased built-in diagnostic units with the Foundation fieldbus power conditioners. These units work very well, but they do increase the cost of the installation and require configuration and man-hours to set up.

When DHOUP started, Foundation fieldbus wasn't approved for use with safety instrumented systems (SISs). The refinery must have conventional instruments for the SIS, which increases spare parts requirements, and requires personnel to remain conversant with the tools and work processes necessary to work on conventional instruments.

Lessons in Software Development

Figure 5: We corrected a number of valves with performance issues using the real-time valve position feedback capability of Foundation fieldbus positioners, but a quick loop check doesn’t always uncover all valve problems. This particular valve passed a loop check (the quick steps in the center of the trend), but when left alone, the valve started misbehaving.

We recently found a level transmitter that will mark the PV bad inappropriately and for those loops, we have changed the default setting to leave the loop in auto.

All control loops go to manual when the transmitter is taken out of service, based on an instrument-in-service bit that Foundation fieldbus attaches to the process variable. We have experienced process upsets caused by an instrument technician working on the wrong instrument. Before a technician (or a control engineer) can make changes to an instrument, he must first take it out of service. Forcing the control loop to manual will reduce these incidents. (Note that if the technician closes the process taps before marking the instrument out of service, there can still be a process upset. There is only so much we can protect against.)

All valve positions are historized. The faceplates and mini-trends include valve position to support ad hoc troubleshooting of control loop performance. Figure 2 is an example of a poorly performing valve. We believe that this alone is worth the price of admission.

DCS logic is set up to make full use of an instrument's entire range, regardless of the calibrated range. Foundation fieldbus instrument communication is 100% digital; there are no zero-drift or quantization errors caused by the digital-to-analog and analog-to-digital conversions that conventional instruments require, no loss of accuracy in communications and no need to artificially limit range to preserve accuracy. However, the DCS must be properly configured to make use of this capability.

For example, a flow controller has a calibrated span is 0 to 50 in. H2O, which is 0 to 2,000 BPD. The transmitter can measure to 250 in. H2O, which works out to a maximum accurate flow of 4,472 BPD. This was a significant change in normal practice that did not get consistently picked up by the EPC's work processes. Conventional instruments are clamped at -6.9% and 106.9% of the calibrated range, as required by the limitations of the 4-20 mA signal. (Ultimately we found ourselves fixing this during the software FAT.)

Body temperatures are configured on all transmitters that have them available. As a northern refinery we have issues with freezing during the winter and overheating instruments if we do not turn off the heat tracing when spring comes. The body temperature alarms are intended to alert the operators when heat tracing isn't working or is working too well.

Temperature controllers have two thermocouples. The logic can be set up to use the average temperature, first good, maximum or minimum temperature reading. A significant difference between the thermocouples is alarmed. For example, MPC specifications require a “check temperature” for all temperature control loops. Normally one thermocouple would be used for control, and the other would be just an indicator. Deviation alarms are not required and generally not supplied. Figure 3 shows the deviation alarm (DEV bock), two thermocouple inputs and the input selector block AVG_OUT, which is located in the transmitter.

Oxygen analyzer controllers include logic to hold the PID output when the analyzer is in calibration. The Foundation fieldbus version of this transmitter sets the PV status to uncertain when a calibration is in progress, so we did not install a digital input to notify the DCS that a calibration is in progress. We also discovered that the PV may not be good for 10 to 20 minutes after the transmitter is started. The PV is marked bad until the sensor temperature comes up to 700°C. (All these years we've been allowing the DCS operator to put the oxygen analyzers on heaters back in control immediately after start-up, not realizing this was doing us no good—or possibly making things worse.)

There's more, but you get the idea.

Among the software development challenges, it can take a lot of work to figure out the capabilities of Foundation fieldbus transmitters. This is not a bad thing, but it must be planned and executed early enough in the project to allow incorporating the capabilities into the logic. DHOUP tested an example of every Foundation fieldbus instrument and I/O multiplexer we expected to deploy on this project. Depending on the instrument, testing and development time would run from two to five days. We built a temporary lab at the EPC's offices to support the testing (the “toy box.”) It was very primitive, but effective.

Foundation fieldbus transmitters are interoperable, but we have found instruments that are not well-behaved. They may pass the Fieldbus Foundation Interoperability test, but we were not comfortable deploying them. We discovered these questionable behaviors during testing in the lab.

Device descriptor files direct from the vendor often are improperly set up. Parameters may have improper defaults or improper permissions, or may be marked “load” when the transmitter will not accept them for loading. Forms are often arranged in ways that don't make sense, and essential parameters may not be displayed on any form. You may have to spend hours deciphering which parameters are essential and which need the defaults changed, and to re-lay out the forms to make sense. Keep good notes. When the next revision comes out, you will be fixing that device descriptor file as well. As you gain experience, this becomes a much less daunting task.

Foundation fieldbus instruments can have quirks. We have documented quirks to help new engineers know, for example, that some instruments will not always load ranges properly, and that you need to load the instrument a second time or manually change the range parameters to fix the problem.

Lessons from the Vendor Interface
Our DCS vendor developed the control logic for DHOUP. The large size of the project required a large staff to convert the P&IDs, databases, control narratives and cause-and-effect drawings into logic. Ensuring consistency with a DCS using conventional instrumentation would have been very difficult, and we felt that ensuring consistency on a Foundation fieldbus job would be impossible — there was too much customization to communicate via written specifications.

To address these concerns, we developed logic “typicals.” We broke down the P&IDs, etc., into repeatable functions, some stand-alone, some intended to be assembled into complex control schemes, and developed pre-tested logic and associated documentation for each function (e.g., a flow controller). We delivered the typical logic and documentation to the DCS vendor as it was developed. When work packages were turned over to the DCS vendor, we included typical assignments for all DCS points and wrote implementation sections into the complex control narratives and cause-and-effect drawings that included the typicals to be used, plus any customization of the typicals.

The typical narratives include everything we learned about each Foundation fieldbus instrument; how to set it up, how to load it and any quirks. The name and revision number of each typical was embedded in the logic. When we found problems (and we did) finding and fixing the problem across thousands of points in multiple servers was greatly simplified; it was reduced to a parameter search.

Ultimately, we developed more than 100 typicals. Foundation fieldbus drove this number up; each type of meter required its own (e.g., for flowmeters we have Coriolis, differential pressure, magmeter, vortex shedding, etc., typicals). In the end we achieved our goal. The installed logic exhibits a high degree of consistency despite a development schedule that extended almost a year and a half and involved many people spread half way around the world.

Software Testing Lessons
Testing the DCS logic and graphics was vital to the success of DHOUP. Our DCS supports full simulation of the logic and substantial simulation of Foundation fieldbus instruments. We were able to perform nearly 100% testing of the DCS logic and graphics as it was returned from the DCS vendor. This allowed us to start up with nearly bug-free logic. (The delivered logic was anything but bug-free, but in our vendor's defense, many of the issues were design flaws. When tested, we found the control schemes would not work. We rewrote a lot of logic.)

We were able to perform full integrated function tests of our safety instrumented systems during the factory acceptance test (FAT) at the vendor's shop. If our scheduling had been better, we could also have performed full integrated function tests of our compressor control and continuous emission analyzer systems at the vendor shops.

DHOUP asked our safety system and analyzer vendors to build conventional I/O-to-Foundation fieldbus multiplexers into their local control panels to convert multiple AIs, AOs, DIs and DOs to Foundation fieldbus signals (see Figure 1). This permitted the DHOUP project team to take a mini-DCS (Figure 4) to the vendor's shop to support full DCS function testing of all DCS logic and graphics. The mini-DCS included a controller, Foundation fieldbus I/O card and power conditioners, an Ethernet switch and a couple of laptops configured as a DCS server and client (very portable). The mini-DCS could be connected to the SIS local control panel with two Foundation fieldbus segments (typically) and two Ethernet connections for OPC and/or MODBUS communications. Connection and set-up time would run two to four hours, or about the time it took to do the physical checks of the LCP. We could be testing logic by noon on day one.

When we left the vendor's shop, the SIS would be fully functionally tested; the DCS logic, database and graphics fully tested; and the wiring between the Foundation fieldbus I/O multiplexers and the PLC fully loop checked. This reduced required field loop checks by roughly 30 to 50 loops per system. The field loop check was reduced to, “Is the segment connected to the correct location?” If yes, match the devices, load and sign the loop check forms.

We also used our mini-DCS to check out the Modbus connections to all our motor control centers (MCCs) during the MCC FATs, completing hundreds of loop checks prior to shipping the MCCs.

Among the challenges, our vendors were not familiar with Foundation fieldbus. They required some assistance with design, wiring and parts acquisition. Naturally, there were price adders for custom work.

Construction Lessons
Construction time is much quicker relative to conventional instrumentation, as would be expected when there is 50 to 75% less wire and there are no termination cabinets, home-run cables or marshaling panels to install. This became very important to the project as construction at one point was three months behind schedule. This compressed the loop check schedule from nine months to six. However, because construction and loop checks are faster with Foundation fieldbus, we were able to easily complete the project on time.

Lessons from Loop Checks
Loop checks of Foundation fieldbus instruments are generally faster than conventional instruments. If everything goes right, a Foundation fieldbus and a conventional instrument can be checked in about the same amount of time. However, fewer things can go wrong with Foundation fieldbus instruments, and when they do, they are generally easier to resolve. For example:

• Cross-terminated Foundation fieldbus instruments are easy to identify. The instruments identify themselves when connected to the segment. DHOUP bought the instruments pre-tagged, so when, for example, 70FT0596 was connected to the network for the first time, it would show up as 70FT0596. It doesn't matter which set of terminations 70FT0596 is connected to. It will show up, and the logic will work (we tried to ensure the terminations were correct to keep the documentation straight).

There are also far fewer terminations in a Foundation fieldbus system, which means there are simply fewer opportunities to make mistakes.

We did have a few instruments wired to the wrong segment, which was quite an achievement as most bricks are fairly far apart. In these cases, finding the instrument was relatively easy; if it wasn't where we expected it, we looked at segments close by. Because the instruments self-identify, you can find 70FT0596 by name and direct the loop check team to the incorrect termination location.

• There cannot be a mismatch between the instrument range and the DCS. Digital communications between the instrument and the DCS means that there is no digital/analog and analog/digital conversion, which means that the span calculation is performed once in the transmitter, and the data is communicated to the DCS as BPD or °F, not 4-20 mA.
• There is no late range change hysteria with Foundation fieldbus. The DCS holds the transmitter range; late changes were added to the DCS database and loaded into the transmitters when they were connected. Loop check documentation, because it was published early, did not always pick up the late changes. We would verify discrepancies against the change log; however, we do not recall any unexpected changes.
• Instrument and valve issues can be investigated and possibly fixed from the DCS. We found ourselves running valve auto-tuning from the DCS frequently (the field team watched the valve), and then checking the valve self-diagnostics to see whether we needed to call the valve technicians to correct poor performing valves. Valves report performance metrics such as stiction and hysteresis. If these were excessive, we would forward the valve to the problem resolution team. Of course, if the auto-tune fails, the valve has a major problem and must be forwarded to the problem resolution team.
• Segment diagnostics ensure wiring integrity. As mentioned in the design section, we installed a full Foundation fieldbus wiring diagnostic system that performs continuous monitoring of each segment. Any wiring issues were identified and corrected as loop checks progressed.

However, Foundation fieldbus instrument loop checks require more DCS pre-work. The specific impediments are:

• When an instrument is connected to the DCS, the control engineer must match the instrument to the DCS logic. This confirms for the DCS that this instrument is indeed the one we want connected. Then the control engineer must resolve any differences between the DCS's copy of the instrument configuration and the instrument's internal configuration by either loading the DCS configuration to the instrument (the DCS is the golden copy) or loading the instrument configuration to the DCS (the instrument is the golden copy).
• The DCS logic for a control loop cannot be loaded until all instruments in the control loop are connected. The transmitter may be connected, but it cannot be loop checked because its logic cannot be loaded until the valve is connected. This did create some confusion and coordination issues during loop checks.
• Instruments with different software versions than expected can slow down loop checks. The DCS database must be updated to match the instrument's software version using the automated “device replacement” procedure. While generally not very time-consuming, if there are hundreds of instruments at different versions (as we had) the updates will consume a lot of time.
• Different instruments will slow down loop checks. We received 50 or 60 Fisher valves with Fisher digital valve controllers where we expected Masoneilan valves. Changing the logic to use instruments or valves from different manufacturers is a non-trivial exercise. This was a particular problem, as we had not had the opportunity to work with the Fisher valves in the lab; we had to do our discovery work on the fly.

To address these issues, we added a night control engineer whose sole responsibility was to find instruments that had been connected during the day and do whatever was necessary to get the logic loaded. This worked reasonably well, however, we found that we were following construction so closely that the daytime loop check engineers were matching and loading instruments to try to keep the field loop check teams busy.

Lessons from Pre-Start Checks
We corrected a number of valves with performance issues using the real-time valve position feedback capability of Foundation fieldbus positioners. We found that a quick loop check doesn't always uncover all valve problems, as the loop check team doesn't have the time to watch a valve for many minutes. Post-loop check, we would set a valve somewhere between 25 and 75% to see if it would have tracking problems. Figure 5 shows an example of the kinds of problems we would find. This particular valve did pass a loop check (the quick steps in the center of the trend). It was within range of being on target so the field team passed the valve. However, as you can see, when left alone, the valve started misbehaving.

While not a specific benefit of Foundation fieldbus, because we finished early, we took the opportunity to test all of our air-handling systems and perform operator training on heater start-up procedures. The testing of the air-handling systems allowed us to identify and correct several issues:

• Air blowers that surged at air flow rates far above the published curve. This required DCS reprogramming to speed surge control response.
• Improper instrument selection for draft range flow control.
• Damper performance issues under load.

Start-Up Lessons
Just like every other start-up we have been involved with, the EPC missed a dozen or so range calculations, and as usual, they were short. Conventional instrumentation would require locating an instrument technician to re-range the transmitter and a control engineer to change the DCS range. Hopefully, communication will be good, and the transmitter and DCS end up with the same range. While you are waiting for the work to be completed, the DCS operator is flying blind, increasing the risk that something unfortunate will happen, and at the very least extending start-up.

Because we set the DCS logic to allow full use of every transmitter's range, the dozen misses only required us to open PV and setpoint limits, which could be done by the control engineer on the fly. If the control engineer wasn't available, the operator could still see the flow (pressure, temperature, etc.), even if he couldn't put the controller in auto.

Living with Foundation Fieldbus
Foundation fieldbus creates a spare-parts management issue. Transmitters are not interchangeable with conventional instruments. Safety instrumented systems still use conventional instruments; therefore, conventional instruments cannot be removed from stock. Spare parts are one reason to go big; it spreads the cost of spare parts across a larger installed base.

Foundation fieldbus creates training issues. Instrument technician and control engineer interaction with Foundation fieldbus is different from conventional instruments. The handheld devices used by instrument technicians with Foundation fieldbus are not satisfactory; they are slow to boot up, and the menu navigation can be difficult. The control engineers now have to interact with instruments and valves; they can no longer treat an instrument or valve as a black box. The activities necessary to connect an instrument to the DCS can cause problems for control engineers who are not accustomed to these new activities (device descriptor file management, device matching, version management and loading instruments). This is another reason to go big; it is nearly impossible to keep skills up to date without practice, which will not happen on a small system or a few Foundation fieldbus instruments in a sea of conventional instruments.

Foundation fieldbus creates workflow and coordination issues. Working on a conventional instrument only requires an instrument technician. Depending on the activity, working with a Foundation fieldbus instrument could be done by a control engineer, an instrument technician, one or the other, depending on who is available, or both working together. For example, changing a transmitter range could be done by the control engineer, the instrument technician using a handheld communicator, or an instrument reliability engineer using asset management software. Replacing a failed instrument requires both a control engineer and an instrument technician — the technician to perform the field work, and the control engineer to match and load the instrument.

Foundation fieldbus instruments can generate a lot of diagnostic alarms. We believe this will eventually be moved to the “worked well” category, but in the short term we have found that unnecessary alarms are showing up in the operator alarm summary. We are currently working to identify which instrument diagnostic alarms have value and how to direct them to the people who are responsible for resolving the alarms (not the DCS operators).

Device descriptor file management is an ongoing issue. Our system has multiple servers. When a new device descriptor file is needed, it must get copied to all servers. If a correction is made on one server, it must get copied to the other servers. New device descriptor files are issued very rarely, therefore, keeping the skills necessary to work on them up to date can be problematic even on a larger system. Device descriptor management can become an acute issue when the replacement part issued from stock requires a file revision you do not currently have on the system. The instrument replacement will be held up while the control engineer searches for the device descriptor file (on the Internet), loads it to the system and performs any minimal changes to get the file to work. (A sad but true story: we have received parts from vendors that were several revisions old. Finding an old device descriptor file can be nearly impossible.)

Ongoing Work
The refinery is now implementing the DCS vendor's Instrument Asset Management system. Foundation fieldbus was justified in large part on the availability of instrument diagnostic information's reducing costs by moving from a reactive to predictive maintenance model. Access to the instruments' diagnostic alarms is a key part of this strategy.

Not surprisingly, based on our experience with Foundation fieldbus so far, this requires a lot of work and a lab. A new instrument revision will require an updated fault model. Although the changes will usually be minor from revision to revision, some effort is still required. Gathering the information necessary to set up the fault models can be difficult. Some manufacturers offer very good documentation; some do not. We’ve found that some instruments offer very complete diagnostics, and some offer very limited diagnostics. Finally, information for older instruments may not be available.

The refinery has a control and instrumentation lab, however, it is planned to move the lab to a larger space. The lab is used for control logic development and testing and for instrument technician training.

In conclusion, Marathon Petroleum successfully implemented Foundation fieldbus instrumentation during the recently completed Detroit Heavy Oil Upgrade Project. The Detroit refinery is continuing to work with Foundation fieldbus to realize the benefits of the available instrument diagnostics, as well as to institutionalize the work practices and training programs that will ensure the benefits of Foundation fieldbus will be realized for years to come.