Use Advanced Automation and Project Management to Simplify Refinery Construction

E. Spiropoulos, Yokogawa Corp. of America, Houston, Texas

Use Advanced Automation and Project Management to Simplify Refinery Construction

Process automation in oil refineries is undergoing major changes, driven by customers frustrated by what they consider to be slow and incremental advances from the main automation original equipment manufacturers (OEMs) in the industry. ExxonMobil has become a de facto industry representative and is driving vendors like Yokogawa and others to reevaluate how large-scale automation projects are implemented.

The customer message is clear: projects take too long; they are too engineering-intensive; and the automation systems frequently become the critical path in the final stages, often causing the project to fall behind schedule. In many instances, automation engineers can legitimately point at process engineers and others for last-minute changes, but with little consolation from the owners.

With several hundred major automation projects executed globally each year, the industry-leading automation OEMs can draw on several decades of experience working in various industries and with a range of technologies. Individually and collectively, they are applying their knowledge of best automation practices and lessons learned to answer the question, "How can we do things better?"

As a result, automation OEMs are being guided by the industries they serve to develop and improve solutions that provide the reliability, operability and safety expected from control system platforms. OEMs are also being asked to improve methodologies for assembling, executing and deploying a complex process solution with improved efficiency, lower installation cost and greater adherence to schedule.

Most of the efforts fall into two main categories: project management and technical improvements. These two categories are deeply intertwined on multiple levels and, as such, can work together to improve projects.

Serial to Parallel

For the past few decades, projects have followed the same basic path shown in FIG. 1. Each phase takes place in a serial fashion, as each builds on the previous effort:

FIG. 1. Traditional project management techniques follow a serial process,
with each step following the previous one in sequence.

1. The design phase typically includes development of functional detailed specifications and agreement on project engineering standards, schema and, sometimes, resources.
2. The design phase leads to the main engineering activities, which can
be grouped into hardware-related and software-related activities. It is desirable to have as much parallel engineering as possible with these activities, and the conventional model achieves this up to a certain point. Control logic, graphics, alarm configurations, tuning parameters, etc., can be application-engineered by a software team in a single location or multiple locations. At the same time, controllers, input/ output (I/O) cabinets, marshalling boxes and enclosures can be manufactured, wired and tested by another specialized team.
3. The significant dependence of application engineering on the design hardware is a challenge. 
An automation application must
be configured to fit the very
specific controller, I/O module, marshalling, termination and wiring plan for which it is designed.
4. Upon site delivery, the application piece is bound to the hardware loop by loop. Late binding allows enough time in the schedule for project design changes to be implemented in both hardware and software before final binding. Flexible binding allows for these changes, as well as reconfiguration, at any point in the project.
5. Either after or during loop commissioning, the owner signs off on the automation project, and the plant starts up. Depending on the business environment,schedule flexibility in startup may be acceptable, but late is never desired.

If events unfold as planned, then the project can stay on schedule, although the schedule might be longer than the company considers desirable. However, most projects do not run exactly as planned because process engineers may realize a vessel is not in an ideal location, the distillation tower is not large enough, or another pump needs to be added at some point to maintain sufficient flow. Any of these process equipment changes will create process automation system changes by moving or adding hardware and related instrumentation.


FIG. 2. Late changes to a project cause delays in each phase.
These delays cascade down the schedule, pushing past the deadline.

As FIG. 2 shows, such changes can extend the time necessary for one or more project phases, ultimately stretching out the schedule and eventually pushing the project past the startup deadline. The automation system now becomes the critical path item holding up the schedule.

Technical Aspects of the Problem and Solution

Compressing the schedule by including more parallel, instead of serial, activities depends on the ability to decouple many elements of the process and mechanical design from the automation system details. To be effective, this requires a method of maintaining overall project management and information for automation software and hardware layers.

One reason why traditional automation projects make such decoupling difficult is the highly customized nature of the hardware, particularly I/O and field wiring. These designs cannot be finalized and built until the process and mechanical portions of the plant are completed.

A typical example is as follows: A vessel in the process needs a level sensor to ensure that the amount of liquid is beyond a given point. For the sake of simplicity and economy, a level switch is specified with a digital on/off output and an appropriate I/O channel created in the control system to receive the signal. However, the process designer later decides that it is critical to know the actual level, and requests a modification.

A level transmitter must now be deployed in place of a level switch alone, so it is necessary to change from a digital signal to a 4-20 mA signal. Such a change might not seem substantial, but, in the real world, it can involve an entire series of steps, from hardware implementation to documentation updates. Multiply this process by a few (or even dozens of) such changes, and construction begins to fall behind schedule.

Fortunately, there is a solution to this problem, and it lies with more flexible I/O systems.

Configurable I/O Cabinets

Several automation OEMs have developed smart, configurable I/O technology capable of supporting multiple signal types on a per-channel basis, and this development is arguably the most critical for the parallel execution of process/mechanical and automation system design (FIG. 3).

FIG. 3. Multiple control system hardware suppliers are already shipping or designing configurable I/O cabinets.
These cabinets are a key element of new project management techniques.

Wiring cabinets outfitted with configurable I/O can now be provided as stock items by the manufacturer, tested and made ready to ship from stock or with a short lead time. They are built to withstand process plant environments, allowing them to be mounted in the field to reduce wiring complexity. Marshalling cabinets are eliminated, along with most termination points. The number of wiring terminations from each device to the control system is reduced from 20 or even more, to perhaps five.

This kind of smart I/O increases the independence of the automation system from the process/mechanical design since it supports system-independent loop commissioning. When the I/O cabinet is in place and the field devices are installed, the performance of the field device and its interaction with the relevant final control element can usually be verified, even before the control system is installed.

When changes come late in the project, such as the shift from a point level sensor to a level transmitter, as mentioned previously, it is a simple matter to reconfigure the connection point in the cabinet. This capability for changing configurations, along with flexible binding of the automation hardware layer to the software layer, support a seam- less transition to the final phases of project completion, without gaps in the schedule. This is because much of the hardware loop validation is accomplished during system-independent loop commissioning.

Smart Communication for Smart Devices

A common element of the new configurable I/O systems is their ability to use the latest digital communication protocols for communication with smart field devices, typically instruments and analyzers. With natively supported communication in place, the diagnostic information from these smart field devices can be gathered and used in a sophisticated asset-management program.

One of the interesting aspects of this capability is its bidirectionality. Not only do the smart field devices send information to the control system, but the control system can also send information to the devices. Customers looking at this capability have asked, "Why can't the control system do the entire smart field device configuration?"

This is a simple question with huge implications. While users appreciate how the capabilities of present-generation smart devices have advanced, the downside is the complexity of configuration. While a pressure sensor 20 years ago might have contained a dozen or so parameters in need of setting, today's units can have hundreds of parameters, so the configuration process can be quite tedious.

All of the information necessary to configure field devices is contained in databases in the control system, so why should these systems be unable to transfer all of the parameters to the device? The technical capabilities are indeed present, and several automation OEMs are developing the process to make it happen. ExxonMobil has characterized this approach with the acronym DICED, which stands for Detect, Interrogate, Configure, Enable and Document (see sidebar article).

Present thinking is that all of these steps should happen automatically. When a technician installs a new field device by placing a device with a specific tag number in a specific location, the process follows of its own accord to accomplish the following:

• The control system detects when a new device is in place and wired.
• The control system interrogates
the device by sending a command requesting its tag. The tag number is the only setting the device requires before installation, and this can be put in by the manufacturer per the customer's request.
• Once the device is identified, the system looks in its database at
the configuration parameters and downloads them to the device. These parameters can include range, engineering units, alarms, etc.
• Once the system verifies that the configuration and the I/O channel are established, the system then enables the device.
• Since this process is automated,
the system can create its own documentation, thereby updating all related databases automatically and drastically reducing the need for human intervention.


Combining these technologies can have profound positive effects.

Putting Technical Advances to Work

When smart I/O, system-independent loop checking and automated device configuration are used together, different functions can overlap to shorten project execution time and reduce required engineering resources (FIG. 4).

With this project methodology, there is significant risk reduction as a result of parallel engineering, reduced automation hardware-to-software dependence, flexibility in binding, reusability of engineering modules and best practices. There is an additional decrease in total project installed cost due to the reduction in wiring, marshalling and field terminations.

FIG. 4. New capabilities allow for a high level of parallel
activity, which compresses the overall schedule.

It becomes possible to envision both parts of the automation effort—hardware and software—as independent pieces assembled from reusable modules following their own schedules. More equipment is purchased "off the shelf," already engineered and tested to relevant standards, and then shipped and assembled in modular fashion, with flexible binding applied at the appropriate time.

This approach allows for design changes and the containment of problems related to late data within a particular execution piece, reducing overall project impact. In fact, it becomes possible to construct an entire process unit or skid offsite, with its associated devices, wiring, piping, equipment, etc., and to mount configurable I/O cabinets as part of the completed unit.

Device and I/O loops can be checked and commissioned in staging, independent of the plant's automation system design specifics. The construction and hardware pieces can be factory accepted, and the entire unit can then be shipped to the site for assembly and connection with the rest of the plant, or adjacent units, all independent of the actual application engineering or system platform at the site.

Creating mechanisms capable of supporting parallel activity on this scale is valuable for all of the reasons discussed, but it does not entirely address the human resource requirements needed to exploit the advantages in the face of demographic changes. Process control system OEMs and user companies are increasingly using engineering resources that are scattered around the world, and many of the new developments make that easier; there are growing libraries of modules to avoid the need for writing code from scratch for a single project.

Customers and suppliers alike are looking for ways to use intellectual property repeatedly, reducing time and cost. Changing to new I/O platforms with self-configuring field devices reduces the time a technician must manually key in parameter values.

Nonetheless, many aspects of a project are still labor intensive, although where, when and by whom specific functions are performed are becoming more fluid. If a greater number of tasks can be carried out simultaneously earlier in the project, then more people will be needed for a shorter period of time. Users will need to utilize combinations of resources—internal engineering staff, construction companies, automation system integrators and automation supplier(s)—in new and flexible combinations, as needed, to realize the biggest benefit.

New technologies and work practices are making these engineering approaches possible and more practical. They can provide great benefits to EPC companies and technology licensors, who can protect their own technology and execute projects using methodologies to provide the most value. Automation OEMs are creating these advances now. Some are already available, but it is certain that many more will be available in the near future.

ExxonMobil's Plan for Self-Configuring Field Devices T. Madden, ExxonMobil Development Co., Houston, Texas Presented at the Yokogawa Users Conference and Exhibition, September 2014

The concept of self-configuration devices can be explained with the term DICED: DETECT: When a new (to the system) HART-enabled device is connected to the configurable I/O, the I/O channel detects that current is flowing where it previously was not. INTERROGATE: The I/O channel transmits the HART command requesting the device tag. The HART-enabled device responds with its tag. (ExxonMobil requires HART 6 or HART 7 devices with long tags.) If the new device is not a HART-enabled device (a shutoff valve, for example), it will obviously be unable to respond to the HART tag name request. In this case, the DICED process is aborted, but a notification to the user can still be generated informing that there has been a change in the field wiring, and it is likely that a new direct-input or direct-output device has been installed. CONFIGURE: Once the system has detected and determined that there is a new HART-enabled device, the system can configure that device with its engineering range, engineering units and other configuration information. ExxonMobil's plan is to purchase field devices with only the tag preconfigured and then allow the system, which generally contains the latest data, to configure the field devices accordingly. ENABLE: The field devices are assumed to be configured in the system and associated with a particular control strategy. ExxonMobil's project execution process assumes that the company will complete most of the engineering, configuration and testing in a virtual environment, but that the company will likely not know exactly to which I/O channel each field device is configured. In this step, the system will know to which I/O channel the new device is connected, and a logical association between the control strategy and the field device can be made. Once this happens, the field device and its associated logic are enabled for use. DOCUMENT: Assuming that all of the above steps are completed successfully, ExxonMobil's expectation is that the system will report this success in an event log. The company aims to greatly streamline field commissioning activities that today require paper loop folders and many field trips. ExxonMobil also believes that the system can automate some of the testing that is performed by an engineer or operator sitting at the console in radio contact with a field team. For example, if the detected device is a control valve, an analog output can be sent to the valve and its position read back via HART. It can be verified that the valve is working correctly, that it is not sticking, that its failure mode (fail closed or fail open) is correct, and that it positions correctly over its range. It would be desirable to contain all of the circuitry needed to implement DICED in the configurable I/O module. If the software can be implemented to take full advantage of this hardware, then this desire may be realized. Note that DICED requires no changes in the field devices themselves.

Eprinted and posted with permission to Yokogawa Corporation of America from Hydrocarbon Processing July © 2015 Gulf Publishing Company