Project Services

Emerson's Gordon Lawther, an automation system modernization specialist, will be presenting at this year's Emerson Exchange. His presentation, Total Installed and Commissioned Cost Savings using Electronic Marshalling in Brownfield Modernization Projects pretty much sums up its focus.

Gordon cites a recent ARC Advisory Group study that estimates $53 billion USD in installed control systems that have been in operation for more than 20 years. If you consider the technology changes in your personal life in the last twenty years, you'll appreciate the advancements in system capabilities.

Gordon and the modernization team performed an analysis for a specialty chemical process manufacturer seeking to replace a 20+ year old system. The objective of the analysis was to consider the total installed and commissioned cost including the control system equipment, front-end engineering design, electrical and instrumentation (E&I) design engineering, control system configuration, training, installation, cutover and commissioning, startup, freight, taxes, and contingency.

The analysis considered replacing the I/O with low-density I/O (8 channels/card), high-density I/O (32 channels/card), and electronically marshalled I/O. The plant staff wanted to reuse as much of the existing cabinets as possible, and reuse some of the existing wire marshalling infrastructure. The plant had two rack rooms 300 feet apart. The cutover would occur during a plant turnaround so the analysis did not have to consider a hot cutover case.

Gordon enumerates some assumptions. Some of these included:

• Cabinets have commonly used dimensions with a 19" rail
• Power and networking connections are included in the estimations
• DeltaV controllers and I/O won't be mounted in existing marshalling or field termination cabinets
• Existing wiring does not have enough slack to reach DeltaV controller I/O locations
• Electronically marshalled I/O can be oriented to accommodate existing wiring in the same cabinet
• No new field wiring or instrumentation is included in the scope

For each case, the team performed a project task analysis. This analysis looked at the work associated with the new controllers and the associated wire marshalling. For the base case with low-density I/O, the work steps associated with the new controller included I/O lists & controller sizing, cabinet layout, power & grounding for controller and I/O cards, and I/O wiring schematics. The marshalling tasks included cabinet layout, terminations / interposing relay design, wiring schematics, and home run cables between the two rack rooms.

For the case with electronic marshalling, the steps eliminated for the new controllers were I/O card power and grounding, I/O wiring schematics, and home run cables. Steps were added to the marshalling tasks including the CHARM I/O card assembly, power and grounding for the individual CHARMs, and network layout.

Through this project task analysis, the electronic marshalling case estimated 63% lower installation costs, and 38% lower E&I design costs. The cost of the control system hardware was higher for the electronic marshalling case. Overall total installed and commissioned cost was 26% lower for the electronic marshalling case. With the high-density I/O case, the cost differential was reduced to 8%. Gordon notes the electronic marshalling case also provided single channel integrity, redundancy down to the individual I/O channel, design and installation flexibility, and the ability to bind each I/O channel to any controller up to 4 controllers per CHARM I/O card.

Gordon sums up his findings that the electronic marshalling approach reduces DCS cabinet design and complexity of the drawings, reduces wiring terminations and multi-core home run cables, reduces rack room footprint with the amount depending on whether the CHARMS are located in the rack room or out in the field junction boxes with a network connection back to the rack room.

If you're among the ARC Advisory Group's $53B club and at the Emerson Exchange, you may want to attend one of Gordon's two workshops. His presentation is loaded with visual builds to better convey the alternatives in this analysis.

MP3 | iTunes

Emerson's Sergei Kuznetsov will be presenting at the rapidly approaching Emerson Exchange Technical Conference. In his presentation, Three Non-conventional Level Control Applications, Sergei shares how to approach three quirky level control challenges:

• Particle bin level control with large deadtime presence
• Copper mine concentrator sump system
• Oil platform water injection surge vessel level control

The Oriented Strand Board (OSB) manufacturing process makes wood-type boards from 2-4" wood flakes combined with epoxy resin. The basic process begins with a dry wood bin filled with the flakes. These are fed to a blender where they are mixed with the resin. Next, the coated wood chips are fed to a forming head where they are formed into mats. In turn, these mats are fed by conveyor belt to the press where the particleboard is created. Deadtime, on the order of 2-4 minutes, is the huge control challenge. The flow rate of the wood chips into the blend needs to be as stable as possible and the level of coated wood in the forming heads must be uniform or the quality of the OSB wood is greatly impacted.

Sergei applied PID control with a Smith Predictor to effectively remove the loop deadtime and allow the cascaded PID controllers with the flow loop as the slave loop and the wood level as the master loop to be aggressively tuned. The standard Smith Predictor algorithm had to be slightly modified to handle the integrating nature of the level loop. Sergei cites a book by Karl J. Aström and Tore Hägglund, Advanced PID Control, chapter 8.5 that describes the modified Smith Predictor for use in integrating processes with long deadtimes.

By applying this algorithm and tuning it the dynamics of the OSB manufacturing process, the plant was able to reduce the panel board weight variation by 29%. They were also able to reduce level-related shutdown rates from 15 per shift to less than 1 on average, and reduce raw material consumption by 7%, which translates into more than a million U.S. dollars per line per year.

Sergei's second level control challenge was a copper mine water management system. The goal was to recover as much water coming from the thickening ponds as possible and pump it back into the "Head" tank where it could be reused by the concentrator plant. Water from the thickeners comes to two sump tanks. Each tank is equipped with a set of single-speed centrifugal pumps. The sump tanks overflow lines are routed downstream to the tailings ponds. Another challenge was that the head tank overflow piping was not operational. This caused additional constraints on this control problem. The control strategy needed to prevent head tank overflow, maximize its level to provide enough water to supply the concentrator during demand spikes, remain below the high-level safety interlock, and keep the sump tanks at minimum safe levels.

Sergei designed a simple, elegant solution by gradually limiting the number of pumps running by each of the sump tank level control algorithms when the head tank level approaches the high-level interlock setpoint. The first pumps to be shut down are the ones associated with the sump tank with the lowest level to help equalize levels over time. Also, when the head tank is recovering from a high-level situation, the pumps of the sump tank with the highest level are started first, again to help equalize the levels. The control strategy was intuitive for the operations and maintenance teams and provided robust control for the mine for the time needed to address their process equipment problems.

The third example was on an offshore platform enhanced oil recovery project using water flood techniques. A similar, simple solution was applied to a water surge tank used to inject oily water back into the wells. Tight platform real estate dictated a small volume surge tank, but the required flow rates were quite high. Sergei employed a simple calculation block to the set of conventional controls. The control strategy was able to reconcile the tank level control objectives with water injection goals set by the production team. Additionally, he employed energy-saving algorithms to the pump variable frequency drives (VFDs) that were used to manage the water injection process.

If you have some tough level-control applications, you'll want to attend one of Sergei's two workshops and hear about his approach in solving these. You may also want to bring your toughest level control challenges to ask him about.

MP3 | iTunes

In our continuing look at elements in the IEC 61511 process safety lifecycle, I uncovered an excellent presentation, Safety Instrumented Systems - Considering the Whole Loop, by Emerson's Andy Crosland. You may recall Andy from a recent process safety seminar series in the U.K. Andy presents at Institute of Measurement and Control regional meetings from time to time.

In his presentation, Andy highlights the safety drivers for process manufacturers, the IEC 61511 safety lifecycle, probability of failure on demand (PFD) for the whole safety loop, integrated control and safety systems, and safety integrity level (SIL) verification calculations.

If you follow Mike Boudreaux' Process Safety page in FriendFeed Twitter feed, you'll see a continuing stream of safety incidents in process manufacturing facilities. Andy highlights these incidents as motivation for an increased focus on process safety. He points to the Safety Users Group video page that highlights videos from the U.S. Chemical Safety Board investigations.

Andy provides a very long list of items that need to be included in an IEC 61511-compliant safety requirements specification (SRS). A sampling from his list includes a description of all the safety instrumented functions (SIF) necessary to achieve required functional safety, definition of process safe states for each SIF, response times to reach safe states, SIF testing intervals, process measurements and associated trip points, target safety integrity levels and mode of operation (demand/continuous) per SIF, and much more.

As mentioned in an earlier post, the SRS is critical since the safety instrumented system (SIS) cannot be properly validated without it. The SRS should be the primary source of requirements for all design and selection information, and the SRS is what the SIS is validated against. Validation is a mandatory step in the IEC 61511 lifecycle.

Maintenance and testing of the SIS is a key part of making sure it will function on demand. IEC 61511 Part 1 Section 11.8.1 notes that the system design should provide technical and procedural requirements to accomplish full testing of all elements within a SIF--sensors, logic solver, and final elements. Andy shared some statistics from the Offshore Reliability Database (OREDA) where 50% of the failures occur in final elements, 42% in sensors, and 8% in the logic solver. He shares some of the typical failures that occur in each of these devices.

These failure rates are the basis for the PFD calculations based on the probability of dangerous-undetected (DU) failures. There is much more to SIF design than doing a PFD average calculation based on DU failures. You have to also consider systematic integrity (check the device certification), architectural constraints based on Safe Failure Fraction, which is an equation involving safe-detected (SD), safe-undetected (SU), dangerous-detected (DD), and DU failure rates. These may lead to redundant voting arrangements (1oo2, 2oo3), common cause and diagnostic coverage. Specialists such as Emerson's SIS Consultancy team can assist with these calculations.

Diagnostics within the individual components can help reduce the undetected failures. Andy describes examples of these diagnostics including HART process variable "bad status" alert, earth/ground current leakage, valve partial stroke testing, and external solenoid valve pulsing. Connecting these diagnostics with smart logic solvers such as DeltaV SIS provide a way to alert the maintenance team of the problem condition to initiate repair actions.

If you're in the U.K. and a member of the Institute of Measurement and Control, look for Andy's next presentation in Scotland on September 15. If you're not, subscribe to the safety category of this blog for future posts related to process safety.

MP3 | iTunes

Update: I've updated the post striking out the reference to FriendFeed. Mike posts these events directly to his Twitter feed.

A few weeks ago, I posted Safety Instrumented Function-Focused Approach. It summarized a presentation by Emerson's Russell Cockman and Andy Crosland on the role of an SIS integrator in the implementation phase of an IEC 61511 process safety project. Russell and Andy have just completed a series of five process safety seminars across the United Kingdom. Andy noted that they were all very well attended with most close to maximum capacity. There seems to be very high interest among process manufacturers in IEC 61511 safety lifecycle best practices.

In the above-mentioned blog post, I deferred the subject of SIS validation, so I'll address it here. In the IEC 61511 implementation phase is a step "Installation, Commissioning and Validation." Validation should not be confused with verification. Verification asks the question, "Did we build it right?" It happens at every step through the analysis, implementation, and operation phase of the safety lifecycle.

Conversely, validation asks the question, "Did we build the right thing?" It comes at the end of the implementation phase to confirm that the installed and commissioned SIFs meet the Safety Requirements Specification (SRS). Validation is described in IEC 61511 section 15.1.1 [emphasis added]:

The objective of the requirements of this clause is to validate, through inspection and testing, that the installed and commissioned safety instrumented system and its associated safety instrumented functions achieve the requirements as stated in the safety requirement specification.

The question is whether all of the installed safety instrumented functions (SIFs), also known as safety loops, that comprise the safety instrumented system (SIS) provide the required functional safety as specified in the SRS. This means that it's important that the SRS be properly completed earlier in the analysis phase of the safety lifecycle. A plan is required to define who needs to validate what, when this validation should occur, how it needs to be done, and which tools, techniques, and knowledge are required.

Russell and Andy shared a validation workbook that formalizes this plan. It includes all of the SIFs and the validation work pack checklist associated with each SIF. These include sign offs for who completes the validation process as well as who approves the work performed. The checklist includes visual inspection, verification of process, electrical, and pneumatic connections as required.

A validation SIF checklist may contain steps such as:

• Verify that SIS performs under normal and abnormal operating modes as defined in the SRS
• Confirm that adverse interaction between basic process control system (BPCS) and other connected systems do not affect the SIS
• Verify that the communications between BPCS and other connected systems work properly
• Confirm that the sensors, logic solvers, and final elements perform as defined in the SRS
• Verify that the SIS documentation is consistent with the installed system
• Confirm that SIFs perform as specified on invalid process variable values
• Verify that the proper shutdown sequence is activated
• Confirm that the SIS provides proper annunciation and proper operation display
• Verify that computations included in the SIS are correct
• Confirm that bypass functions operate correctly
• Confirm that start-up overrides operate correctly
• Confirm that manual shutdown systems operate correctly
• Verify that proof test intervals are documented in maintenance procedures
• Verify that diagnostic alarm functions perform as required
• Verify that the SIS performs as required on loss of utilities
• When utilities are restored, confirm that the SIS returns to the desired state
• Confirm that the electromagnetic compatibility (EMC) immunity, as defined by the SRS, has been achieved

Once this detailed process has been successfully completed, the plant moves into the operation phase of the IEC 61511 safety lifecycle. A plan is required for routine actions such as proof testing, maintenance override conditions, documentation of system demand and failure rates to verify if they are consistent with the safety integrity level (SIL) verification calculations, audit and test documentation, and diagnostic and repair procedures.

As Russell and Andy note, the operations phase may last for the next 20 years. It's critical that good recording and documentation practices are followed for the regular proof testing of the complete safety loop (or SIF)--the sensor, logic solver, and final elements.

MP3 | iTunes

Update: Welcome readers of Gary Mintchell's Feed Forward blog! I hope you'll consider adding your thoughts to this post or subscribing while you're here.

Update and Bump: Here's information on Russell's and Andy's UK Safety Seminar Series.

Emerson process safety experts Russell Cockman and Andy Crosland recently presented at the Institution of Chemical Engineers (IChemE) North West Members Group in the United Kingdom. The topic of their presentation was SIL Determination: an Integrator's Perspectives.

From the IEC 61511 safety lifecycle, Russell and Andy noted that the typical scope for an SIS integrator is the implementation phase--performing the design and engineering of the safety instrumented system (SIS). This phase will ideally occur after the safety requirement specifications (SRS) have been established in the analysis phase of the IEC 61511 safety lifecycle.

Per IEC 61511, the SRS provides requirements for the required safety instrumented functions (SIFs) and their associated safety integrity. At the most basic level, the SRS provides a description of all of the safety instrumented functions that are necessary to achieve the required functional safety. IEC 61511-1, Clause 10.3 provides a list of information that should be provided by an SRS.

Russell and Andy pointed out that one of the biggest challenges for managing the safety lifecycle is that the IEC 61511 lifecycle is seemingly idealistic when it comes to the sequential progress of the safety lifecycle phases. In reality, most projects are managed in such a way that the SIS implementation phase overlaps with the analysis phase, in order to optimize the project schedule. The hazard and risk assessment, layer of protection analysis (LOPA), and safety requirements specification activities often occur in parallel of the SIS Design & Engineering activity. Sometimes, project schedules force progress in such a way that safety loops are designed before the SIL is even specified. This leads to increased cost and complexity because designs are go overboard.

Additionally, without a structured process for identifying safety functions, anything safety related ends up going into the safety system. This leads into poor separation of the safety and control systems, since control functions will end up being implemented in the safety instrumented system instead of the BPCS where they actually belong. The SIS becomes overloaded with non-SIS functions and overblown SIL ratings to compensate for poor specifications.

They stress that the process engineer should compile the SRS since the SIS cannot be properly validated without it. The SRS should be the primary source of requirements for all design and selection information, and the SRS is what the SIS is validated against before any hazards are introduced to the process. Key for a successful and efficient process is to get the SRS completed early in the process. Also by taking a SIF-focused approach, it narrows the focus on just the safety related parts, becomes a single information source, confirms design documentation current revisions, and drives SIF design and verification.

They conclude their presentation by pointing out that there are major benefits to be gained by taking this kind of approach to safety lifecycle management. Because the SIS will be designed to deliver the functional safety that is required by the process, the resulting design will be much less conservative, less costly, and less complicated. This can reduce CAPEX cost by 20% and the reduced complexity will drive OPEX down by 25% because maintaining the SIS will require less work. Beyond cost, another important benefit is easier standards compliance. The simplest solution is typically the safest solution, and you can't do SIL verification or SIS validation without specifying the requirements for SIFs. It just makes good sense to manage projects this way for improved safety.

I'll save their experiences and guidance on SIS validation for a future post.

Russell and Andy are doing a series of Safety Instrumented Seminars in the UK over the next few weeks. If you're in the UK and involved in process safety, you might want to catch one of their sessions and hear their recommendations and experiences first hand. I'll update this post with a link to the schedule once it's published.Here is the schedule for their UK Safety Seminar Series.

MP3 | iTunes

Last Friday I highlighted thoughts from Emerson process safety expert, Len Laskowski in the post, Executing IEC 61511 Process Safety Projects. He shared more than I could fit in a single post, so today's post will share the balance.

One of the points made by the authors of the article, IEC 61511 Implementation - The Execution Challenge, was:

The information required to fully define and document a SIF may entail 40 or more unique data items. The source and detail required to document each item must be defined clearly. The effort to gather, track and review this data can be significant. For a large project, the work includes migrating and recording large amounts of data that may be provided in different formats, at different times and by different disciplines and organizations, so some companies develop in-house SRS database tools to improve productivity, reduce errors and track SIF development and approval status.

Len agreed with the challenge of managing this amount of data items required for many safety instrumented functions (SIFs). The cause-and-effect matrices may provide 25 to 30 data items. Other decisions about test frequencies and coverage factors lead to additional data items. Given this large volume of data per SIF, having a database to manage the development and approval status is critical. The authors ask:

A common scope question is what are the project requirements for documenting protective instrumented functions (PIF) that are not required by the LOPA [layer of protection analysis]/PHA [process hazard analysis]. Are PIFs documented in the SRS? Do the SIF analysis and verification steps apply to PIFs? Will the SRS differentiate between SIFs and PIFs?

Len cautioned against using tools such as Intergraph's SmartPlant Instrumentation (INtools) that manage your basic process control system (BPCS) I/O as the place to manage your process safety management (PSM) database. A typical plant may have 3000 I/O under control by the BPCS and 300 I/O under control of the safety instrumented system (SIS). Local, state, and federal regulations require a well-documented management of change process for any process safety-related changes.

Mixing your BPCS I/O into this change process is asking for trouble. Process manufacturers need the flexibility to make changes to the BPCS to operate and optimize their processes in an efficient manner. Programs such as INtools may be okay for developing initial I/O lists, making instrument specs, and other parts of the design process, but not for long-term documentation and management of change.

Instead, Len recommended a simple spreadsheet for the SIS I/O, which is much easier to control and requires no special training. It contains the SIS database settings, cause and effect matrix settings including engineering units, pre-trip, and trip levels. Often the control of this PSM database is by a different group within the plant than the group that manages the BPCS.

Len's closing thoughts for process manufacturer's new to the IEC 61511 process is to focus on the critical shutdown streams in their process. In most processes, there are a few really important streams to close down to take the process to a safe state. The rest are secondary effects to the key streams. Once the key streams are designed and approved, the rest can be done. This often helps to simplify the safety requirements specification (SRS) and make the ongoing support through the safety lifecycle more manageable.

Having strong, experienced technical leaders on the front-end help minimize problems as the process safety project progresses. Although this front-end work may seem time consuming and expensive, Len shared the old safety saying, "If you think safety is expensive, try an accident!"

MP3 | iTunes

ControlGlobal.com has an excellent article on the global process safety standard, IEC 61511. The article, IEC 61511 Implementation - The Execution Challenge, shares the experiences of two Mustang Engineering process automation project veterans.

I turned to one of Emerson's certified functional safety experts (CFSE) and long-time process safety veteran, Len Laskowski, for his thoughts on the article. You may recall Len from numerous process safety-related posts.

In our phone conversation, Len's first comment after reading the article was, "This sounds like the voices of experience. One does not just declare, 'On the next project we will implement IEC 61511' and have life be happy ever after. As the article suggests, a company needs to adopt the IEC 61511 Safety Life Cycle. This takes time and resources that many process manufacturers underestimate." Len noted that by following the Safety Life Cycle and doing the needed work will give process manufacturers the foundation to properly execute a project--and more importantly, a safe facility.

He agreed with the authors of the large challenges confronting process manufacturers when planning, designing, executing, and maintaining their operations using the IEC 61511 process safety lifecycle. The article's authors frame these challenges:

The Safety Instrumented System (SIS) standard, IEC 61511, is driving the need for new engineering tools and Project Execution Plans (PEPs). The standard is a lifecycle approach to defining, implementing and managing a safety instrumented system (SIS). Industry discussions tend to focus on the technical aspects of the standard, but project execution is proving to have an equal or perhaps greater impact on the quality and success of an IEC 61511 project. This article describes a few of the challenges from the EPC [engineering, procurement, and construction] and MAC [main automation contractor] perspective, and suggests approaches to enhance IEC 61511 execution and technical outcomes.

I asked Len what most caused these project to go awry and without hesitation he said it was giving the upfront planning the time it requires--especially if this is the first time the process manufacturer has executed the project using the IEC 61511 approach or if the process is new. Even with completed Hazard and Operability (HAZOP) studies and validated layers of protection analysis (LOPA), it takes a lot of time and there is usually quite a bit of recycle. One example Len cited was a pressure relief valve. When walking through the hazard scenarios, discoveries may come up, such as insufficient sizing for reverse flow conditions. Changes may have to be made which ripple to other safety instrumented functions (SIFs).

Another example Len offered is alarm level settings for standalone alarms that are used as an independent layer of protection. Questions must be asked and answered if operators really have the required minimum amount of time to do something as a result of the alarm condition. It also must be clear exactly what the operator must do to alleviate the alarm condition. And ultimately, can all this be done within the process safety time for the given condition? Resolving these questions takes cross-departmental participation and it all adds up to increased time required on the project's front end.

Len's guidance to project engineers is to resist the temptation to shortcut this front end planning. It will cost more on the backend of the project in terms of rework, will increase project timelines, and will increase the difficulty in testing the safety instrumented functions over time.

Len shared more than I can fit in a single blog post so I'll hold some back for future posts. If you have some wisdom to share based on your project experiences, add your thoughts below.

MP3 | iTunes

I've mentioned in a recent post about the power of on-line communities to connect folks on a peer-to-peer basis to quickly find answers. Here's a recent example from the DeltaV Digital Automation System LinkedIn group.

A new thread, Cabinets Number estimation., was started a few days ago. The engineer who began the thread asked:

I have an estimate of 500 I/Os count for my DCS. How do I estimate the number of marshalling/system cabinets required for this? This is being implemented by Delta V standard Cabinet size of 800mm width x 800mm depth x 2100mm height with front and rear entries.

A consultant responded within a day that it's a function of the mix of traditional and bussed I/O and how you engineer your AC and DC voltage distribution. Next, an Emerson project manager, Luuk Somers weighed in noting that the use of WirelessHART devices can lessen the cabinet footprint needed. He also noted the CHARM I/O in the imminent DeltaV release could also have an impact.

Emerson's Andre Dicaire, a DeltaV product manager responsible for the DeltaV hardware, succinctly stated how electronic marshalling could simplify the cabinet estimation process:

Actually, the answer is now easy. Select the Cabinet type and divide into the total I/O to determine the number of standard Electronic Marshalling cabinets needed.

Siraj indicates he plans to use DeltaV standard cabinets, front/back entry. These cabinets are based on Electronic Marshalling with CHARM IO. This cabinet supports 576 I/O channels, of any mix. There are 6 CHARM IO cards in the cabinet, each card supporting 96 channels. The channels are individually characterized with the needed signal types by the installed CHARM. In addition, each channel can be assigned to any one of up to 4 controllers. This means you can start with one controller, and if needed add up to three additional controllers to handle your control logic. You can reassign any signal without touching the wiring.

Also, you can re-task any channel if the project changes a signal type, such as upgrading a limit switch to an anlog sensor. Install the sensor and change the CHARM. The wiring need not change.

Early on, you only need the I/O count. Once the I/O types are known, you can order the CHARMs. In the meantime, you can start the installation of field wiring knowing that any signal can land on any channel.

OK, You should separate any high voltage type signals from low voltage instrumentation, since most plants require AC level signals to be segrated. So, divide the signals into these two voltage levels, calculate the number of cabinets by dividing by 576 (or 288 for front only access).

Yes, you can still design the system with traditional I/O cards, and wait until the engineering is more advanced so you know how many controllers you need, where the I/O must be landed and then plan the field wiring. Or you can look at Electronic marshalling to decouple the field wiring from the control strategy/controller designs.

Within the span of a couple of days project engineers, consultants, project managers, and product managers shared their expertise on a peer-to-peer basis to address a question that faces most project engineers. This is especially important in this rapidly advancing world of technology in which we live.

MP3 | iTunes

On the Fieldbus Foundation Forums is a recent post, Macrocycle for control in the controller. The post begins:

I have seen many posts about scheduling and macrocycle calculation for control-in-the-field (CIF). I have some doubts about control-in-the-controller (CIC) application. Unfortunately, there is no other option in the project I am working for.

The question asks about acyclic vs. cyclic communications, macrocycle communications, and loop response time.

ISP Lima Process Control Specialist and Control magazine contributing editor, John Rezabek, contributed to the conversation. He referenced a post I had done previewing one of the Emerson Exchange presentations, Control Response Period for Foundation Fieldbus Control-in-the-Field Loops. This presentation was given by Emerson fieldbus consultants Dan Daugherty, Ferrill Ford, and control performance consultant, Mark Coughran.

Here's their presentation, which tested and compared control performance for CIC and CIF:

Dan shared a few thoughts with me that I wanted to pass along specific to control in the controller and control in the field considerations. He said most process control engineers don't know how slow the modes they need to control are. The performance for control loops where control is performed within a Foundation fieldbus (FF) device will always be better, but if the engineer imposes reasonable rules on the use of CIC, it will work well.

Some want to do CIC to avoid the fieldbus segment design calculations and others encounter problems once they do the calculations and commission the segment. In some automation systems like the DeltaV system, the Foundation fieldbus H1 card can run the control loop. Since it's directly connected to the fieldbus segment, the latency of passing information up to the controller is avoided. This significantly reduces the number of applications requiring CIC.

Dan takes issue with rule of thumb developed over the years where the segment-sampling rate is 2X the controller update rate. He believes this is a misapplication of Shannon's sampling theorem. The problem is not that it doesn't work; it's that it increases the cost of project due to fewer devices per fieldbus segment.

Deciding that none of their theoretical arguments, diagrams, and Laplace transforms was having an impact with the 2X sampling belief, Dan, Mark, and Ferrill performed tests in the Fisher Marshalltown flow lab. Dan summarized the most important thing he learned from the test:

Once the loop control mode frequencies are identified, then you choose your control settings so the closed loop transfer function attenuates that frequency. And you need your control update rate to be somewhat faster than that. When we were looking at update rates in the ¼ and ½-second range, we essentially had an update rate that was 25 to 50 times the frequency of the mode we wanted to control, and 2.5 to 5 times 10x the frequency we were trying to control.

He concluded:

It's true that CIF, with super precise determinism, gave the very best control. But CIC gave pretty good control. So, it wasn't really a question of whether or not to use CIC or CIF (because CIF is clearly better), but if circumstances made it necessary to use CIC whether or not it was better to oversample at a slow update rate or to get one-to-one sampling at a faster control update rate. It turns out the faster control update rate gives you more for the money than oversampling at a slower control update rate does. However, note that this line of reasoning applies mainly to continuously changing disturbances.

So, first you need to understand what you are really trying to control, and how good is good enough. That determines your control update rate. Second, once you have a control update rate, then see how much you are willing to load the segment (devices per segment, for economic reasons). If you are forced to use CIC, and if that maximum loading doesn't allow oversampling, then don't oversample. If you are forced to use CIC, and if that if the maximum loading allows oversampling, then by all means oversample.

If you are using CIC, then what you gain by oversampling is a slightly better attenuation of the disturbance frequency, AND a significant improvement in end-to-end response time. So, if you have a process that is mostly flat lined, but every once in a while some rather sudden change occurs, an oversampled segment will have an initial response that is a little quicker than one that isn't oversampled, and if you are using any discrete logic, then you will have a little quicker end-to-end response to the field input.

As for estimating "required" macrocycle times, that varies by method used (number of compel data communications required), speed of devices, and number of devices. CIC requires more compel data per macrocycle, so it will tend to make the macrocycle about 2x longer than if CIF were used.

Our interest in the experiment wasn't to see if CIF or CIC was better, but to determine if oversampling was worth it. Given the already longer macrocycle with CIC, in my opinion, it is a needless self-imposed penalty to oversample, which (for same number of devices) now takes your control update rate out to 4x what you could get with CIF. So, you get worse control because it is CIC, and worse again on top of that because you slowed down even more to oversample.

MP3 | iTunes

Emerson South Korea general manager, Patrick Deruytter was in Austin recently. You may recall Patrick from earlier posts about large FPSO projects being performed there. He has an upcoming presentation at FLNG Project Advancement on accelerating FLNG (floating liquefied natural gas) project delivery using a main automation contractor approach.

For those unfamiliar with FLNG, it borrows the idea of floating production, storage and offloading by building a liquefied natural gas facility on a tank ship. From Wikipedia:

LNG is principally used for transporting natural gas to markets, where it is regasified and distributed as pipeline natural gas.

According to a World FLNG Market Report:

The IEA [International Energy Agency] forecasts annual growth in natural gas supply will average 1.6% from 2006 to 2030. By 2030, natural gas will account for 23% of total worldwide primary energy supply. The difficulties in progressing onshore projects in LNG has driven the adoption of FLNG which now offers an increasingly important method of bringing gas from stranded reserves to the market.

I saw an advanced copy of Patrick's presentation. In it, he notes that process automation touches every element of an FLNG vessel including production units, hull, ballast, power generation and distribution, fire and safety systems, and information management systems (IMS).

Automation typically accounts for only 3% of the capital costs for an FLNG project, but is critical to its successful operation. The automation technology and project execution methodology play a large role in determining how successful ongoing operations will be.

The Construction Industry Institute (CII) described a PEpC (Procurement, Engineering, procurement and Construction) process that can produce:

...savings in time between 10 and 15 percent and savings in total project labor cost between 4 and 8 percent were possible.

CII describes how the PEpC process does this:

...utilize supplier expertise in all phases of the project life cycle by developing an advance procurement strategy and reaching agreement with suppliers on strategic procurement items and/or systems prior to the associated project engineering activities.

Patrick described how this process works on FLNG processes. Working as a main automation contractor (MAC), his team helps develop the execution plan and schedule, procurement specifications, design and execution specifications, device communication protocols, power/heat/loading estimations, measurement technologies, and role/responsibility matrices--all in the front end engineering design (FEED) phase of the project.

Post-FEED, the team develops cost estimates, clarifies scope of MAC supply for the engineering and procurement construction (EPC) contractors, and develops control system detailed design and integrated tests for long lead-time equipment such as compressors and tank storage.

He describes the role automation technology can play. A distributed modular approach for the automation reduces control room footprint, reduces cable size and weight, and facilitates modular design, pre-assembly and test which helps reduce the project timeline. Wireless instrumentation can reduce the project tasks required by eliminating power and grounding efforts, I/O and cabinet design, installation, and commissioning.

Also, electronic marshalling reduces design, engineering, drawings, cabinets and the associated incremental installation and commissioning effort required.

These technologies combined with a structured project execution methodology help to reduce the overall project risk and cost. It also provides the vessel's staff with the control, safety, and information required for efficient, ongoing operations.

The key in accelerating project execution for FLNG is in deploying recent technologies such as wireless and electronic marshalling combined with an advanced project execution model such as MAC.

MP3 | iTunes

Finding alternative sources of energy remains a large, global topic. A quick check of Google News returns almost 8,000 news items in the past month alone. The Emerson Alternative Fuels team, led by director Al Novak, is holding a fourth regional summit on December 16 in Houston, Texas. The Alternative Fuels Summit has as its focus the successful commercialization of alternative fuels and coal gasification technologies.

These summits bring together industry leaders, investors, academia, and other experts to discuss the technologies, feedstock issues, and best practice developed to date. The goal is to find ways to reduce risks, lower the costs of production, and find commercial viability for the many types of alternative fuels. Some examples of these alternative fuels include wood waste to ethanol, animal fats to clean diesel fuel, and coal gasification.

The speakers at the Houston event include:

• Phil Amick, commercialization director, gasification, Conoco-Phillips, on feedstock conversion technologies
• John Derbyshire, senior vice president, KBR, on feedstock conversion technologies
• Matt Whitaker, senior vice president, Synthesis Energy Systems, on process commercialization of a new technology
• James Childress, executive director, Gasification Technologies Council, on the legislative landscape
• James Stanley, manager for alternative fuels for Emerson, on reducing project risk, costs and scheduling - on blueprint to production

I caught up with James Stanley and asked him about some of the key points he planned to discuss. He noted that synfuels from coal, pet coke, and other non-traditional feedstocks would be imperative to the U.S. energy portfolio. Whether a company is retrofitting a brownfield site or building a greenfield site, following processes such as Independent Project Analysis and PEpC are key to success. James also pointed to the trend of increasing process complexity and increasing safety instrumented system (SIS) requirements for gasification projects. Partnering early with a main automation contractor can help reduce risk during project execution, commissioning, and start-up.

The session kicks off with a keynote presentation by Michael Williams, the commissioner for the Railroad Commission of Texas. Beyond its initial charter to regulate railroad charges and tariffs, the commission now regulates all energy in the state of Texas.

If you're involved in the research, funding, design, engineering, or production related to alternative forms of energy, you may want to visit the alternative fuels website and register for one of the 50 slots.

MP3 | iTunes

I received an email from one of my friends on the Emerson Process Management Korean team. We featured some of their work with a Floating Production Storage and Offloading (FPSO) projects presentation by general manager, Patrick Deruytter, in an earlier post.

The project execution and services team has been quite busy executing mega-sized projects and was recently named a Center of Excellence for Process Automation by the Emerson Asia-Pacific Region staff.

Some of the team's recently completed mega projects include:

• PTT Aromatics and Refining Public Company Limited, the largest aromatics producer in Southeast Asia
• Middle East Oil & Gas facilities modernization project with a South Korean contractor
• Korean Polysilicon solar cell manufacturing process
• Middle East Ethyleneamines production process

The Korean office has 2500 sq. meters (27000 sq. feet) and a team of approximately 200 engineers and PMI-certified project managers working on process automation systems-related projects. They performed a quarter-million project engineering hours over the last year. Given the scope and complexity of most mega-sized projects, the Korean team works with engineers from many world areas executing these projects.

Because of these increasing numbers of projects, a new training center in Seongnam-city provides process automation professionals with certified classes in process control systems, analytical measurement devices, and asset optimization.

I share all this with you, because I have a fondness not only for the increasingly significant projects they do, but also for the innovative spirit that Patrick helps foster. The team established the first non-English Emerson blog of which I'm aware. Check out the Emerson Korea blog. It even contains selected posts from this blog translated into Korean. Here are some pictures on the blog from the award ceremony recognizing their work.

Congratulations to the Korean team and keep leading the way on your projects and innovation efforts!

MP3 | iTunes

The EngineerLive website has an article, System migration: make sure you improve control, not just replicate, which shares many of the thoughts we've expressed in recent modernization posts.

I turned once again to Emerson principal modernization consultant, John Dolenc, for his thoughts and additions to this article. I'll include them in their entirety:

You can summarize the author's comments as:

Process control systems will get old. The hardware components will eventually fail. Older configurations tools limit your ability to optimize the process. Integration to MES/ERP systems may be limited by older systems. Engineering expertise on these older systems has retired or moved on to new state-of-the-art systems. Spare parts are becoming scarce and expensive.

These are correct statements. So the bottom line is that at some time, older legacy systems will need to be replaced. The questions become: When will these system components fail? What are the options to replace the system? How much will it cost? How can the cost to replace the system be justified?

The author also had some excellent comments on the planning and implementation of a system migration project. He infers that migration projects are not easily and quickly implemented. The planning process is very important, and during that planning process it is import to identify the business and process issues that drive the plant. The migration plan should then be designed to meet the business and operation goals and not to simply replace-in-kind what exists.

Emerson Process Management provides automation feasibility studies to answer these questions. An automation study is always tailored to the specific needs of each client. Typically, the deliverables of an automation study include identification of benefits from automation and estimates of the financial value. An automation modernization / migration plan is developed to address business and operational issues; many times with migration options. A fairly detailed design is completed including bill of materials, scope of work for engineering and installation, cost estimates and schedules. The final report provides the information the client needs to make the decision to move to the front end engineering or implementation phase of the project.

The author also mentions that a holistic approach should be taken for the migration planning process. Although we cannot be sure what the author means by a "holistic approach," we do have our own interpretation.

First; one must expand the scope of a "process control system" to really be a "process automation system" including instrumentation, control valves and other associated applications such as advanced control, safety systems, and asset management. Then one must understand that the solution to a control problem is not necessarily found in the process control system. Is the measurement device the correct choice for the application and process conditions? Is it located in the proper position for optimal control? Is the control valve the correct type and sized properly? Is the positioner up to the task of providing rock steady control? In other words, a control system can not correct all process control issues alone. All components that make up the control loop need to be considered.

Experiences from one of the early system migration projects we completed provide some examples. We were asked to migrate an existing control system in a batch chemical unit. The existing system was an integrated system consisting of PLC I/O equipment, PC-based control, and a custom, PC-based operator interface. As with most integrated systems we encounter, this system had the typical symptoms: Limited flexibility, the system integrator had to make all control modifications and provide maintenance, high cost for integrator services, and limited spare part availability just a few years after being installed. The only migration option was complete replacement.

During the early design phase of the project we discovered that many of the existing instrumentation was in bad repair, weigh cells were used to add the raw materials, and the right-the-first-time factor was in the mid-80s range. We convinced the client that replacement of the bad instrumentation was in order along with the inclusion of mass flow meters and control valves for the raw material feeds to the reactors. The client required that we reverse engineer the system configuration, because they had invested quite a bit into system modifications and they did not want to lose the engineering investment. So in essence, the control logic was close to a replace-in-kind situation.

The right-the-first-time factor was in the low nineties after the first few weeks of operation upon completion of the migration. The only issue preventing this factor being in the high nineties was certain control logic that was added to the legacy system to overcome its control deficiencies. These logic modifications were soon removed.

The lessons learned here are two fold. First, the new control system performance was impeded by retaining the existing control logic in kind versus retaining the desired control functions and allowing the control system to be configured as designed. Second, the addition of better instrumentation and control valves substantially improved the performance of the process, despite the control logic not being optimal.

John, thanks for adding your perspectives to this article!

MP3 | iTunes

Control magazine had a great article a few months back entitled, Control System Migration. It did a great job covering the selection and planning process when modernizing your automation system. Recently, I featured Emerson's John Dolenc and his perspectives on justifying your automation modernization investment. Taken together, there are many ideas to help plan a system migration project.

John sent me an email with his thoughts on the Control magazine migration article. With his writing prowess, I like to kid John that he should also be an Emerson blogger. In that spirit, I'll include his thoughts in their entirety:

I just recently read an article on control system migration best practices. The article noted that the keys to a successful migration project include:

• Selecting the best control system
• Performing a Front End Engineering study to well define the project issues, develop the automation plan, and develop detailed scope of works and cost estimates.
• Using experienced engineering services and following detailed procedures during the detailed design and implementation phase.
• Developing a detailed cutover plan

I agree with the noted engineering procedures, especially the need to conduct Front End Engineering to properly scope and design the migration. However, the article approached the system selection process from solely a technical performance issue from a configuration engineer's / system integrator's viewpoint. The author defined a system selection process that rated system suppliers on controllers, I/O modules, operator consoles and other system hardware/software issues.

Conducting a technical evaluation of a control system is always advisable, but this evaluation is best done prior to any identified project as an exercise to create an approved bidders list. One must also expand the criteria to include new technologies that are found in today's state-of-the-art control systems; especially those technologies that may provide the financial benefits to justify a system migration. Interface capabilities to ERP systems, asset management systems, and the ability to easily incorporate new field communication technologies such as fieldbus and wireless are important to future systems. We always need to remember that a control system is a tool to be used by operations to efficiently run the process on a day-to-day basis. The availability of tools to monitor control and process performance is important. How easily control strategies can be updated, including advanced control techniques, is important for continuous process improvement.

The article began with the assumption that the decision has been made to update the existing control system. No mention was made for the engineering team to review what led to the decision to replace the existing control system. It is vital for the engineering team to understand the financial and operational reasons for replacing the system. The control system issues that led to the replacement must be identified. And it is the ability to best meet these operational and performance issues that should dominate the system selection process.

The operational objectives must also be considered when developing the automation plan. The results from a replacement-in-kind of the existing control system will typically never please plant and operational management. Correcting process performance issues normally involves improving process measurements, correcting poor control valve performance, implementing better control loop strategies, improved interlocking strategies, sequential control strategies and possible advanced control strategies.

Between the magazine article, the justification blog post, and John's thoughts presented in this post, I hope you have new ideas to advance your system modernization efforts.

MP3 | iTunes

Update: Emerson's Aaron Crews with the The Automation Group business adds a nice twitter tweet:

@JimCahill good post. I like the point about technical evaluation of the control system. Our vendor comp analysis looks @ 600+ criteria

Recently, when Emerson's John Dolenc was in Austin, we had one of those hallway conversations about automation modernization projects. He shared a paper he'd written a few years back that contained many of his thoughts on modernization project justification. The paper had many pearls of wisdom that I'll share over the coming months.

John had strong points about being careful using automation equipment obsolescence as a cornerstone of your project justification efforts. He warned that automation system component obsolescence is a real issue that needs to be addressed. The inability of system suppliers to source components for their older systems and the lack of engineering expertise are issues that also should be addressed.

While your maintenance costs may be increasing, he finds that true maintenance savings are normally not large enough to justify the capital investment. Also, the cost of unplanned process shutdowns due to system failure must be factored by the probability of a failure occurring. We all know that electronic components will eventually fail. Predicting the probability of the failure is the difficulty.

Using obsolescence as the primary justification usually means the management team will dictate the cost of system replacement be kept at the lowest possible level. You lose the opportunity for financial gains through process optimization with improved control strategies, additional or more accurate process measurements and improved control actions. Also, you lose the chance to work with the operators to improve the operator displays and alarm management to handle abnormal situations more effectively.

Instead, one needs to consider the advantages afforded with new technology. The opportunity to review the process thoroughly to identify mechanical and process issues should be taken. Process automation modernization should extend beyond the automation system to include the instrumentation, automated block valves, control valves and variable speed drives.

John noted that it is a rare circumstance where well-designed control strategies can overcome these process- and equipment-related issues. Replacing the obsolete process control system without addressing underlying process problems will not yield the operational performance improvements that some would expect with current automation technologies.

Other areas to consider with new automation technologies include:

• Reduced unplanned process shutdowns and reduced maintenance costs using predictive maintenance practices
• Improved production management through increased process information exchange between the automation system and higher-level operations and enterprise software
• Process optimization through historical process monitoring and trending to allow process engineers to disseminate historical information.

When economic times are good, everybody is usually so busy that the status quo prevails. Difficult economic times offer the best opportunity to really take a close look at your operations, baseline it, and develop an automation plan to improve production and decrease production costs. In future posts we'll take a closer look at John's thoughts on addressing system obsolescence, process automation modernization opportunities, and automation modernization planning.

MP3 | iTunes

Update: Welcome, readers of Gary Mintchell's Feed Forward blog. Thanks for visiting!

Update 2: I just received an email from Control Global which includes a link to an article, Control System Migration. It does a great job describing the migration planning process and is something you may want to check out.

Carbon capture and storage (CCS) processes are emerging as a way for reducing carbon dioxide emissions from fossil fuel-based, power generation facilities. Also referred to as geosequestration, it is:

...a natural or manmade reservoir that accumulates and stores some carbon-containing chemical compound for an indefinite period.

I exchanged some emails with Murray Cox who had some background on Emerson's role in Australia's first geosequestration project. It was designed to demonstrate the deep geological storage or geosequestration of CO₂. The Emerson Australian team provided technologies like the DeltaV automation system and DeltaV SIS safety instrumented system, Rosemount measurement devices, Fisher valves, and Micro Motion flow and density measurement in addition to project management and project engineering services. This process was commissioned and has been operating since April 2008.

Murray describes the process of geosequestration. It begins with having the right geological formation to hold the CO₂ gas. The site had thick layers of porous sandstone covered with mudstone to prevent leakage of the carbon dioxide gas back into the atmosphere.

For this demonstration project, the CO₂ gas is initially collected from a source well that was more than 85% CO₂ with the balance methane and other hydrocarbon gases. Separation is the first process to isolate the CO₂ gas. It is next compressed to generate a stream of supercritical CO₂, which is transported 2-3 km by pipeline to gas injection wells in the natural gas-depleted sandstone formation.

Since this is a pilot project, monitoring the CO₂ injected into the formation is a key part of the project. This monitoring will continue for several years to understand how CO₂ behaves or changes over time. The trial is meant to determine if this process and method is a viable way to capture and store CO₂ produced from fossil fuel-based generating facilities.

A quick check of Wikipedia shows a number of countries involved in geosequestration projects. The viability of these types of projects will be determined as these demonstration projects accumulate run-time data.

MP3 | iTunes

I saw a great process safety article in InTech magazine entitled, When failsafe isn't enough. It give a "howto" approach to volume tank sizing for reserve air pressure required for an orderly safety shutdown.

The author describes some cases where this reserve air volume might be needed, such as when failure position of safety valves are not in the failsafe condition or when operating conditions require and orderly, sequenced shutdown.

The equations to size the volume tank are given as well as who would typically supply the equation parameters. For instance, the valve supplier typically supplies the safety valve torque requirements and required leakage rates. The actuator supplier provides the torque-to-supply pressure tables. The good news for those of us a little rusty in our advanced math skills is that the equations are algebraic and the simplifying assumptions err to the side of conservative volume sizing.

I sent a link of this great article to Emerson's Len Laskowski, whom you may recall from earlier process safety posts. Len is a principal technical consultant, registered professional engineer, and certified functional safety expert (CFSE) and TÜV CFSE.

Len added that many engineers will tend to the conservative side and size the volume tank for several strokes of a valve, even if it needs to operate only once in a single stroke. This is mainly because extra capacity is relatively inexpensive, especially to mitigate the risk of a larger hazard.

He shared a reactor emergency depressurization example as a typical application where you might find volume tanks. Len wrote:

Typically, if this is a safety instrumented function (SIF) you want de-energized to trip failsafe. The emergency depressurization valves are Fail Open on loss of air. A spurious trip of this system would be bad news as the author suggests. It could create secondary hazards as is suggested in IEC 61511 that need to be identified.

For example, if the air failure was extensive a large number of vessels all depressurizing at once could overload a flare system. Too quick a depressurization of some chemicals could cause auto refrigeration that could lead to a cooling of the vent piping below design spec and the hazard of pipe embrittlement.

In some reactors, it would possibly blow catalyst out the vent system and possibly put stress on reactor beds, or trays that could damage the internals of the vessel, due to the large pressure differential caused by the emergency depressurization. These secondary issues also need to be managed and are reasons why volume tanks are needed.

Len has worked with process manufacturers to address some of these issues:

In some cases, a nitrogen or air bottle backup system would be used that have much more capacity than a volume tank. I have also seen cases where nitrogen is automatically switched in to back up a valve. This can be done by having a 3-way valve hooked up so that the common goes to the final element, one side goes to Instrument air and the other nitrogen.

You need some check valves to guard against reverse flow and have the valve actuator off the Instrument air so that it cuts off the nitrogen when instrument air is present. This is also a good setup when you have air motors that need a lot of air (gas) that need to move big valves. With nitrogen's toxicity in sufficient concentrations, these applications are generally outdoors, well ventilated, and require close review.

Len complimented the author on his article and added a few more considerations for process safety professionals. He wrote:

Other considerations that may be overlooked are common mode failures and testing. Typically, one would put two check valves in the system because failure of one would allow the tank to bleed out to the plant header. Also, care must be taken that the air is clean and no dirt is allowed to get to the check valves, so a filter/ separator is really required to ensure that the check valves have a good opportunity to operate.

Facilities to isolate the volume tank from the air supply and bleed the air upstream of the check valves are also required not only to check that the system works initially but also for future proof testing. Typically, these systems should be checked at the same time the safety instrumented system (SIS) is proof tested. This is an easy item to overlook and needs to be put on the testing schedule with the SIF's it supports.

I hope between the author's original article and Len's additional thoughts that there are some pearls you can apply in your process safety efforts.

MP3 | iTunes

Over the past several years, the Middle East has been a growing source for new process manufacturing facilities such as liquefied natural gas (LNG) plants and petrochemical complexes. Emerson has increasingly been involved in providing technologies and expertise for these projects.

I just saw a news item of the opening of a new Emerson facility in Dubai. A large cross-section of Emerson businesses are now located at this facility. From the release:

Emerson businesses with a presence at the new facility include: Emerson Process Management, Emerson Network Power, Emerson Industrial Automation, Emerson Professional Tools, Emerson Climate Technologies, and Emerson Storage Solutions.

Being the curious sort, I sent off a note to a friend I've known for many years, David Walker. David is a technical sales manager specializing in the DeltaV and DeltaV SIS systems. I asked him how it was to have so many of the Emerson businesses outside our Process Management group all together.

David shared with me how the very large projects they are executing require products and technologies from many of the businesses. He cited a few examples such as Network Power providing control room furniture, uninterruptable power supplies (UPS), and power conditioning equipment for on-site and remote buildings. From the Industrial Automation business, David mentioned variable speed drives, solenoid islands, and solenoid valves used in safety shutdown valves.

Even the building's Scroll compressors at the heart of the large air conditioning units that are sized handle the Dubai summer heat are from the Climate business.

Now knowing all the sharp-eyed folks who read this blog, I'll likely get emails for all the other things I didn't mention that are used in projects and in the building itself like motors, closet organizers, thermostats, and even the sink disposer units. That should hopefully head off a few.

The news also described:

...50,000 square feet of light industrial manufacturing and warehouse space...

David noted how this area is used to stage the large projects for project engineering and final acceptance before it ships to the process manufacturer's site for commissioning. Having colleagues across the various businesses together in one facility helps in the communication and project management of these large, complex projects.

It sounds like I need to put my head together with David's to figure out how I can wrangle a visit over there to see the new accommodations and the growing level of experts executing large projects. It could be a very interesting visit!

MP3 | iTunes

A few weeks ago, I wrote about a floating production, offloading and storage (FPSO) presentation shared with me. These, because of my background in offshore oil and gas production, personally fascinate me. As a freshly minted electrical engineer back in the day, I found it challenging to do projects on offshore platforms because they included safety shutdown systems, power generation and distribution, process control, and telecommunications.

FPSOs and floating liquefied natural gas (FLNG) vessels add challenges way beyond what I saw--navigation, thrust, ballast and much more complex processes to safely control.

Emerson's Knut Jorgensen and Wärtsilä's Ingebjørg Lien recently presented From MAC To "BIG MAC" For FLNG at the Commercialising FLNG Asia 2008 conference last month. The focus of their presentation was to discuss generic floating LNG plant design, technologies and expertise that Emerson and Wärtsilä combine to deliver.

The name Big MAC comes from the main automation contractor acronym that's been increased in scope. Engineering services extend to electrical, instrumentation, telecommunications and navigation. Wärtsilä adds dual fuel engines (natural gas and diesel), generators, thrusters, and power distribution systems to the main automation contracting services normally provided by Emerson--design, engineering, project management, and project execution around the instrumentation, control, and safety systems.

What reinforced my notion of vastly greater complexity was the breadth of scope in each area. For instance, in the safety and automation system area, the scope includes the production automation, hull automation, ballast and cargo monitoring and control, power management, safety, fire & gas, emergency shutdown systems, and the FLNG information management system (IMS).

This information needs to be shared among the crew, who are located on many levels of the vessel from the engine rooms and high voltage (HV) rooms down low to the engine control room, central control room and bridge at the higher levels.

Knut mentioned the goal for a successful project given this complexity is to do less work at the fabrication yard and pre-commission as many of the systems in modules as possible. This reduces overall engineering and commissioning time and finds the problems earlier when they are easier to solve.

Knut also believes that wireless instrumentation can be a cost-effective alternative for 20 to 25% of the onboard instrumentation measurements. Anything to reduce the overall weight on these vessels increases their efficiency. And, wireless devices help eliminate cables, conduit, cable tray, and the overall steel and space required. For a typical 17,000+ I/O system, this could mean $2 million USD in capital savings plus the ongoing weight savings, which translate into lower operational costs.

A final big challenge I gleaned was the global scope of these projects. The engineering, procurement, construction (EPC) contractors for both the hull and topside may be located in different regions, as are the owners, Emerson/Wärtsilä project center, and module fabrication sites. Global coordination and project management of resources in the U.S., Europe, India, Japan, Australia, China, Singapore and other locations is critical. Executing these as part of a "Big MAC" is an important step in reducing project risks, purchasing interfaces, and interface management.

MP3 | iTunes

I caught up with Emerson's Dan Jacobsmeyer this past October at the Emerson Exchange. Dan is a Flexconnect product specialist and a member of the migration best practices exchange group in the project management office. Dan started to mention some lessons learned on process automation system migration projects and my ears quickly perked up. This sounded like great stuff for a blog post.

Most people modernizing their control systems spend a lot of time in the system configuration with the I/O, control strategies, and graphic displays engineering everything properly in preparation for the cutover to the new system.

Dan's experience is that the source of a lot of the troubleshooting issues and time spent is often associated with the field instrumentation. A critical step in the migration process before the cutover begins is to verify that all instruments in the control system database are working prior to the cutover. Another key step is to find all the loops that are currently operating in manual mode and have a thorough understanding from the operators as to why this is so.

Dan cited some examples seen by the migration specialists that these checks have caught--known bad transmitters, missing process variable (PV) signals from multi-variable transmitters, short circuits caused by water-filled transmitter housings, missing agitator belts, disconnected field wiring, etc.

Each alone can be fixed without too much time and trouble, but when done as part of a complete system switchover, it can take much more time. This is because the source of the error can be anywhere along the path from the system to the instrument. It takes time to troubleshoot each point along this path.

After doing these checks and beginning the cutover, what do you do when instruments do not commission on startup? Dan suggests you disconnect the instrument from the termination panel and test the transmitter or final element. Test the field wiring for opens, grounds, or shorts. Simulate or source the loop to systems like the DeltaV system. Output current and test the loop. Finally, reconnect the transmitter or final element and test it again.

Dan also recommends you have spare instruments available, the specifications to all of the instruments, location drawings of the instruments, and an available instrument technician to field test the instruments where required.

Having the documentation and pre-cutover checks done can save quite a bit of time during the heat of the battle when the unexpected surprises occur, as the firm believers of Murphy's Law can attest they will.

Thanks for sharing these lessons and letting me pass them along, Dan!

MP3 | iTunes

I've known Emerson's Patrick Deruytter for many years. He's now the general manager for the Emerson Process Management office in South Korea. As his career has advanced, he's lived in many places--Minnesota and Texas in the U.S., Belgium and the U.K. in Europe, Australia, Singapore, and China. His experiences have included projects, project management, product marketing, lifecycle support, and general management.

He was in Austin last week and we had a chance to catch up. I found out he recently spoke at the Asia Pacific FPSO Summit with a presentation, Enabling Operational Excellence in FPSO. For those not versed in FPSOs, the acronym stands for Floating Production Storage and Offloading. When I worked in the offshore oil and gas industry in the mid-to-late 1980s, the overwhelming majority of offshore production came from fixed-leg platforms that set on the ocean floor.

Patrick highlighted some of the challenges and global trends for FPSOs. The first is the ever-increasing sophistication and complexity of the vessels and the onboard processing facilities. Oil and gas producers are building and modernizing FPSOs to meet the global needs for hydrocarbon-based energy.

Increasingly, FPSO owners want all of their systems integrated--navigation and propulsion systems, integrated automation systems (IAS), custody transfer systems (CTS), etc. Given the fast track nature of FPSO projects, equipment deliveries and skilled project engineers are critical for on time, on-budget performance. Once commissioned, the systems need to be highly reliable and easy to maintain, given the marine environment in which they operate.

Integrated systems provide a single window into the oil & gas production processes, subsea control processes, management of onboard assets, safety instrumented systems, and vessel automation processes (ballast control, offloading, power management, tank washing, etc.)

The design of the processing facilities on FPSOs is becoming extremely modular. This helps with the construction phase while the vessel is in the shipyard, and makes engineering, installation, and commissioning more manageable. The major processes like separation, gas dehydration, gas injection, oil metering, seawater treatment, power generation and distribution, custody transfer, etc. are pre-built, instrumented, and set on the deck of the vessel for integration with the automation and safety systems.

The modular trend extends to the wiring. FPSOs are moving away from large central control rooms toward remote I/O and control stations distributed among the production modules. This reduces the size of the total control room footprint, which is quite expensive on these ships. It also reduces cable runs, which reduces overall weight. And the modular design lends itself to modular pre-assembly and pre-testing which reduces overall commissioning time. Typically, the earlier you find problems, the easier and less expensive they are to resolve.

Patrick listed products across Emerson Process Management and alliance partners used in large marine projects like FPSOs and FLNG (floating liquefied natural gas) vessels. The list included DeltaV automation systems, DeltaV SIS safety systems, AMS suite software, Scanjet tank cleaning, Wärtsilä power distribution / engines / drives / vessel automation / propulsion systems, Rosemount tank radar level gauging and measurement, Fisher valves and regulators, Daniel metering and custody transfer, Micro Motion flow meters, and Valve Automation offshore valve systems.

These technologies have been applied in some of the world's largest FPSOs including ExxonMobil Kizomba A & B, BP Angola, Pemex, and Total, to name a few.

Patrick closed his presentation on WirelessHART wireless devices and how they are being incorporated in applications like wellhead annular pressure and heat exchanger pressure monitoring. This additional monitoring helps more quickly spot abnormal situations and reduces the manual clipboard and keyboard entry work processes.

The level of sophistication and technologies applied to these marine applications has come a long way from my days back in offshore oil production two decades ago!

MP3 | iTunes

A hot cutover post from several weeks ago featuring Emerson's Aaron Crews prompted a question from another Emerson project professional to Aaron. The question described an upcoming hot cutover project and asked Aaron to share any additional thoughts he had. For those unfamiliar with this jargon, a hot cutover is the process of converting to a modern process automation system while the process is still running.

In addition to sharing the detailed step-by-step process developed by The Automation Group (part of the Process Systems and Solutions organization in Emerson), Aaron shared these thoughts with his colleague:

Hot cutover execution is not necessarily too tough of a task as long as you know what you've got. The most important thing about a hot cutover is to have all of your information together and organized. You'll want to have survey information for all of your valves, including whether there are bypasses or hand jacks. If there are not bypasses on the valves, you'll want to review those cases with operations and the process manufacturer's engineers to ensure that they can lose that valve for a few minutes (maybe they can fill up a tank before cutting over the inlet valve, for instance.) If they can't lose valve function, there might be a workaround - you might have cases where the valve is normally at 100% and you can use a mechanical stop to keep it from failing closed, etc. Find an instrumentation expert to help you with any of these situations.

From a software standpoint, it is usually possible to put the I/O point in manual or to bypass logic that uses the point, but it is (as always) paramount to know all of your control references and complex loop functions on both the new and old DCS. Again, as long as you have all of your information you are ok-it's what you don't know that can get you in trouble.

The other major planning task is the cutover order. We typically cut over by graphic since the operator will have to be operating off of two DCSs at once. Within the graphic, we cut over indicators first (temperatures and pressures before flows, generally), then control loops then shutdown loops.

Overall, we just try and stay organized and keep all the documentation together. We generate reports at the end of each day that list the proposed points to be cut over the next day. These reports contain any field survey notes (that valve information from earlier), drawing numbers, wiring information and controls references on the old and new DCS for each point. This list is reviewed with operations and the specific order and specific operational concerns or strategies can be discussed during a daily meeting with operations, engineering, construction and safety leads.

We also track cutover progress very carefully to ensure that we are staying on schedule, and we keep a master list of loops as a cutover sign-off document.

The specific cutover procedure per point is typically pretty systematic, except in those problem cases that you will have defined.

I hope you see a few nuggets of wisdom you can use in planning a modernization project which includes a hot cutover at your facility. Also, I hope that I still get cc'ed on emails like these. One never knows when a blogger might add a little visibility to a good email!

It must be one of those weeks where a theme accidentally emerges. This week, it's discovering things to write about courtesy of Twitter. The subject for today's post comes from Aaron Crews, a principal control systems engineer with The Automation Group (TAG). TAG joined Emerson earlier this year.

Aaron's tweet alerted me that he's tackling a project with a hot cutover. For those unfamiliar with the term, it's converting over to a modern process automation system while the process is still running. It takes careful, detailed planning.

Aaron shared the cutover planning process with me on this DCS modernization project. The tasks include cutover scheduling, logistics planning, sequence planning, safety planning and cutover documentation.

Cutover scheduling requires all prerequisites be complete, including the control system configuration and installation, operator training, etc. The scheduling must take the overall operating conditions and plant maintenance activities into account.

The cutover logistics planning choreographs the space requirements and movements of the old and new equipment since both are in operation as the cutover is performed. Power, communications and other connections must be part of this planning since operator stations and I/O cabinets may be temporarily located during the transition process.

The cutover sequence planning looks at the order the process units will be converted from the old system to the new. Generally, a back-to-front order is used unless process conditions dictate a change. A key consideration in this phase is the switchover of the operators' graphics. During this cutover process they are operating on both the old and new operator consoles. The plan needs to make this as easy as possible to operate during this switchover period.

Cutover safety planning is critical. All of the established plant safety procedures must be followed. For U.S.-based hot cutover projects, a pre-startup safety review should be conducted in accordance with the Occupational Health and Safety Administration (OSHA) Process Safety Management (PSM) requirements. All team members must have completed the established plant safety-training program and must have the proper safety equipment.

The cutover documentation includes the collection and organization of all the required drawings and cutover reports. A process tracking system is created to ensure that all documentation is checked and that the cutover proceeds per the scheduled plan and that any required changes are noted.

For this particular project as with all hot cutover projects Aaron and his team identify the cutover challenges, associated risks and possible solutions--the earlier the better. This process begins with the initial field survey. The earlier these challenges can be identified, the better the planning and required solutions can be engineered in advance. In the detailed engineering phase, the best engineering solutions are determined for these challenges give the associated risk, cost and schedule considerations.

Aaron shared a few of the challenges on his current project, which I'll share in a future post. If you've planned or participated in a hot cutover, how does this compare with your process?

I just read a great article, How to Achieve Competent Workforce for Safety, in the May edition of Automation World magazine. Written by editor-in-chief, Gary Mintchell (also of Feed Forward blog, Automation Gear blog and Twitter fame), this article looks at the people side of ensuring safety. It examines some of the existing regulations and standards around competency, views from both process and discrete automation suppliers and views from safety-focused organizations.

Emerson's Chuck Miller is quoted in the article and has long articulated the role of people in effective safety programs. The article notes that both the U.S. Occupational Health and Safety Administration (OSHA) and the global IEC organizations, through the IEC 61508 and IEC 61511 standards, "state that people involved with the safety lifecycle must be competent in the area in which they deal."

The safety lifecycle covers a broad spectrum of responsibilities, and Chuck notes, "even people we consider to be safety experts may not be expert in all areas of the lifecycle. For example, a reliability engineer may know a lot about the equipment, but may not be able to competently go into the plant and effectively calibrate and maintain that equipment."

The article describes the top-down support and commitment to build a strong safety culture with competent people across all phases of the safety lifecycle. To help in this competency requirement, Emerson developed a safety management system built according to IEC 61511 and had its processes audited and certified by TÜV in 2006.

A safety management system should clearly define the organization, competency policy, safety audit procedures and the safety lifecycle activities. Good guidelines exist to help. The United Kingdom's Health and Safety Executive (HSE) in 2007 published, Managing competence for safety-related system, Part 1: Key Guidance. It includes 16 principles across the plan, design, operate and audit/review phases of the safety lifecycle.

Emerson's safety management system defines clear policies and processes, roles, role competency requirements and the training/experience required to achieve the identified skills for each role. Examples of roles in the project phase are SIS consultants, SIS project leads, SIS software engineering personnel, SIS hardware engineering personnel, and SIS field equipment engineering personnel. In addition to an employee's work experience, a key part of Emerson's safety competency requirements program is the Certified Functional Safety Expert (CFSE) certification. I did a quick search on the list of CFSE/CFSP certified safety professionals and counted more than 60 global Emerson folks that are now certified.

I caught up with Mike Boudreaux to find other ways that Emerson helps end users to address their SIS competency requirements. Thorough knowledge of the entire safety system is important. Competency requirements should apply to all of the components that make up the SIS, from the sensor to the final element and everything in between. Here are some ways that Emerson is helping:

• SIS Seminars that include a safety overview, discussion of SIS applications and a discussion of the safety lifecycle
• PlantWeb University SIS courses that are free online courses that provide a good overview of IEC 61508/61511 safety lifecycle concepts.
• Process Safety Training Courses that cover the Analysis and Realization phases of the IEC 61511 safety lifecycle
• Training courses on the SIS components that Emerson supplies, including the sensors, logic solvers, final elements, and safety lifecycle tools.
• Emerson has supported the development of the CSFE/CSFP programs through participation on the CFSE Governance Board. The governance board is an independent board that administers certification tests for CFSE.

Mike also points out, "competency goes beyond knowledge of the concepts and technologies that are used to implement an SIS. Good design and implementation reduces the random and common cause hardware failures. It is in preventing the systematic failures where managing competency throughout the entire safety lifecycle becomes so important. For many end users, this means that developing competency management in the Operation phase is very critical."

Knowledge of the process application and the hazards involved is a must. IEC 61511 also calls out the need for "adequate management and leadership skills appropriate to their role in the safety lifecycle activities" as part of competency. This has a lot to do with the type of people that you employ and the company culture that you develop. It is not something that can be created overnight and it takes a long-term commitment to be successful.

Update: Welcome Feed Forward blog readers!

I received an email from Anand Iyer. He's a certified project management professional (PMP) and a project manager in Emerson's engineering center in Pune, India. His project experience covers the gamut from pharmaceuticals, bulk drugs and intermediates to oil, gas and petrochemicals.

He's sent me a paper he's written entitled, Collaborative Measurement Control System Engineering. It describes how measurements close to one another in the process can collaborate with one another to verify their operation. He describes an example around a distillation column:

Now let us take two temperatures (bottom temperatures) in a distillation column and a level measurement. When the level is normal, the two temperatures are same or have a fixed relationship between them. TI1 is placed at a lower level in the column (near bottom) and TC2 is at a higher level (and used for Temp. control). Now TC2 is generally used for control. We can safely say that if Level is normal, and TC2 is under maintenance, TI1 can be used for control (with a minor adjustment to Setpoint if required). Thus Level and Thermocouple TI1 put together can "collaborate" the measurement of Temperature-measurement TC2.

Anand contrasts the traditional approach to a failure with how collaborative measurement strategies can be used in control strategies to avoid outages or process disturbances. In the traditional approach:

...the first thing done if an element were to fail was to swap the elements (either during the shutdown caused by the failure) or by a planned outage or having the loop in manual and doing the swap. At times, we have also used our ingenuity and just swapped the wires at the analog inputs and tuned control setpoints to have the plant up and running in a very short time. And hopefully, in all that chaos, someone had the presence of mind to record the swap on the wiring diagrams.

Using a collaborative measurement strategy:

...says that if level is not low and TC2 is not available then TI1 can be a valid measurement. We alarm the operator that TC2 is not available, fine tune the setpoint if required... All this occurs automatically and there is no outage or disturbance that could result in quality issues.

He extends the thought to Foundation fieldbus devices where the final control elements themselves can perform the logical evaluations and select the available primary or collaborated measurement, increasing the overall robustness of the control strategy. Anand also extends his thinking to wireless devices and how they could be used in a collaborative measurement environment--not as a primary measurement, but as a collaborative measurement to check on other devices nearby.

I hope you'll give Anand's paper a read and add your thoughts.

My RSS feeds pointed me to a great ChemicalProcessing.com article on batch manufacturing alarms. The article, Rethink batch-manufacturing alarm systems, was written by Joseph Alford.

He opens with provocative questions:

Do operators sing the praises of your plant's alarm system? No? Well, do they at least agree that generated alarms represent real abnormal situations requiring a response and that the automation/control system presents alarms in a timely, accurate and reliable way? No again? Well why not? Aren't operators the primary customers of your alarm system? Perhaps it's time for an alarm remediation project.

Many with continuous processes would agree that their alarm strategies implemented inside their automation systems need work. The complexity is amplified in batch processes because unique operating conditions are created within all of the numerous steps along the way.

The article boils down the crucial steps to take:

The key considerations in achieving effective alarm systems include defining objectives early in a project's life (i.e., in a plant's alarm philosophy or a system's functional requirements), adhering to the definition of an alarm, and implementing alarm-management best practices.

I ran this article by Todd Ham, a senior principal engineer in Emerson's Life Sciences industry organization. You may recall Todd from earlier posts.

Todd agrees completely that a successful alarm strategy begins in the functional requirements stage of a project. The project teams work with pharmaceutical and biotechnology manufacturers early on in a project to document their alarm requirements.

Todd stressed that a good strategy examines not only what conditions require an alarm--typically an adverse effect to personnel, product, or equipment--but also what is the desired response. Is alarm annunciation sufficient? Does this require a device interlock? Should this put the batch in hold? Does quality assurance (QA) need to be notified? This is called exception handling.

In a batch process, the requirements may differ based on the process step. For example, the alarm may be critical during processing, but not important during cleaning. Further, the alarm may only need to be monitored once the process is at steady state. In these scenarios, the control strategy developed by the project team will selectively enable/disable alarms at the appropriate point in the sequence.

Todd cautions that this is not a "one size fits all" exercise. The project team and manufacturer's staff must step through each process unit/system and ask a series of questions to arrive at a solution where alarms are both appropriate for a particular operating state and relevant for alerting operators to abnormal situations.

Todd agrees with the author that this work must be done up front, or the alarm flood, nuisance alarm scenario described in the article will be the result. You can't wait until the end of the project to think about alarm management. When you come right down to it, it's just as important as defining the control requirements for the project.

Emerson's Chuck Miller is one passionately guy when it comes to process safety and the international safety standards, IEC 61508 and IEC 61511. He is on a mission to put the focus of functional safety management where he believes it belongs--on the competency of safety professionals involved in the safety lifecycle.

Chuck noted a panel discussion he sat in on at last fall's ISA Expo in Houston. The panel discussed various approaches to process manufacturing risk mitigation. These included combining control and safety in the same control system platform, the standalone safety instrumented system (SIS) approach, and the separate-yet-integrated safety system approach.

An end user on the panel discussed the common platform approach. He emphasized that his company's internal policies and procedures for risk assessment, implementation, operations and maintenance were well understood and consistently applied. These factors drove the decision to implement systems in this manner.

A safety instrumented system supplier discussed the standalone SIS approach and one of Chuck's colleagues discussed the separate yet integrated approach that is represented by safety instrumented systems like DeltaV SIS. Using several advanced technology examples including advancements in diagnostic coverage; common programming environments and global databases the presenter illustrated how such technologies, when appropriately applied, provided measurable savings throughout the safety lifecycle without compromising the SIS's ability to conform to international safety standards, such as IEC 61511.

Chuck's revelation was that the real issue is not so much the philosophy, the approach, the architecture, or even the platform selected. What really drives a successful SIS implementation is competency. Each of the presenters was passionate about their approach being the best solution because their individual competency was based on that particular philosophy and approach.

His bottom line--functional safety management must be implemented around the requirements of a technology and supported by competent safety professionals that always ensure that the SIS solution is defined, designed, installed, operated and maintained in a way that meets its defined functional safety requirements throughout its lifecycle.

As this group of panelists demonstrated in their exchanges with the audience--there are several philosophies, architectures and platforms to mitigate process manufacturers' safety risks. It takes competent safety professionals to work with these throughout the safety lifecycle.

I'm returning back to the U.S. from a week of meetings in Thailand. I'm struck by the sheer number of large greenfield projects being implemented and being planned across the Asia-Pacific region.

Over the past several years, Emerson project teams from this region have executed and are executing many of the mega-sized projects. Some examples from prior press releases include: Shanghai SECCO Petrochemical ethylene complex, Fujian LNG-import terminal, and Reliance Life Sciences therapeutic proteins manufacturing.

These projects are executed on a global scale with participation from project engineers from many countries in many world areas. Advances in communications and what can be done across the internet make global project collaboration and management possible.

While in other world areas we see a lot of experienced automation professionals retiring, in this world area a new generation of automation professionals is coming on the scene. They are learning the automation craft as these projects are executed and the new plants are operated.

Working on greenfield projects mean these new automation professionals get to use the lastest technologies like digital busses, controller-based advanced control, and enterprise connectivity to build plants that are more efficient than what is possible with prior technologies.

With my visit and new connections made, I hope to bring more stories of Emerson experts from this bustling region of the world.

A colleague recently pointed me to a Manufacturing Business Technology article, Red alert: Increase in process automation heightens need for safety-related systems. The article points to a recent Frost & Sullivan study which predicts the market for safety-related systems used by process manufacturers will more than double from 2006.

Quoting from the account of this research report:

It says users will welcome systems that address the underlying challenge of minimizing the trade off between process uptime and process safety. In addition, users will favor vendors that have significant technical experience in installing complex integrated safety solutions that monitor safety and non-safety functions while reducing the costly channels of diversified communication.

Over the past several years of blogging, I've discussed safety instrumented systems and the associated global standards, IEC 61508 and IEC 61511 on numerous occasions. Newer architectures like Emerson's smart SIS incorporate digital communications so that the complete safety instrumented function (SIF) can be continuously diagnosed to help the function perform when it should and not when it shouldn't.

Rather than being prescriptive and instructing process manufacturers what to do, the safety standards are performance-based. IEC 61511 allows you to investigate the alternative solutions for the right safety instrumented function for the safety integrity level (SIL). This means that more engineering work may be required to investigate these alternatives to find the best solution.

I think this where the "technical experience" part of the quote from above comes in. Emerson's Len Laskowski said it best in an earlier post:

This is great news for the engineering community because they get to do the engineering. However the bad news is they must do the engineering.

As process manufacturers address their risk-mitigation strategies and comply with the IEC 61511 standard, they will continue to work closely with those that can provide the technical expertise required throughout the safety lifecycle, from front end engineering and design to ongoing system maintenance.

Engineers being the problem solvers that they are, typically enjoy a project in full execution mode. Problems must be quickly confronted and solved to keep everything moving forward. As we've mentioned in earlier posts, the part they typically like least is the upfront justification to get the projects approved in the first place.

Emerson's Pete Sharpe, a principal consultant in the Advanced Automation Services organization, shared his thoughts on automation investment justification with the readers of Automation World magazine. The article, Strengthen Company, Minimize Risk, pointed to areas of opportunity for project justification.

Pete's guidance is to look at the economic buckets your efforts in automation can influence, which boils down to increasing profits and minimizing risk. Simply put:

To increase profits, "you must either increase revenues or lower costs," he emphasizes. Revenue is a bucket on the positive side of the formula that is affected by things like throughput, yields, recoveries or product price. That means "you have to shift production toward the more valuable products, or increase yield, reduce off-spec, product losses and downgrades of product," Sharpe states. Cost-lowering considerations could involve maintenance, labor, energy, utilities or raw materials, among other areas.

Pete cites an example of looking at quality. Poor quality can lead to customer rejection, off spec and rework. Providing better quality than is specified in the contract is called "quality giveaway". It likely means additional costs are being incurred without receiving additional price for this quality. This is particularly relevant to commodity markets such as gasoline and diesel. Other potential sources of justification are in intangible costs like safety and environmental compliance.

Minimizing risk is about reducing the probability that something bad will occur in the plant's operation. These projects focus on improving reliability, safety, environmental liability, and dealing with abnormal situations. Risk can be evaluated based on the frequency and severity of historical incidents. Then appropriate application of technology and programs designed to mitigate the highest risk areas by applying such things as predictive maintenance, operator training systems or abnormal situation prevention technologies.

The key is to look for how your project will affect the throughput, production costs and total production value on an on-going basis. Ultimately, the expected financial return of the project will determine whether the project goes forward or not. The article sums this up:

...the ultimate metric for justifying investments is ROI. He notes that it includes the time value of money, and calculation of returns based on expected future cash flows from the investment.

In most companies, the management team evaluates potential projects based on the expected return and the risk associated with the investment. The projects with the highest rate of return and lowest perceived risk are those that will likely be funded. In almost all cases, the project return must exceed the manufacturer's cost of capital, which varies depending on company. Pete notes that there are exceptions where a low return, discretionary project is approved. This could be a "stay-in-business" investment decision, which ultimately is about reducing overall business risk.

In the process of moving hydrocarbon through the supply chain from producer to consumer, terminals play an important role. They receive liquids and gases from many sources including ship, rail and pipeline. These gas and liquid hydrocarbons are stored in tanks or vessels until required to move via other methods of transportation including barge, truck and pipeline.

I had the chance to view an upcoming article featuring Emerson's Cor Vermeijs. He's based in the Netherlands. The article explored ways for terminal operators to use automation to optimize the inventory management and operational efficiency of their terminals. The goal is to improve the quality, productivity and availability of the terminal and help the owner of the terminal lower the costs of operations and maintenance, improve environmental and safety compliance, and reduce energy usage.

He notes that many terminals today are manually operated from planning all the way to manually operated valves and pumps. This limits the availability of real-time information to make the most efficient schedules. These delays affect the throughput of the terminal, which directly affects its profitability.

In the article, Cor stresses the starting point should be to study the current operational processes. The key is to look for areas of inefficiency that can be automated. The study typically includes a cross-section of the organization from operations, sales and management. The output of this study is:

...a plan to optimize these processes, to automate them, and to implement them wherever necessary. The results of this site audit are issued in a report that gives the solution for the concept, a cost-benefit analysis, the payback period and a performance guarantee. It's all based on the best possible use of the storage tanks, the pumps, the pipelines and the jetties. The objective is as many product movements as possible without running the risk of product contamination or tank overfills.

Architecturally, when manual processes are automated, the information is collected in a single system. This information becomes the basis for a route planner. The system takes the recommended route with the corresponding pipeline segments, valves and pumps and links it to the data from the work order. This information can include the time when the route/transfer can be started, how long it will take, which ship or train will deliver the volume, and who is the owner. Cor sums this up:

...all information is available not only to the operator in the control room, but also to the man on the jetty, the planner and perhaps even to the captain of the unloading or receiving vessel. And it all takes place in real time, with immediate feedback of events such as a delay along the line, so that you can adjust your planning while the work goes on without interruption, thus increasing your terminal's efficiency.

Terminal management includes a number of processes including custody transfer accounting, inventory tracking, security management, loader or driver verification, load requests and initiation, permissives management, ticket generation, custom reports, remote dock monitoring, event logging, and system integrity management.

Successfully executing a project with safety instrumented systems requires trained and competent project team members. They must be versed in the safety lifecycle as required by international safety standards--primarily IEC 61508 and IEC 61511 (ISA 84.01 in the U.S.) for the process industries.

To address this safety expertise requirement, TÜV and exida along with the support of other global safety experts created the Certified Functional Safety Expert (CFSE) concept. Its mission is:

...to ensure that personnel performing SIS lifecycle activities are competent as required by the IEC 61508, 61511, and 62061 [machinery safety] standards.

Currently there are two levels of certification, CFSE and CFSP (Certified Functional Safety Professional). The difference is mainly in practicing experience--ten years for CFSEs versus two years for CFSPs. The CFSE.ORG website describes the difference:

The CFSE is the higher level certification and is aimed at professionals who actively lead, coordinate and review the more complex and demanding activities in the Safety Lifecycle in leadership positions including SIL selection and SIL verification.

The CFSP is targeted at professionals who need a thorough understanding of the Safety Lifecycle activities at the execution level without necessarily leading, coordinating or reviewing the more complex and demanding activities.

CFSE.ORG reports that there are currently over 200 CFSEs and CFSPs in practice worldwide. The certification process is not easy. Those trying to take the test are warned:

...the certificate exams are extremely rigorous and often demand significant preparation in order to achieve the 80% passing grade for both exams. With this in mind, the Governance Board strongly recommends that all candidates develop an in-depth study plan to properly prepare for the examinations. The topics covered in the different exams and sample Process Applications Exam questions provided in the Specialties and General Information pull-down menus may be helpful in developing an effective study plan.

In view of the comprehensive nature of the exams, the Governance Board recommends that candidates put in at least 40 self study hours as part of their preparation for the CFSE/CFSP exams.

I bring all this up because I received a note from one of my colleagues in Calgary in our Hydrocarbon and Energy industry center. The news is that they have some newly minted CFSEs--David Goerzen and Ajmal Siddiq. Congratulations on your achievement!

I went out to the CFSE.ORG site and did a search on the 15 pages of CFSEs/CFSPs. As of today, November 27, 2007, I counted 38 Emerson CFSEs and 8 CFSPs. This is more than 20% of all the certified safety professionals in the world. The percentage is higher if you exclude the machinery safety professionals.

The organizational roles of these safety professionals run the gamut including projects, support, technology, sales and marketing. These organizations work with process manufacturers at various stages of the safety lifecycle to help meet their risk reduction goals.

There may be reasons why you need to consider something beyond your automation system that has been running in your plant for years and years. It might be the need to more tightly control energy usage to reduce energy costs. It might be to improve quality and consistency to stay ahead of your competitors. It might even be that you are losing peoples' expertise to retirement to maintain this automation system.

The vernacular for this process varies--modernization, migration, or upgrade--but planning is an essential component. I caught up with Laurie Ben, who directs a team of modernization consultants in Emerson's Process Systems and Solutions business. They have expertise in Emerson systems and systems from other automation suppliers. They also have methods and tools to design a migration solution.

This migration process can range from a simple connection between systems all the way to a "rip and replace" project, depending on the business drivers prompting the change. Some plants have existing pneumatic and panel-mount controls. Downtime and reliability concerns often provide the justification required to transition these to the current digital communications-based systems.

These digital technologies provide ways to do hot cutovers to keep the process running while the automation is migrated from pneumatic to digital. An example of how this works is a Fisher Foundation fieldbus-based DVC6000f digital valve controller. Its pressure control functionality connects to a DeltaV system while also sending a pressure signal to the existing actuator or pneumatic positioner. Once these pressures are balanced within the system, control is transferred to the digital valve controller. During this phase, AMS Device Manager helps finalize the cutover by helping the team to communicate locally with the valve to monitor exactly what is happening during the process of mounting, adjusting, stroking, and calibrating the valve.

Laurie mentioned that operator consoles typically have the shortest life span of all the automation system components. It is often the first consideration for migration to a modern automation system. Newer operator workstations keep the look and feel of the operator graphics and faceplates and connect to the existing automation system. Over time, I/O and controller hardware and software can be migrated. The business drivers help dictate the pace of migration.

For instance, if energy cost reduction is the business driver, it may make sense to modernize the controller and I/O to get embedded advanced control capabilities. Units like lime kilns, fired heaters, boilers, etc. can be run more efficiently as a unit with model predicted control than as a collection of interdependent loops.

It really begins with your business drivers and developing a plan to move forward to modernize your automation. The hardest path is to justify it based on obsolescence since the calculation of ROI based on problem avoidance. The best path is to find cost reduction or efficiency-improving opportunities. These numbers are the basis for your financial justification calculations.

You may have seen quite a bit of news coverage (here, here) on wireless technology as it applies to plant instrumentation. At the recent Emerson Exchange, Emerson also announced some wireless news.

If you are an automation engineer, you might have thought about some applications where you would like to try this technology.

Your best course is to start with a simple business case. Perhaps the operators perform rounds to get readings from gauges and instruments not connected to the automation system. Having this information and associated diagnostics coming from wireless devices could possibly make your plant's instrument technicians more efficient.

I caught up with Mark Sagstetter in Emerson's Rosemount Measurement business. He recently went to a refinery along with John Biscone, a service technician in Emerson's Instrument & Valve Services business. Operator and instrument technician efficiency was the very business case this refinery was pursuing. Mark and John were contracted to provide their expertise to help plan the network and installation process of the wireless instruments and gateways. Much like the early days of digital bus technologies, this expertise can help automation engineers establish best practices for planning and executing future wireless installations.

In the course of a two-day site visit, they worked with the plant engineers and identified five process units including four tank farm locations that met the criteria for increasing operator and instrument technician efficiency.

My understanding when talking with Mark is that there are basically two overall best practices to follow when implementing a wireless field network. The first is planning the wireless network and the second one is the network installation.

When executing the best practice of planning the Self-Organizing wireless networks, Mark and John like to have scaled site drawings. Unfortunately, in this case, scaled drawings were not readily available. Necessity being the mother of invention prompted the team's great idea to use Google Earth to generate site maps. They used the printouts during the walk-through of these process units to help envision device locations, gateway locations, plot anticipated communications, and to help identify possible impenetrable situations.

As part of the best practice of planning the network, it is a good idea to plot at least two paths of anticipated good communications for each instrument. Using a color-coding scheme, with one color to mark anticipated good communications paths and another color to mark potentially interrupted paths of communication, John and Mark were able to use this process to help understand how the network may function when installed. It also helped to understand, plan for, and possibly eliminate possible pinch points and/or possible impenetrable situations before the actual installation.

With every Self-Organizing wireless instrument being capable of being a router (sending and receiving messages from other instruments), possible pinch points and impenetrables are easily overcome. This is accomplished with the addition of measured points or instruments that act as routers or range extenders.

During the installation-planning portion of the site visit, Mark and John recommended the plant engineers follow the wireless installation best practices. To do this, the plant engineers would need to power and commission the gateway first. Then install, power, and commission the instruments, starting with the instrument closest to the gateway and continue working outward from the gateway. The instruments' connectivity to the gateway should be verified each time after installing, powering and commissioning the instrument.

One thing I noted in my conversation with Mark is that the instruments mount with standard process connections. Engineers have been using these standard connections for years. The actual mounting location for the instruments and gateways were determined by providing a forearm's length (a measurement device every instrument technician has with them at all times) of space between the antennas and any wall or metal structures to avoid signal attenuation.

Installation would continue by powering, installing, and commissioning instruments outward from the gateway, until all the devices have been brought on-line. By installing the instruments in this fashion, the actual formation and connectivity of the wireless Self-Organizing network can be compared with what was expected during the best practice of planning the network.

Beyond the immediate need to help the plant engineers plan a smooth installation at this refinery, Mark and John helped them establish best practices to aid in future wireless projects/installations.

Jack Murray, a member of Emerson's Metals, Mining, and Minerals industry team, shared a paper he had co-written with an Alcan Gove bauxite mine and alumina refinery staff member and Emerson fieldbus consultant, Sudhir Jain. Alcan was recently purchased by Rio Tinto.

Their paper, Fieldbus Technology on a Large Scale Mineral Project, describes Alcan's path from the 4-20mA analog world to a digital bus communications world. Alcan's investigation of the benefits of moving from analog to digital began in 1999. They had seen possible ways to reduce their project costs and improve operations by using digital busses.

Their first step, like most when undertaking something new, was a small step. They chose to implement Foundation fieldbus in a non-critical area of an existing facility. Their initial installation consisted of 20 I/O. They chose fieldbus devices from a number of automation suppliers to obtain a greater breadth of experience. They also chose Profibus DP for their motor control centers and variable speed drives.

This experience proved beneficial when the decision was made in 2004 to nearly double refinery capacity to meet growing demand. The project consisted of 5,000 field devices and 15,000 total I/O including motors and drives. They used a DeltaV system and the two digital busses, Foundation fieldbus and Profibus DP, for which they gained experience to connect the majority of this I/O. A key part of their decision was to work with Sudhir during the front end engineering design (FEED) process to assist in the segment design, training of key personnel, and to establish wiring best practices and standards.

Sudhir related to me how they developed new hazard analysis procedures (CHAZOP, short for control HAZOP) to ensure that failure of any bus segment would not leave a critical part of the plant unmonitored or uncontrolled. Segment segregation practices were developed to address the findings from this analysis. They also had a 3D model of the plant site, so that questions of distance and pathways could be quickly addressed to help rapidly advance the engineering effort.

They chose a modular construction approach using pre-assembled modules (PAMs). These modules were assembled and fitted off-site and fully pre-commissioned before they were delivered to the plant site. These PAMs were self-contained units and included process vessels, piping, pumps, instrumentation and valves, all fully wired and tested.

The digital busses fit into this modular approach with test procedures developed and a portable DeltaV system used to test field devices and fieldbus segments within the PAMs. Once delivered to the plant site, it was much faster to hook up fully tested segments than to individually terminate and retest devices as had to be done on their analog-based projects.

The project team followed elements of the Construction Industry Institute (CII) PepC model. The paper describes this model:

In the new model procurement transactions for the most critical elements of the project (indicated by capital P) happen first and to a large extent define the next step, the main body of the engineering effort for the rest of the project (Capital E). This is followed by procurement of the materials for the rest of the project (small p), followed by the actual construction (capital C).

This model helped Alcan take advantage of the expertise of the suppliers involved in the project and aligned with their globally distributed engineering and procurement practices. It also supported their modular approach and the use of PAMs.

As with most every bus-based project, they documented savings in cabinet space, installation and commissioning. The real value was in the accelerated project timeline. In five fiscal quarters, 95% of the engineering, 76% of the PAM fabrication, and 54% of the on-site construction was completed. Alcan was able to meet their aggressive project schedules and get production on-line sooner.

Update: Welcome readers of Carl Henning's PTO PROFIblog. I'm not sure about the "voice of reason" part, but like Carl, I certainly agree that the benefits from the digital bus technologies outweigh the change in status quo from the analog world.

Read the Crossing the Chasm article to which Carl refers and judge for yourself. Feel free to let me know what you think.

While at the recent ISA Expo 2007, I had the chance to listen to Emerson's Jonas Berge's presentation on software for automation. Jonas is an active member in the ISA SP104 committee. This committee is responsible for advancing the Electronic Device Description Language (EDDL) standard.

A few years back he wrote a book, Software for Automation: Architecture, Integration, and Security. His presentation covered some of the ideas from the book. Specifically, he discussed these key points:

• Select technologies for software architecture
• Justify investment to management
• Where and how to deploy DCOM vs. Web
• Where each OPC flavor is used and how
• Integrate with business and coexist with legacy
• Troubleshoot DCOM and OPC
• Apply software and make the PC rugged
• Engineer and document software
• Backup, administer, and optimize
• Make it robust, safe, secure, and 21 CFR Part 11 compliant

The body of knowledge that an automation professional must understand to perform their job effectively continues to expand. As Jonas describes, the software architecture is as important to design as the hardware architecture. Information flows from devices connected from digital busses all the way through the automation systems to enterprise-level software applications.

Security concerns must be addressed and be part of this design. Cyber-security is an area of specialization unto itself and you can follow many of the issues and advancements at the Digital Bond and Unfettered blogs.

Jonas describes setup of networks and OPC, ODBC, and web services communications across networks and tips for troubleshooting these. One everything is functioning properly, methods of management and administration including backup and restore procedures are covered.

Jonas highlights the fact that this is a lot to plan and get right. If you find yourself overwhelmed and too busy to become an expert in this area, you are not alone. Many process manufacturers are working with their automation suppliers versed in this level of expertise to help on the project front-end and to help maintain these software packages and integration methods through their useful lifecycle. One example is Emerson's SureService support services.

Emerson's Mike Schmidt, a principal safety consultant in the Refining and Chemical industry center, presented Beyond 2oo3: Multi-sensor Architecture in SIF Design at the Emerson Exchange. You may recall Mike from an earlier post.

Mike discussed several cases and applications where more than three sensors are used in safety shutdown applications. Redundancy was his first example where more than one sensor is being used for the exact same purpose. An example is separate temperature sensors installed on the inlets to multiple reactors, perhaps because of fears of common cause failure. In fact, all three of these sensors measure the same thing. The inlet temperature is coming from the same header, so it is the same for all three new sensors.

Separate hazards are those serving unrelated purposes or are at independent points in the process. There is no redundancy here. The only possible architecture for the sensors is to have three separate instances of one-out-of-one (1oo1) voting.

Mike built the case of three tanks with three inlet temperatures sensors coming off a common header and said it could be argued that the three could be considered redundant. However, three sensors on the tank outlets could not be considered redundant since they are monitoring for separate hazards.

When evaluating fault tolerances, it is important to consider the number of success paths. Parallel paths provide redundancy where serial paths with multiple elements have single points of failure. If you have three identical temperature sensors in parallel, it is like having a path with three in parallel in series with common cause failure. Using different types of sensors greatly reduces this common cause failure to provide much lower probabilities of failure on demand (PFD_AVG).

Mike discussed the case of a packed-bed reactor. These may be instrumented with ten or more temperature sensors to provide a temperature profile. The safety trip will be based on an abnormal profile. With advanced logic solvers, it is possible to perform the calculations necessary to reduce several measurements to profile parameters that can be used to trip a safety instrumented function (SIF). The profile is 1oo1 voting, but a rule might be that 8 out of 10 temperature sensors must be working to be considered a valid profile, so the PFD_AVG is based on 8oo10 fault tolerance.

A separate issue to consider from a safety mitigation standpoint is multiple sensors for localized problems, like hot spots or leaks. Considering packed bed reactor hot spots, it sounds right to say we do not want to trip the reactor based on a single temperature sensor fault. Although this may sound right, Mike explored the math behind determining the PFD_AVG. The example here is for an array of sensors installed to detect a hot spot within the packed bed, but it could just as easily be an array of analyzers around the outside of a piece of equipment installed to detect a leak of flammable or toxic gases.

He discussed the concept of the temperature sensors located next to the failed one. The sensors are primary for their respective zones and secondary for their neighboring zones. The key is to set up a separate safety instrumented function for each zone, which contains the primary sensor and the neighboring secondary sensors. This allow the reactor not be treated as a single SIF where any one sensor failure can trip it.

The math works out that no matter how many transmitters, and surrounding zones, the PFD_AVG calculations are based on primary and one secondary, even in the case of multiple secondary zones. The voting is one out the number of surrounding zones plus the one primary zone, and the PFD_AVG is always based on 1oo2 fault tolerance. No credit is taken for any of the additional secondary sensors in the PFD_AVG calculations.

Mike summarizes these concepts by saying the number of sensors required for a SIF can be optimized to achieve the necessary coverage and the required redundancy. Using more than three sensors for redundancy does not really help. It may be necessary for coverage based on the geometry of the vessel, but not for increased redundancy.

The ever-increasing global demand for energy requires tremendous daily global movements of crude and refined products. Offsite operations play a vital role in the hydrocarbon supply chain. These offsite operations provide the receiving, shipping and storage facilities for handling bulk liquid or gas products. These sites typically include tank farms, blenders and terminals for handling truck, rail, and marine transport.

Tank farms and terminals are found at various stages along the production process from oil & gas collection terminals to refinery terminals and depots, to primary depots where refined products are loaded and transported to your local gas station.

I caught up with Patrick Truesdale, a senior consultant, in Emerson's advanced automation services team. Patrick will be co-presenting with Emerson's Gerrie Benjert at the upcoming Emerson Exchange. Their topic is developing a business case for tank farm and terminal automation.

The biggest business challenge Patrick finds from his work with offsite operators is the lack of spare capacity throughout the global distribution system. Capacity utilization is at a maximum and assets in many of the established markets like North America and Western Europe are aging. This increases the chances for unplanned shutdowns. These facilities often lack flexibility to deal with changes in market demand.

Other challenges include increasing safety and environmental requirements and increasing compliance reporting. In addition, new regulatory mandates for ultra low sulphur fuels, biofuels and other additives increase the number of products to manage through the distribution chain.

Overcoming these challenges is the basis for the business case that Patrick helps offsite operators build. If the case for improvement justifies capital investment, an important step will be reviewing the key components in an offsite automation system. These components include automatic tank gauging and inventory management, goods movement automation and control, blend control and optimization, and terminal management systems.

The more these components are integrated, the better the efficiency of the offsite operations can be. Automated data collection, correlation, and reporting help streamline the regulatory reporting challenge and provide a better data to make process improvements. In addition, custody transfer of the liquids and gas can be more accurately measured, accounted, and billed.

In his presentation, Patrick and Gerrie will discuss some of the quantified benefits that some offsite operations have been able to achieve. It is important to establish a continuous improvement loop to collect data before and after these offsite automation system components are added or modernized. This is so the data can be analyzed and used to generate additional projects to further integrate and streamline operations, based upon quantified results.

Recently the DeltaV News RSS feed announced a video case study for Australia's Arrow Energy at their Tipton Gas plant.

I discovered that Bob Gale, an AIChE fellow and Sr. Technical/Safety Consultant in Emerson's Refining and Chemical industry center was involved in this project. You may recall Bob from an earlier post about achieving IEC 61511 compliance.

Like more and more projects, a global team from Emerson was assembled to execute this project. Bob's role was to do the safety integrity level (SIL) verifications for the project. Bob noted that a part of the IEC 61511 Safety Life Cycle for DeltaV SIS projects is to have an Emerson Certified SIS Consultant verify that the safety instrumented functions (SIF), as they were designed, meet the safety integrity level that is specified in the project.

Bob's task was to ensure them that each SIF provided the risk reduction that was required to make things safe. One example he described was determining that this plant needed to divide one large SIF that encompassed the fire detection equipment on all the compressors into a single SIF for each compressor. This change allowed each of the smaller SIFs to provide the necessary risk reduction required. Each SIF is designed to shutdown the compressor in the event of a fire.

By working methodically through all of process equipment that required risk reduction, Bob played a key role for the project team in the plant's IEC 61511 safety lifecycle efforts.

Standards play an important role in fostering technological progress--both in the willingness of consumers to adopt the technologies and suppliers in developing products to meet the standards.

In our world of process automation, standards have continued to advance from base-level digital communications protocols to higher-level data communications standards for process manufacturers. The ISA-95 (S95) or IEC/ISO 62264 family of standards as they are globally known are an example of a set of data standards for the interface between enterprise planning systems and automation systems.

I had a chance to get a preview of a whitepaper that Emerson's Shenling Yang is developing around S95 and the XML-based implementation of this standard called Business To Manufacturing Markup Language (B2MML). You may recall Shenling from an earlier post on project timelines. She is now a data integration specialist in the Life Sciences industry center.

As stated in an ISA press release this past January on B2MML improvements:

B2MML was developed by the WBF's XML Working Group to provide manufacturing companies with a freely available XML Schema implementation of the ISA-95 Enterprise - Control System Integration Standard.

You can get a sense for just how detailed and comprehensive these standards are by viewing some of the schema documents available on the World Batch Forum's B2MML web page. Beyond the common schema organized around the S95 data model, other schemas exist for equipment, extensions, maintenance, materials, personnel, process segments, product definitions, production capabilities, production performance, and production schedules. Warning, these schema documents are not light reading!

On projects requiring workflow improvements and/or paperless operations, Shenling and the team follow B2MML data definitions to be consistent with the S95 standard. Because leading enterprise resource planning (ERP) systems like SAP support B2MML, Shenling finds that it simplifies connectivity and reduces the overall engineering effort for integration between the ERP and manufacturing execution systems like Compliance Suite. Ongoing maintenance is also reduced since the information exchanged between applications follows well-defined data definitions.

An example is an order coming down from SAP in an XML-formatted document complying with the B2MML Production Performance schema. The project team used transaction templates, along with the Compliance Suite support component and the process order XML from SAP to generate the actual transaction documents to be passed from the ERP to Compliance Suite. The automated parts are handled by the DeltaV Batch system and other parts of the process like materials management, laboratory information, and proof of personnel training are sent to their respective workflow processes.

The results of these workflows and batch data from the automation system are consolidated in an electronic batch record, which is a critical piece in reducing the overall cycle time on the way to releasing the product for sale.

Update: Gary Mintchell reports on his Feed Forward blog today that the World Batch Forum has announced version 4 of the B2MML standard and some of the additions to this standard. Here's the announcement from the WBF.

One of the challenges in converting the Northern Alberta oil sands into usable energy is the tremendous amounts of natural gas consumed in the process. The supply and cost of this resource is a major cost factor for Oil Sands producers.

OPTI Canada and Nexen are the first to introduce large-scale gasification into the bitumen upgrading process in the Long Lake project. This process uses the Shell Gasification Process (SGP) processes which takes the liquid asphaltenes from OPTI's OrCrude process and produces hydrogen for the distillate hydrocracking process, synthetic gas for the bitumen recovery process and fuel for power and steam generation.

The economic benefit of this process is well described in a 2004 paper, Gasification in the Canadian Oil Sands: The Long Lake Integrated Upgrading Project:

The energy balance of the project... demonstrates the elimination of virtually all of the natural gas cost exposure, which results in an operating cost advantage of about 50% over currently-configured operations.

Stephen Krause, a specialist in Emerson's Hydrocarbon and Energy Industry center based in Calgary is involved in the project engineering on this large, complex first-of-its-kind project. Much like processes found in other industries like refining, Stephen told me that gasification is an extremely complex process that requires extensive safety design to mitigate risks. I highlighted some of these safety design challenges in an earlier post. Some of the goals with respect to safety, automation and modular aspects of this project are described here.

Other Oil Sands producers are watching this project unfold as they consider including gasification as part of their upgrader project. And, the experience gained by Stephen and the Emerson project team will greatly help these producers as the future projects unfold.

Recently, a press release announced Emerson's selection on a $2.6 billion (USD) oil sands project in Northern Alberta, Canada.

The project team includes Emerson's Hydrocarbon and Energy Industry Center and Emerson's local business partner, Spartan Controls, both based in Calgary. Spartan Controls also has an office closer to the oil sands region in Edmonton. This team will supply engineering and project management, automation commissioning, and ongoing support services. Over the past several years, they have had experience with several other oil sands projects.

These Canadian oil sands (a.k.a. tar sands) hold known oil reserves second only to Saudi Arabia. Unlike those reserves, it is quite a bit more difficult to process bitumen, a molasses-like viscous oil into feedstocks for refineries to turn into gasoline, diesel and other sources of usable energy. With this project and many others, total Canadian oil production is projected to double from 2.5 million barrels per day (MBPD) to 4.9 MBPD by 2020

The process revolves around an upgrader, which changes the bitumen into synthetic crude oil. The Oil Sands Discover Centre describes the process well in this Upgrading Fact Sheet. It opens with this nice summary:

Upgrading is the process that changes bitumen into synthetic crude oil. Bitumen, like crude oil, is a very complex mixture of chemicals (a hydrocarbon with chains in excess of 2,000 molecules). It also has a lot of carbon in relation to hydrogen. Some upgrading processes remove carbon, while others add hydrogen or change molecular structures. Upgrading also involves sorting bitumen into its component parts and then using them to produce a range of additional products and byproducts.

The large oil sands projects require quite a team effort among the energy companies, Engineering, Procurement and Construction (EPC) contractors, automation suppliers and their local sales and service organizations to execute these large projects as efficiently as possible. And, in the words the energy company's president a "consistent and durable process" is the goal once the upgrader process is in full operation. This is especially important in the cold, harsh winter climate of Northern Alberta. For this project, the upgrader has a total processing capability of 231,000 BPD and construction expected to begin after regulatory approval this fall.

With higher crude oil prices, more projects like these become economically viable to do, to help the supply catch up with the global demand.

There is plenty of work to be done and many career opportunities in Calgary, Alberta if you want to join in all this fun!

For complex processes like gasification units in the Oil Sands region of Northern Alberta, Canada, how do you handle the integration of complex sequences which involve both the safety instrumented system (SIS) and control system (BPCS--basic process control system in safety-speak)?

This was the subject of a recent paper given by Dean Taggart, a professional engineer and certified functional safety expert (CFSE) in Emerson's Calgary-based Hydrocarbon and Energy Industry Center. Dean gave this paper along with members from Spartan Controls and the oil and gas producer, OPTI Canada.

The team gave the paper, Integration of Complex Sequences using DeltaV (presentation), at the 2007 AIChE Spring National meeting. Dean and the team quite comprehensively covered the areas of process and safety requirements and their technical concerns, and applying an implementation framework to this project.

With this post, I'll zero in on the decisions of what should be within the span of the SIS and BPCS. As the team states, it's clear what initially goes into the SIS:

Normally the process is designed in a Front End Engineering Design (FEED) phase, where vessels, pumps, piping, and instrumentation are proposed. The process goes through a HAZOP process, with the intent of identifying hazards. As these are considered, either through a PHA, LOPA, or Risk Analysis, SIL targets are determined and requirements for SIS are established [hyperlinks added to help with acronyms].

For complex processes, the SIS may be involved in the startup or stopping sequences, like in the burner management system on a gasification reactor. Normally the process of burner management involves closing off the feeds and the burner goes off. But for a gasification reactor, under high pressure and temperature, the vessel must evacuate the asphaltene quickly or it will harden and plug up the feed lines. A shutdown sequence is required to depressurize and cool down in a non-damaging way.

The choice the project team faced was either to perform all of the startup and shutdown sequences in the SIS or split them between the SIS and BPCS. The issue with splitting the sequence is increased configuration complexity, data mapping, communications diagnostics and handshaking logic required. And some common methods for this communication like MODBUS/serial communications and OPC, the communications throughput has to be carefully designed and tested. A bigger concerned stated in the paper:

In order to work properly, the BPCS and SIS would have to have "parallel" sequences which would need to be synchronized very tightly with each other. In the event that communications was lost during a startup or shutdown, each would have to execute separate and parallel actions. Since the actions may need to be modified based on process conditions, this adds even more complexity.

For this project, the team used the DeltaV system and DeltaV SIS and ran the sequence in the DeltaV SIS. The paper describes a simpler approach:

Under normal circumstances, the SIS runs the sequence, can override the BPCS when required, and can examine the health of the BPCS. The BPCS only performs process control, listens to the SIS for overrides, and can examine the health of the SIS. If communications is lost, the SIS can take the appropriate action (perhaps abort a startup, execute a shutdown, or may do nothing at all if in normal operation). In this case, the BPCS may continue to execute process control on some loops, and for others they may automatically be set to override or manual mode. The flexibility is there, and there is little concern over loss of communication.

If you have a project with hazardous areas with control system and SIS requirements, this paper is an excellent resource for an approach to think through the design process.

People from across the world come up this blog and get some great questions from time to time. The most recent example is questions about safety instrumented systems (SIS) and the IEC 61511 standards. I thought I'd run them by two experienced Emerson safety experts, Len Laskowski in the Refining and Chemical industry center and Stephane Boily in the Hydrocarbon and Energy industry center.

As safety professionals incorporate these performance-based international safety standards, I thought sharing their answers with you might help your safety planning efforts. Len answers the four questions and Stephane adds his thoughts looking at the SIS installation components.

What are the standards that define the best rules for installation of field equipment of a SIF/SIS, on site?

IEC 61511 or ISA-S84-2003 (which is really the same thing, plus a grandfather clause) are intended for application in the process industry. They do the best job of defining what one needs to be concerned with for field instruments. The guidance may be considered somewhat minimal but the critical safety issues are there. Whatever would make a good installation for the basic process control system (BPCS) is a good installation for the SIS also. However, some different issues need to be recognized. First, the instruments need to be reliable. One measurement, referred to as "proven in use" means reliability data must be available for safety integrity level (SIL) calculations. If not then SIL-rated instruments are an option. Next one must consider fault tolerance requirements for the Safety Instrumented Function (SIF). This is a function of the SIL level for each SIF in the SIS. There will of course always be the need to make sure the instruments are calibrated routinely and tested per the proof test requirement. If this is online then the engineer needs to make sure that those facilities plus the ability to do maintenance is designed into the project. Typically sensors need their own root valve and final control elements may need bypasses or means for partial stroke testing.

The routing of the individual cables of transmitter that is in a 2oo3 voting system--the same route, different routes?

Some reliability engineers would want to try to convince you that a different route is required. While everyone would like a diverse routing from a common mode point of view, (a fire, dropped crane load, chemical spill could destroy all the cables in the same tray, etc.) it is many times impractical to route differently. One deciding factor is availability. If high availability is require diverse routine is a good idea, but again not mandatory. Some companies may have internal standards on this subject. The other factor is whether or not the SIS fails safe. If a loss of a cable, causes the System to have a spurious safe trip the system is safe, but you have to deal with the cost of the spurious trip. If the SIF is energized-to-trip, one needs to look at separate routing. Also, end of line monitoring etc.

Can I install the three field devices in battery or in different places to avoid, common failure, e.g., vibration, risk of fire?

Field instruments are designed for the outdoor industrial environment. Utilize them correctly for their application. If it is a bad installation for the BPCS it is bad for the SIS also. While many SIS logic solvers have been industrially hardened to operate in a broad range of environmental conditions with numerous successful applications, it just stands to reason that putting them in environmentally controlled areas will improve potential reliability plus the ability to do maintenance.

Yes one must always be careful with respect to common mode. Common mode can wiped out the reliability gains of redundancy. That is why it is required to do SIL Calculations to verify that the common mode effect is not so strong that it renders the SIF ineffective.

Must I use the normal practices of engineering or do rules or recommendation exist for the installation of field equipment for the SIF/SIS?

One has to ask whose normal practices?? If we mean industry best normal practices the answer is yes again but one needs to follow the entire IEC-61511 Life Cycle to determine what that really means for each project. What is an acceptable solution for one plant may not work for another. The questions you ask really points out that to safely design a plant, the project needs to execute the IEC61511 Safety Life Cycle. Hazards are identified early in the project and solutions are designed around those hazards. The questions you asked should all be covered in the Safety Requirements Specification (SRS). There are 27 questions that cover the topics you have asked and more, much more. Inexperienced engineers may not be aware of this list of questions that define an IEC61511 SRS. This is why you should work with experienced organizations. A study done by the Health and Safety Executive in the UK has shown that the majority of problems with SIS systems today are actually specified into the project. (Or shall we say not specified into the project, one does not know what one does not know.) Failure to execute the life cycle activities early and properly can have serious safety, schedule and cost implications on a project.

Stephane adds these thoughts on the installation components:

Sensor-To reduce common mode each sensor should have a separate process connection. There have been some good arguments made with regards to using different technologies in order to reduce common mode but one must look at practicality vs. benefits and risk reduction. Also, although the use of diverse technologies can reduce common cause it will not eliminate it completely.

Transmitters-For sensors integrated (or separate) with the transmitter, the geographical locations of the voted transmitters should be away from each other to the extent possible (so that in the event of a fire--all transmitters are not affected--as an example!)

Junction Boxes-Separate JBs for each transmitter / 2 core cable is preferred.

Multicore Cables-If separate JBs not possible, run each transmitter pair in separate multicore cables to the control room.

Cable Trays-Run the multicore cables in separate trays which have separate routes to the control room when practical. Availability would be the determining factor.

Safety Logic Solver-Each transmitter signal could be connected to separate SLS, on separate carriers. This would slightly compromise on the PFD value however and could also make the SIF configuration more complicated, but reduces common cause. SLS installed in two different cabinets in different control rooms would be even better! However common sense needs to be used and practicality. Same logic could be used for the output signals.

The extent to which one would go in segregating will depend on ALARP - As low as reasonably practicable (here 'low' refers to the risks involved). The Risk Reduction Factor (RRF) of the SIF and how much of the risk is the engineer / company ready to absorb, will dictate the decision. The common cause calculator (based on such segregation) is given in IEC 61508-6, Table D.5.

At the recent Interphex Pharmaceutical Manufacturing Conference, Emerson's Todd Ham presented on the subject of automating fermentation. Todd acknowledged that Christie Deitz, whom we've featured in several other posts, had a large hand in the development of this presentation and work on the project discussed.

The presentation discussed a recent project done on a large-scale, multi-product biopharmaceutical complex. This project was so successful it recently won the Facility of the Year Award Winner in Project Execution. One of the keys to success was a clear design philosophy established up front. Elements of this philosophy included:

• Fully automated
• Paperless, dock-to-dock using electronic records, operator handheld devices, and barcode scanning
• Consistency for operators based on industry standards like ISA-88 (S88), ISA-95 (S95), and digital bus technologies
• Focus on fermentation as a key process area for the project

A key to success in the project was the close working relationship between the manufacturer and the Emerson Life Sciences project team on the up front requirements and design, and the subsequent module-level and integration-level testing.

The upfront design considered not only the fermentation and recovery processes, but also the full automation required for paperless operations. This design included recipe-level batch control, warehouse management, electronic signatures, and a complete electronic batch record, including the manual processes. These manufacturing processes included material management, container management, filter management and sampling.

The project team applied the S88 standard to control modules looking to identify the common modules and instances for things like motors and valves. At the S88 equipment module level, the team created project wide module templates, area specific module templates, and unique, one-time use equipment modules.

The sampling system and sparger control are examples of project-wide templates. Fermentation agitator control and dissolved oxygen control are examples of area-specific equipment modules. Transfer panels and valve assemblies are examples of unique equipment modules.

At the S88 unit level, the team designed classes and instances based on physical similarity and phases that they use such as batch media, inoculate, ferment, etc. This led to various unit classes for fermentation vessels including seed fermenters, production fermenters, and feed vessels.

From a recipe standpoint, the design grouped phases into operations, then grouped operations into unit procedures, and finally grouped unit procedures into procedures, all again following the S88 standard.

Todd shared some lessons learned from the team. With regard to the modular design approach, the team learned to keep process units the same as much as possible. With similar units, it is also important to make sure the operations are also as uniform as possible. The team cautioned about the overuse of aliases, which reference pieces of physical equipment like valves and motors, in phase logic. By not overusing aliases, but rather relying on equipment modules to handle physical differences, the phase logic could be generically written to handle multiple pieces of similar equipment like process tanks.

Other lessons learned were to plan for the extra documentation required for high levels of modularity and dock-to-dock automation. Like other members of the Life Sciences team have counseled in earlier posts, time spent upfront in planning and testing saves a lot of project backend effort.

The benefits of a complete electronic batch record vs. a paper-based process in terms of faster release of products are pretty clear. It's important to assemble the project team and begin the planning and design early to prepare for the additional effort commensurate with the increased automation required for a successful project.

Do you ever feel that pressure when things just aren't right? Things like increasing production costs, growing raw material and/or finished product inventories, inconsistent quality and inflexible production to meet changing customer needs. According to John Dolenc, a principal consulting engineer for Emerson's Advanced Applied Technology team, these are potential business drivers to consider modernizing your process automation.

Other potential drivers include unreliable operations caused by false trips and excessive plant alarms, poor-to-nonexistent production data, time wasting manual data entry and checking, and time consuming regulatory compliance and documentation. Each of these drivers has a cost associated with it that can be used to develop a business case for improvement.

John helps process manufacturers understand and quantify these opportunities for improvement in Process Automation Feasibility studies. The study begins with gathering the background information found in process flow diagrams, P&IDs, operating procedures, operator log sheets, plant history data, production costs and trends, quality reports, and current control strategies.

Usually a team forms with members from plant management, plant engineering, operations, maintenance, quality assurance, and even corporate engineering and management depending on the level of potential improvement. John and other advanced applied technology consultants bring expertise in production processes, plant operations, and the impact control strategies have on the process to help develop an improvement plan. They are experienced in providing a methodology based on past experiences and bring an outside perspective to facilitate discussion and have the freedom to challenge the rational behind past practices to get at the underlying issues.

The methodology examines the process unit performance first from a financial perspective. Key performance indicators (KPIs) are identified and the performance versus these KPIs is analyzed. Base line performance is established, potential improvements are identified, and financial gains are calculated. An automation plan to achieve the financial benefits is developed based on examining the production process; looking at process constraints, process disturbances, and limitations in equipment or other areas of the operation.

The cost to implement the automation plan is estimated and a financial analysis is done to determine if the projected benefits justify an automation project. For smaller units this process can take four weeks to perform the feasibility study, while larger units or plant-wide studies may take several months.

The real fun happens when projects get funded and quantified improvements get made. It goes a long way to relieve that pressure!

Todd Ham and Dan Lorenzo from Emerson's Life Sciences Industry center presented a workshop entitled, Large Project Execution. The focus is on sharing best practices for successfully executing large projects.

They define a large project as 10 or more engineers with more that 5000 engineering hours. The project schedule is typically measured in years and tends to have high visibility with upper management.

Far and away the most important aspect to success is the team leadership. Team leaders should possess technical expertise, managerial competence, and the ability to attend to problems early. Many different styles of leader can be successful, but setting upfront expectations is critical. Dan cites a balanced leader that is knowledgeable, but non ego driven, is willing to make and stand behind tough decisions, knows when to defer to the team, and provides an environment for the team to explore new ideas. This leadership style gives the project its best chance of success.

The next important step is to create a common message to breakdown the project complexities, to provide a clear, cross-functional set of objectives, and to help everyone understand their roles in achieving these objectives. Todd made it clear this is not "rah-rah" motivational sayings on wall posters, but rather a clear vision such as a world-class biotech facility.

The makeup of the team is very important. Most teams have a mix of experience and inexperience and personalities. It's important the leadership be engaged, reinforce the common message and direction, and deal with people issues head-on and early. Build a team with a balance of skills and personality.

Project indicators that things are going well include new ideas being suggested, measured progress being made, and people on the project generally seem happy. On the flip side, indicators that things are not going well include people acting differently in the presence of team leadership, the leadership being unaware of major issues, and people hoarding information and knowledge. It boils down to reinforcing practices that are yielding good results.

Finally measure and monitor what makes sense for the project. Items that are measured will get better. Too many metrics can do more harm than good and not move the project forward toward the intended objectives.

Here at the Emerson Exchange we're now into the workshops where process automation professionals, Emerson technologists, and Emerson industry, project, and application professionals share some of their experiences.

Dave Horan, has 17 years with Emerson's Rosemount division. Dave works with many of the engineering contractors on large projects on their instrumentation requirement. His presentation is on a shallow-water offshore project off the coast of Venezuela.

The project had a floating storage offloading, central processing facility and wellhead platform. The central process facility (CPF) basically cleans up and separates the produced fluids from the wellhead platform. Produced water and some gas is re-injected to the reservoir to help keep the production flowing.

The largest problem in this project was 40 skids coming from 23 vendors located on 2 continents. The number of possible permutation in types of instruments is huge given so many skid suppliers. This would create a real training and maintenance headache to support these once the CPF was started up. The challenge was to manage the skid vendors to standardize on a set of instrumentation to reduce the permutations.

For the Rosemount transmitters, up front planning was done with the oil producer's engineering team to pre-select appropriate instruments that could be used by all the skid vendors. For this project, all skid vendors had the same project manager in Emerson's Rosemount organization, to specify and purchase the transmitters. Standardization was enforced for model numbers, materials, mounting brackets, and local indicators to name a few instrument selection parameters.

The project management group provides project managers, engineers, project documentation, quotations, data entry, logistics and other functions/deliverables required to achieve the project milestones.

The goal to reduce the variations of instrumentation was achieved meeting the project objectives of an on-time project and minimizing training and ongoing maintenance.

Anyone who has been a project engineer knows that there are some areas of a project with more inherent risk to schedule and cost more than others. Areas like data integration between hardware, software and systems need early attention so that they can be resolved before the pressures of the critical path are felt.

One of the Emerson Exchange papers being presented in the Project Work Processes track is Data Flow Requirements for Main Automation Contractor (MAC) projects. Emerson's Mike Simpson and Jim Davis from our West Coast Business Partner, Caltrol, convey processes, procedures, and tools for the information formats, milestones, sequences, and timing for smoother project execution.

Mike notes that many of the decisions for standards and responsibilities are made during Front End Engineering Design (FEED) phase. These have major impact on the data exchange processes during project execution. Their recommendation is to set the communications rules during this phase of the project and confirm all the data sources and predecessors.

The key is to designate a single coordinator for all data exchange. This person establishes the data exchange standards including: data types, formats, media, due date, supplied by, supplied to, risks. A database application with milestone alerts can help to issue project controls for completion and near term due exchange alerts and all long term milestones.

When on a project with a new process or process technologies, Mike and Jim recommend testing to avoid surprises. Split this work into two phases with the first phase, a thin slice phase and the latter, the main phase. The thin slice phase lets you test new hardware, control strategies, and/or communications to discover surprises. This testing helps avoid committing your entire project to the new technology and avoid assumed methods of engineering and implementation without assessing how it will work.

Mike and Jim show examples of how this applies in integrating process units and process skids using serial and digital bus-based communications and taking advantage of software tools like Intergraph's SmartPlant Instrumentation to manage this project data flow.

Mike notes that it really boils down to early involvement in the FEED phase of these MAC projects where it is critical to plan these well-executed data hand-offs.

Process manufacturers need better flows of information to make timely decisions to efficiently run their businesses. The ANSI/ISA-95 Manufacturing Enterprise Systems standard, commonly referred to as S95, is the international standard for the integration of enterprise and automation systems. This global standard consists of models and terminology for the exchange of information between systems for sales, finance and logistics and systems for production, maintenance and quality.

One key area of information flow is reading laboratory analysis results from the laboratory information management systems (LIMS) and coordinating this information with the running batch controlled between the batch automation system and the manufacturing execution system (MES). The MES normally maintains the complete electronic batch record of all automated and manual processes, including LIMS data.

I spoke with Steve Thorp, an Integration Consultant in our Life Sciences industry organization. He is currently working with a batch process manufacturer who is implementing extensive elements of the S95 model, including comprehensive LIMS integration. Some of the key objectives for this project included:

• Providing the MES system (Compliance Suite for this project) the ability to request the creation of new samples within the LIMS system based on the current status of the MES Electronic Work Instructions. The MES system would also read information from the process control system to determine when and what samples would be created.
• Providing the MES system the ability to monitor the status of specific samples within the LIMS system
• Providing the MES system the ability to read the analysis results for specific samples within the LIMS system after the samples status has been set to "completed"

Steve talked about the alternative of doing this process manually, the number of people who can be involved, and the delays this manual process can cause to the release of the batch. By analyzing this processes and architecting a solution to automate the manual pieces, big efficiencies can be gained.

For implementing this portion of the S95 model Steve offered the following guidance to process manufacturers. First, fully understand the current workflow including how and when the physical samples are taken, when the results are required, how these should be included into the electronic batch record, and what failure contingencies should be made in the MES and automation system if the results are not ready when expected. Second, when implementing the design, it critical to understand the underlying data structure within the LIMS system, and to understand the overall usage patterns to properly estimate server and storage requirement for the hardware design.

Given competitive pressures, process manufacturers put great pressure on project teams to bring projects on-time, on-budget to capture revenue and payback the outlay of capital sooner.

Engineering efficiency is one of the keys to success. This efficiency is measured in output per cost and in the ability to shrink task timelines on the project plan.

I spoke with lead engineer Brian Crandall in our Life Sciences industry organization to gain insight on what areas can help drive engineering efficiency. You may remember Brian from an earlier post.

Brian boiled it down to three areas: design & implementation standards, project execution methodology, and project design tools. I've addressed standards and projection execution methodology based on the S88 model in earlier posts so we've focused this post on project design tools.

Tools can help eliminate the repetitive and low-value tasks. They can also reduce risk and improve quality by eliminating errors associated with manual tasks.

Brian likes to think about these tools in distinct stages of the project. In the detailed design phase, documentation tools automate the system configuration work to come later. As an example, the Life Science project teams use DeltaV Control Studio as a design interface to generate textual and graphical description of how code should be implemented. This generates Visio diagrams for process visualization and Word documents to help detail further actions required. Documentation tools can also provide easily-readable summaries of the automation system configuration for use in project reviews, and in the case of non-GMP projects, provide the final documentation deliverables.

Coding tools are those that help in the implementation phase of the project. The project teams' see engineering efficiency gains in both batch and continuous elements of the project implementation including: units, phases, composite modules, recipes, equipment module sequence logic, module database elements, and I/O database elements. Using XML and SQL data standards helps move information between the external databases and the automation system configuration database. Tools like DeltaV Bulk Edit and other ones created by the Emerson project teams have increased efficiency during this implementation phase.

During the test phase of the project, execution tools can help the testers rapidly access and manipulate large amounts of parameter values to verify that proper the actual control matches the design. Excel spreadsheet templates connected to the system with an OPC-based Excel Add-in provide the ability to read and write large amounts of data and capture this data for historical viewing and analysis.

A final point Brian made is that these same tools can extend engineering efficiency beyond project commissioning. The combination of standards, methodology, and tools make ongoing changes and testing more streamlined and reduce the overall maintenance costs over the life of the plant operations.

Congratulations to Praxair's Geismer, Louisiana methane reforming production facility for winning Chemical Processing magazine's Plant Innovation Award.

Praxair's innovations were the result of their objectives to reduce energy (natural gas) usage while meeting the production demands for CO, H2 and steam much of which is exported to customers' neighboring plants. The Geismar facility is comprised of four steam reformer plants of different age. The key challenge was to allocate load based on current plant performance and product slate.

I spoke with Chris Hawkins, a Senior Consultant and Technology Manager in Emerson's Asset Optimization organization. The AO team worked with Praxair to design advanced site optimization using the AMS Optimizer to calculate values for key process variables in real-time to increase the energy efficiency and consistency of each of the individual units. This work was combined with some model predictive control strategies implemented by the Praxair project team.

Working with the Praxair team, AO team members developed detailed models in the AMS Optimizer for each of the operational components of the site. The models compare the current plant operation and customer demands to determine the most economic set of production setpoints across the multiple units. These setpoints are automatically sent to the lower level control systems to keep the process running at optimal efficiency.

Chemical Process magazine reported the following results from the project:

Individually, the MPC systems increased in the carbon monoxide recovery on the cold boxes an average of 5-8% across multiple units, and much more consistently running of the units during production changes and load disturbances. Full implementation of this approach cut energy usage by over 1.0% for the facility. While that may not seem like a large percentage, for a site of this size, such a reduction equates to several hundreds of thousands of dollars a year in savings and provided a project pay back on the order of 2 years.

Batch process manufacturers have long understood that applications which require both sequential and continuous control have been a challenge. A typical example is a centrifuge application commonly found in Biotech and Pharmaceutical manufacturing processes. A centrifuge separates solid and liquid material by spinning a sieve-like device at high rate of speed, and recovering the liquid, solid or both materials.

I caught up with Brian Crandall, a Life Sciences industry project engineer. He said that proper control was critical since centrifuges are quite expensive, and sensitive to a variety of failure conditions. These conditions need to be addressed within seconds to prevent equipment damage and possible injury to operations staff.

Brian summed up the control challenge as the centrifuge having various operational states. Moving between these states is best done using sequential operations. However, monitoring of the failure conditions, which change in severity and action depending upon the operational state, must be done in parallel with the sequencing.

If a failure condition occurs, the current sequence has to be stopped, and the specific failure sequence started within a minimum timeframe. The S88 Batch Model defines a sequential state driven approach, but it does not fit the requirements of this application. The big issue is the failure monitor does not offer continuous monitoring required for quick reaction to the failure condition.

Using a DeltaV system for this particular Biotech application, Brian designed, tested and implemented a modified S88 state model that had the ability to stop a sequence without waiting for a transition thus meeting the high-speed timing requirements of the equipment. Multiple sequences would be required for the main sequence, shutdown, and E-Stop to allow stopping one sequence and starting another at the same time. Also the code design needed to modular to fit the rest of the S88 modular design philosophy. Also, this design placed control at correct level in S88 batch model, at the equipment module level.

Some failure conditions the design addressed included: high vibration, VSD fault, low seal water pressure, and low instrument air pressure. Depending on the state of operation, the failure conditions required different actions per a failure condition matrix.

Other industries have applications requiring this mix of continuous and sequential control. Some examples include a refiner in the pulp and paper industry, extruders in the specialty chemicals industry, and other state-driven processes or equipment.

S88, short for ANSI/ISA-88 is a standard for addressing batch process control. This design philosophy for software, equipment and procedures provides a consistent set of standards and terminology for a batch automation project.

I spoke with Christie Deitz who coauthored a paper entitled, Writing a Functional Specification for an S88 Batch Project.

Christie believes that S88 provides many benefits for the project team and project stakeholders. It starts with establishing common structure and terminology for clear communications between the automation, quality control, manufacturing, and the management teams. The nature of the modular standard facilitates object-oriented, class-based designs. This helps minimize documentation by defining requirements only once for the entire class. It also helps improve the consistency of the design. By streamlining many instances into one class it means that design, implementation and testing efforts are reduced which help the project stay on schedule.

She stresses that the key is to use S88 early during the requirements definition. According to GAMP (Good Automation Manufacturing Practice), the functional specification defines the process automation requirements and becomes the basis for the design specifications. The functional specification may include a process description, piping and instrumentation diagrams (P&IDs), process flow diagrams (PFDs), and an instrument list.

Christie encourages process manufacturers to make sure automation or other S88 knowledgeable people are involved early in the process design to make sure the advantages of a modular approach are built into the project. It's also a good idea to include stakeholders from automation, process engineering, production and quality into the creation of the functional specification. This front end work will minimize changes due to misunderstandings by the project stakeholders. These changes become more expensive the later they occur in the project schedule and can delay the startup date.

Process manufacturers have many choices in how to organize the specifications. Christie's experience is that functional specifications should be created for each area, which allows classes to be described within a single document. There are typically five to ten process areas within a process. This allows for a limited number of documents to manage.

By taking this approach Christie and the experts in our Life Sciences organization have helped deliver projects ahead of schedule, which means faster payback on the project.

Every capital project has it challenges, usually around tight budgets and tight schedules, not to mention team flexibility and changes in scope.

Recently at the Interphex conference, the big industry gathering for Life Science manufacturers and suppliers, Emerson's Michalle Adkins, Steve Murray, and Dawn Marruchella presented a paper entitled, "Optimizing Your Automation Investment By Mitigating Risk."

I had a chance to catch up with Steve who is a consultant and project lead engineer in the Life Sciences industry organization to understand what experience they shared with those who attended their presentation.

Steve shared five strategies for helping to reduce risk in projects. These include:

1. Set Expectations
2. Prototype
3. Establish Project Guidelines
4. Use Global Standards
5. Leverage Testing

Set Expectations. Risks in miscommunication, budget, schedule, and overall project execution can be reduced by having the project team (both manufacturer and supplier(s)) align on the expectations for the project. The expectations include the deliverables, documentation, schedule, procedures and processes, tracking metrics, and the overall level of automation and integration between systems and processes. This helps aim everyone's efforts in the same direction and discovers efficiencies which can be gained as the project is implemented.

Prototype. Risks in budget, schedule, changes, and project execution can be reduced with a prototyping strategy. Prototyping helps incorporate operational philosophies into the upfront engineering, helps ensure consistent look and feel, and provides a visual medium to communicate designs to the project team, manufacturing, maintenance, and other interested parties. The prototype lays the foundation for the project guidelines and demonstrates methods for software testing, operator training, and process simulation. This strategy can reduce changes later in the project. There is much more to say on what and how to prototype which I'll save for a future post.

Establish Project Guidelines. Risks in budget, schedule, maintainability, and project execution can be reduced by establishing clear project guidelines. The agreement of established procedures, practices, and fundamental philosophies at the front of a project help avoid project-wide changes later in the project. These guidelines should cover execution methodology, change control, document control, testing and all the team member roles and responsibilities. It covers all aspects of the automation project including operator interface, batch architecture, continuous control, devices and I/O, and integration with external systems.

Use Global Standards. Risks in budget, schedule, maintainability, and training can be reduced by establishing or using already established global standards. Global standards in this context refer to standard, modular, pre-tested pieces of automation like control modules, equipment modules, phases, etc. These standards incorporate existing knowledge and best practices, help facilitate communication between team members, and shorten the learning curve for new members to the project team. Ongoing maintenance and support is easier for the 80-90% of the project configuration that typically can use global standards. These standards are often provided by automation suppliers since they see more projects and can more efficiently iterate towards an ideal standard. In addition, spreading the development costs across a broad project base can significantly reduce these costs.

Leverage Testing. Like using global standards, risks in budget, schedule, maintainability, and training can be reduced by leveraging good testing practices. For highly regulated Life Science manufacturers, everything needs to be tested and documented. The key is that each level of testing (supplier, acceptance, commissioning, IQ, OQ, PQ) should build on the previous layer and not repeat it. Testing is always a risk-based endeavor. There can never be so much as to eliminate every possible problem scenario. At some point the cost can drive a project cost more than anything else. It's better to spread testing cost for standard items as widely as possible, and load most of the testing into the front end of a project since testing gets progressively more expensive the further it is done in a project schedule. The key is a solid test plan which identifies the risk areas from all members of the project team and finding ways to combine some of the testing levels like commissioning and qualification.

Steve and other experienced Life Science Industry experts have shared their wisdom in many papers over the years including S88 batch project specs and S88 project requirements.

A recent post on Control.com's global on-line community for automation professionals asked about how to go from pneumatics to a process automation system in a refinery.

Given the strong global demand for refined products, refineries want to avoid any downtime when modernizing their automation and safety instrumented system technologies. This process of cutting over from old to new while the process is running is called a Hot Cutover.

Ken Suetterlin, a senior Emerson Project Manager from our Refining and Chemical Industry organization responded to the Control.com post with the following recommendations:

1. Identify which loops are to be converted as Hot Cutover and which are to be done during Turnaround. If possible, we recommend you convert loops related to safety shutdowns during Turnaround. The loops in each category can be color coded on P&IDs and/or indicated by category in an instrument database. Then you can sort by Hot Cutover and get a list of all loops in that category.

2. Once you have a list you'll want to work closely with Operations to schedule the loops based on production priorities and loop complexity.

3. Install and test as much as possible in advance to avoid last minute surprises.

Upfront planning is critical to avoid downtime. In a Shell Deer Park refinery modernization project, Emerson supplied all phases of engineering services related to Hot Cutover including conceptual design, FEED (Front End Engineering Design), detail design, FAT (Factory Acceptance Test), field commissioning, SIT (System Integration Test), SAT (Site Acceptance Test), and installation. The team worked closely with installation contractors, and provided the engineers and technicians for actual cutover.

The Hot Cutover process at the Shell Deer Park refinery which included critical units like the Cat Cracker is described in an April Hydrocarbon Processing article.

Here is a description of some of the expertise and technologies Emerson applies in a Hot Cutover project.