Everyone has their war stories of projects that in hindsight are full of ‘we should have done’s and MatrikonOPC is no exception.  We were involved with Lyondell’s recent DCS upgrade at Bayport that had several serious hiccups, including the redundant OPC implementation.   Lyondell details the story in a ‘Lessons Learned’ type presentation that was recapped on the GlobalControl.com Editor’s blog. 

As one of the vendors involved, we have to shoulder the responsibility of not fully meeting the needs of the customer in this case.  I can talk about some of the mitigating circumstances that led to this, but at this stage that is little different than offering excuses.  However as a result of shortcomings on our part, the customer was left with the impression that OPC is a ‘complex and fragile’ technology.  As a committed OPC vendor, we’d be seriously remiss if I didn’t at least attempt to defend the honor of OPC.  

The problems encountered really had nothing to do with OPC, rather they where the result of a combination of classic interfacing problems: improper architecture, products with initial release growing pains, and inexperience with a new system.  Not that this lessens Lyondell’s frustration or inconvenience in any way, but to be fair, the perception that OPC as a technology was at fault is misdirected.

First a bit of background.  The OPC communication setup between the DCS and PLC was a relatively complex architecture, involving redundant connections at the device, server and application layers.  The ‘Matrikon system’ actually refers to three separate pieces;  a pair of Matrikon OPC Servers for Triconex, the OPC redundancy product, and an OPC client application which was communicating with the redundant Experion PKS system via the Honeywell OPC servers.

Let’s start at the bottom.  The Matrikon OPC Server for Triconex is still the recommended way of interfacing third party systems with Triconex devices.  This piece of the OPC architecture always worked as expected, did not require any software revisions and continues to function properly at the site today.  Score one for OPC.  Unfortunately issues occurred higher up the chain.

The original architecture proposed interfacing with the Experion system via their OPC server interface.   This was the preferred and proven method for enabling redundant OPC connections.  This architecture had been successfully implemented in dozens of installations, including connecting to earlier Honeywell systems such as the TPN and TDC3000 incarnations.  

However, lack of extensive knowledge of the new Experion system and the subtleties on how their powerful redundancy scheme behaved led the team to assume this architecture was still the right choice.  We all know what ‘assume’ means.  We’ve since learned that when connecting to redundant Experion PKS systems, using the Honeywell OPC client interface is a better option.  This has less to do with how OPC behaves but rather how the two interfaces react during fail over conditions.  Regrettably, we learned that on the Lyondell project.

Changing the architecture to use the Honeywell OPC client, then led to a choice in which OPC redundancy product to use, the Honeywell Redirection Manager, or the MatrikonOPC product.  The timing of the upgrade was especially unfortunate, as both products were suffering from recent release syndrome, and had the inevitable software issues.  This was compounded by the fact that Matrikon’s Experion-Triconex test bed did not match the configuration, and R210 software upgrades that the site was running.  The development team’s eagerness to solve the problem led to multiple software revisions targeted for a live system.  Any Process Engineer who has been there can attest to the frustration, uncertainty and stress this inflicts.  The resulting negative feelings for OPC are understandable.

From an OPC point of view, the story had a happy ending.  The final architecture of the Experion PKS OPC client, the Redirection Manager and the Matrikon OPC Servers for Triconex is performing well.  I can’t help but add, that since the project was using OPC, they had a choice of products from different vendors, and could make changes relatively quick, without touching the Triconex systems.  Dealing with a custom interface, or a more tightly coupled protocol makes changes like this an even bigger challenge.

Lyondell is not the only one who learned painful lessons from this project.   Since that time both the MatrikonOPC and Honeywell products have improved for the better.  Our Engineers have gained an improved skill set, experience and comfort level with the Experion platform and redundant architecture.  Similar projects have since be successfully implemented, including ones for Shell and Exxon Mobil.   Some use the Honeywell Redirection Manager, some use the Matrikon OPC Redundancy Broker, (such as at Georgia Pacific).  To my mind, this means OPC lives up to the promise of interoperability, which allows end users to choose the application or vendor that best suits their needs. 

Let me sum up by saying I believe OPC was and still is the right choice.  This ‘challenging learning experience’ was not the result of using OPC, but rather implementation mistakes and less than effective communication on our part as the OPC vendor.  As a company committed to OPC,  MatrikonOPC cannot blame the occasional implementation mishaps on the all-too-easy-to-use camouflage of  ‘it’s an OPC problem’.  That would do a disservice to ourselves, OPC and the OPC community.