Hello All,
I have several questions concerning Honeywell's OPC Server and its functional successes in allowing 3rd party OPC clients to interface the LCN via Honeywell's APP Node. The question develops from our need to connect a third party Advanced Process Control system to the LCN. Talking with Honeywell they state that this should be no problem and they have even taken the assignment to setup the OPC Server Side themselves. This has caused me to wonder though. It appears that thier OPC server is a Software solution that is not ingrained into the Control Software itself, thus it must have several levels of development, i.e. from the client side, i.e. to map to the server variables, as well as from the Server side itself, i.e. to map to the LCN internal variables. In my working with other OPC complient DCS system, namely the Emerson's DeltaV System, this server side development is fully ingrained in the software upon install. Am I right to think that Honeywell developemnt is like this? Has anyone had to set this server up on an APP node and utilize the APP as a 3rd party OPC gateway?

Also, looking at the OPC Foundation I see that the Honeywell OPC server has past our chosen OPC Client Interoperability Test, but I am wondering about actual implementations and a possible set of Lessons Learned from those projects. What problems were faced when this solution was attempted?

Any and all information is much obliged,

TexasFM3

 

We have a customer that has successfully interfaced our BrainWave advanced process controller to Honeywells app node. So it is what you are looking for, third party APC software, OPC communications, etc. contact me offline if you want more details ...."[email protected]", mailto:[email protected]

Rick

 

We have successfully interface OSIClient software to honeywell PlantScape OPC server. I'm not sure I understand you comment about the OPC server not being ingrained in the control software due to the open structure of the control software, honeywell offer a range of data access components in the system sofhtware to serve data to clients. The OPC server is run as a seperate process but has direct access to the system db thus it is possible to stop start and change configuration of the OPC server without affecting the system DB.

The control system software comprises of many processes and datatables the OPC server is fully integrated into this structure.

Hope this helps.
Mark Mullins.

 

Hello Mark...

Thanks for your reply... What I meant was that the OPC server seems to be a software solution that was developed sort of like a patch work interface and must be installed as another software on top of the DCS control software. Once this is done then it seems that it must be configured and explicitly told what to serve out thru the OPC interface. Am I wrong in this assumption? I know that with my back ground in Emerson's DeltaV, when the Software is installed it is simply a matter of connecting a Client to the system and moving forward. With the Honeywell OPC server, it seems that not only must we set the client up, but we must also set the server up as well. I assume this because you state "stop start and change configuration." This tells me that the Honeywell does not serve up all its internal items and must be explicitly configured to serve up any entities that we might want to control via the OPC gateway. Also, I know that there is a limit of about 800 items per OPC Server, thus we have to run multiple instances of the software if we have a requirement to push and pull more that this. I am again assumming that each server must be setup for its own list and human error might grow in this respect if work is not careful.

Am I correct in this?

Thanks for your insight...

TexasFM3

 

Because the LCN has it's own messaging structure and is a distributed database of data servers, LCN communication software and point.parameter
definition of some sort is necessary to gather the information. That's a fact. From there is can be ported into the OPC application.

The key is how quickly can this be done and maintenance of the link. Also the amount of data is an issue as too much demand on the data server nodes will choke the LCN.

We are in the process of developing a direct LCN interface that forms part of our product called aXConnect. We have database read routines that take LCN point configuration EB files and produce the LCN and OPC connections automatically.

Regards,

Paul Jager, President
www.mnrcan.com
[email protected]
(250) 724-1402

 

Hello TexasFM3,

OPC Tunneling may eliminate your Setup Headaches. OPC (OLE for process control) is the preferred communication standard for sharing process control data at all levels of the enterprise. But as OPC pours into mainstream acceptance, integrators like you may find configurations where OPC can be a hindrance to the panacea of plug-and-play application interconnectivity. (The most common situation occurs when applications on different Windows domains must communicate with each other. Still, other designs call for the use of low-bandwidth or unreliable networks. It is in these setups that OPC can make use of new “tunneling” technology, which eliminates the biggest OPC headache for integrators: setting up DCOM.)

OPC (OLE for Process Control) standardizes data sharing between plant floor devices (DCSs, PLCs, analyzers, etc - OPC compliant are preferred) and software applications (such as HMIs, Process Historians, trenders, etc). No matter what the device is, data is always shared with an application in a standardized format. Of course, standards-based communication is only half the task - the other half deals with the actual method by which the data moves across the network.

When OPC applications are installed on the same computer, they use Microsoft’s COM (Component Object Model) technology to exchange data. But, when installed on 2 separate PCs, they use DCOM (Distributed COM) for the data exchange.

Unfortunately, OPC developers have no programmatic control over DCOM, and are thus bound by DCOM’s limitations. Consider two OPC applications that are installed on two PCs on two different Domains. Clearly, their OPC communication must use DCOM. Consequently, the Domains must share at least one common username and password. (This sometime can be a serious issue, especially when these domains and applications are owned by different groups (IT and Process Control), different vendors (two different DCS vendors), or even different businesses altogether (when plants must share information). OPC applications from any vendor will be stopped dead in their tracks, unless this DCOM issue can be overcome. While these may be simple technical hurdles that are easy to overcome, they may also present serious political issues.)
In that case Tunneling Eliminates DCOM.

DCOM problems can sometimes be overcome with a few hours of work and good corporate maneuvers (politics). But, another approach is to eliminate DCOM altogether with Tunneling technology. In this case, an OPC Tunneller is placed on each of the two PCs. Each OPC Tunneller object communicates with its local OPC application using reliable COM. The two OPC Tunneller objects are then free to exchange data via any appropriate communication technology, such as TCP/IP, HTTP, HTTPS, XML, etc. The data transport technology can be selected by either the user or programmer to accommodate for the special needs of the required design. Third party passwords are immediately nullified, Domains become irrelevant, and network performance (bandwidth and reliability) is a non-issue. Thus, each OPC Tunneller has two objectives: to transfer the data in the most reliable way to the other OPC Tunneller object, and to translate all data back to standards-based OPC, so that the communication remains persistent and consistent. The result? All of the headaches typically associated with DCOM are alleviated. Specifying an IP address or computer name within OPC is all that is required.

Recommendation:
OPC is an accepted standard within the process control industry. Whenever possible, users should use the existing infrastructure: COM/DCOM. However, in cases where the underlying technology cannot accommodate the project’s specific needs, OPC Tunneling provides a viable and reliable alternative.

Best regards
Tapas K.Bhattacharya
[email protected]

 

Pleas give credit (for articles and information) where credit is due. For the above post by Tapas K.Bhattacharya ([email protected]).

Post copied word for word from an article by Randy Kondor, OPC Product Manager at Matrikon.

http://www.automation.com/sitepages/pid1456.php

 

Also the plagiarized post is completely irrelevant to this thread, and has nothing to do with either the problem or the solution. Nothing whatsoever.

So if you do have to plagiarize, make sure it's something relevant. Even a college student knows this much.