Refinery Expansion Runs on Fieldbus

Marathon Petroleum Shares What It Took to Build a Successful Fieldbus Project

By Ed Bullerdiek

1 of 7 < 1 | 2 | 3 | 4 | 5 | 6 | 7 View on one page


The first part of this article appeared in the July, 2014 issue of Control Magazine. Additional information found only here begins with Lessons in Software Development on page 3.

In the fall of 2012, Marathon Petroleum Company (MPC) started a $2.2-billion expansion of its Detroit refinery, the Detroit Heavy Oil Upgrade Project (DHOUP). The expansion centered on a new delayed coker unit and included a distillate hydrotreater, sulfur recovery units and associated utilities. The project also increased the refinery's overall crude capacity, and Air Products built a co-located hydrogen plant.

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.

The four key lessons we learned are to go big, to embrace the technology, to prepare for the challenges, and to build a lab.

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."

1 of 7 < 1 | 2 | 3 | 4 | 5 | 6 | 7 View on one page

Join the discussion

We welcome your thoughtful comments. Please comply with our Community rules.
All comments will display your user name.

Want to participate in the discussion?

Register for free

Log in for complete access.

Comments

  • Yep. We get the idea. I think what you are saying is that the future is digital also for process control.

    I personally think this is a good summary of some of the key benefits of digital fieldbus over 4-20 mA and on-off signals. Your recommendation to design fieldbus segments based on worst case single “maximum acceptable” segment calculation is incredibly valuable. Many plants in the past were designed with individual segment calculations – those plants did not get the full fieldbus project advantage. Thanks for sharing.

    I agree that modern systems must be networked, and networked from the very first meter, starting at the sensors and actuators. FOUNDATION fieldbus is the logical choice for a process plant.

    The engineering team did the right things to avoid the engineering challenges and cost faced by some other projects in the past like you mentioned. individual segment calculations as in the past would be costly and non-productive. A single worst case “typical” design or like your “maximum acceptable” segment calculation is the right way to go to avoid cost increase. This is what fieldbus projects are doing now. Thanks again for sharing.

    From what I have seen, long-term support issues for fieldbus have been due to lack of proper tools and training. Can you imagine the previous generation instrument technicians going from pneumatic to 4-20 mA without anybody teaching them Ohm’s law or giving them a multimeter? I’m sure there was gnashing of teeth, rolling of eyes, as well as showing of claws back then. So yes, fieldbus training is required and personnel should be given portable fieldbus testers like the Relcom FBT6 or the new P+F tester. Fieldbus training cannot be the generic once-size-fits-all kind; it should be customized for each role: different competencies/skill-sets for design engineers, system administrators, instrument technician, and troubleshooter.

    Building a lab is an interesting idea. Plants these days often build operator training systems (OTS) so why indeed not build an instrument technician training system?

    For some systems you can even get fieldbus interface modules with built in fieldbus power supply. This further reduces cabinet space, footprint, and weight etc.

    Here is a link straight to the FOUNDATION fieldbus brochure: http://www.fieldbus.org/images/stories/technology/aboutthetechology/overview/fieldbus_brochure.pdf

    The issues with device descriptor files have been mentioned by many early adopters of fieldbus so the fieldbus technology was drastically improved in this area not too long ago. Fieldbus now supports “backwards compatibility” meaning a new version of device can be installed without changing the system configuration, as well as “automation of device replacement" and "without manual intervention". This makes fieldbus dramatically easier to run & maintain. See here: http://www.fieldbus.org/index.php?option=com_content&task=view&id=1113&Itemid=281

    Also, "additional advanced support for fieldbus device replacement and backwards compatibility" which "are aimed at simplifying fieldbus implementation, operation and maintenance." That is, "enable host and device suppliers to offer backwards compatibility to their users in order to further simplify device replacement" meaning "utilize a newer device with an existing device configuration without the need for new DDs." http://www.fieldbus.org/index.php?option=com_content&task=view&id=1236&Itemid=281

    Plants with fieldbus systems should upgrade to the latest version of system software to take advantage of these usability improvements.

    Make sure to use fieldbus couplers with short circuit protection to ensure that making a mistake while working on one instrument will not take the entire segment down.

    I totally agree that multi-input temperature transmitters shall sit close to the sensors. This is the correct thing to do from a metrology point of view. You can buy the multi-input temperature transmitters with the field enclosure, ready to install, or “prêt à installer” as Coco Chanel would probably have called it had she pursued a career in automation. Fieldbus is not remoTe-I/O, fieldbus is remoVe-I/O.

    The article did not specifically mention on-off valves. Make sure to use intelligent two-wire on-off valves rather than traditional solenoid and proximity switches hardwired to an I/O box. This is achieved using fieldbus on-off valve controllers.

    Others also complained about “having to load the instrument a second time” like you said which was due to parameter order mismatch, so the fieldbus technology was improved with deferral of inter-parameter checks which means it disables consistency checks during automated download, but once completed, the device re-evaluates configuration. This avoids errors. A “no download” feature was also included.

    Plants should make sure to upgrade their fieldbus system software to take advantage of these new usability enhancements.

    There are fieldbus systems where the system automatically matches (binds) the instrument to the DCS logic based on the preconfigured device tag once the device is connected. That is, if you order the device preconfigured with tag set from the factory; once the instrument is connected it is automatically detected and bound to the system database placeholder based on that tag. System engineer need not touch the software.

    There are fieldbus systems that allow you to connect, commission, and check devices one by one.

    The next major version “ITK7” of the FOUNDATION fieldbus technology will support "PV interchangeability". Interchangeability means that even if the logic was originally created for one type of device you can replace it with another without having to change the system configuration, thus "making Foundation H1 easier to use than conventional 4-20mA"; as easy 4-20 mA since instrument technician can just replace the device without the help of a system engineer, and easier because you don’t have to configure parameters one by one; they are downloaded automatically: http://www.fieldbus.org/index.php?option=com_content&task=view&id=1252&Itemid=281

    Once these system features are made available, plants should upgrade their system software to the latest version to take advantage of these features as it will make the system dramatically easier to run & maintain.

    There are fieldbus systems that support automatic device replacement – in their latest versions. This means the instrument technician can replace the field device using only a screwdriver. There is no need for the system engineer to work on the DCS because everything in the DCS such as download happens automatically.

    Earlier versions of systems do not have this feature, so this is another reason to upgrade the system software to the latest version supporting automatic device replacement. This makes fieldbus systems and devices very much easier to run & maintain.

    To resolve the issue of “unnecessary alarms are showing up in the operator alarm summary”, make sure to make use of the NAMUR NE107 status signal and alarm management feature in the system and devices. This is usually only available in the latest version system and devices.

    Again, systems that don’t support NE107 yet should be upgraded to the latest software version to take advantage of this instrument diagnostics alarm management capability. Similarly, the firmware of many fieldbus devices can also be upgraded online by a simple firmware download. Make sure to upgrade device firmware to take advantage of NE107. Remote centralized firmware upgrade to enable new features in existing devices is one of the advantages of fieldbus.

    There are fieldbus systems where the device descriptor file only has to be loaded in a single station and from there automatically gets distributed to other stations.

    As mentioned earlier, fieldbus now supports “backwards compatibility” meaning a new version of device can be installed without changing the system configuration.

    Some systems also provide a service for automatic or semi-automatic download of device descriptor files. This eases the burden on the system administrator to go look for these files.

    Reply

RSS feed for comments on this page | RSS feed for all comments