Hi,

in our plant we have communicated many years Honeywell`s PlantScape system with our HP-UX based MES due to some Network APIs for UNIX not more supported by Honeywell.

Once we have upgraded from Plantscape to Experion and 32 bit HP-UX to 64 bit HP-UX machines (Itanium)these APIs are not valid for more time.

We are thinking about OPC (Experion has an OPC Server) to solve this problem, but we are not able to find a comercial OPC client for UNIX or for an intermediate LINUX "bridge" machine, since comms between LINUX and HP-UX is not a problem for us.

I mean:
EXPERION(OPC Server)->LINUX(OPC Client)->64 bit HP-UX (MES)

Has anybody any other idea to solve this problem? Does anybody know any OPC client for UNIX/LINUX?

thanks,
Torre

 

Technosoftware has an OPC stack for Linux. A custom development on HPUX would be as better solution.

 

Hello,

Please consider our open-source Plantstreamer product. It works with OPC DA and stores the data in a PostgreSQL database. It is multiplatform, so if you have java in HP-UX you can run it there. Our own platform of choice is Linux.

If you need some customization or any other assistance for your project, please let us know.

Best Regards,
Andrey Romanenko
andrey (at) ciengis (dot) com

Ciengis - Advanced Process Control and Optimization

 

Does your HP-UX based MES support OPC communications?.

What other alternatives different from APIs support your MES?

 

What options does your MES system have for communicating? That is, you said "EXPERION(OPC Server)->LINUX(OPC Client)->64 bit HP-UX (MES)". However, how are you planning to do the "LINUX(OPC Client)->64 bit HP-UX (MES)" part of it? I assume from your description that you need some sort of custom application for this.

There are several different types of OPC, which work in different ways. The common one is built entirely around Microsoft DCOM, so it really only works on MS Windows. There are emulation libraries that work on Unix, but there is also other solution to this.

I will give you several options. All of them are free (except for any OPC servers you might need for the Experion system).


Option #1
=========

If you are planning on writing a custom application for it anyway, then have a look at "http://openopc.sourceforge.net/". This is a Python library.

You would use it in two parts. One part is a gateway program that you would run on the MS Windows machine where your Experion system is located. This would take care of talking to the OPC server.

The other part is a library which you would use in you application that talks to the MES system. The two parts would communicate through the "Pyro" RPC protocol that avoids the headaches of DCOM.

With this, I think you could probably run the second part directly on the HP-UX machine, as Python should be available for that. If that isn't desirable, you can still run it on the Linux system.


Option #2:
==========

Could you use Modbus/TCP to talk to the Experion system? You could install a Modbus/TCP server (using OPC) on the Experion system and go like this: "Experion --> Modbus/TCP Server --> Modbus/TCP Client(Linux) --> MES (HP-UX)". Again, you might run the Modbus TCP client directly on the HP-UX system.

Again, this assumes you are writing a custom application that converts Modbus/TCP to whatever the MES system can understand.

For a Modbus/TCP client look at the following:
"http://sourceforge.net/projects/mblogic/". You would want the "MBLibs" package with the SimpleClient library. The project web site is at: "http://mblogic.sourceforge.net/".

This is a Python library. This is my project, so if you have any questions you can contact me on it.


Option #3:
==========

Can you connect the MES system to something using a web service? If so, have a look at the links mentioned in option #2, but look at the MBLogic package.

Again, you would use Modbus/TCP to connect to the Experion system. You would then run MBLogic on either the Experion system, a separate Linux server, or the HP-UX system. The MES system can then commuincate to MBLogic using a web service protocol that is intended for exactly these sorts of applications. You have two choices of web service protocols - a REST protocol, and a JSON based protocol.

MBLogic also has soft logic and HMI built into it, but those are optional features and you can turn them off if you are not using them. The web management interface will give you the status of the system (including Modbus/TCP communications) at any time. It does both Modbus/TCP client and server, so if your Experion system already has Modbus/TCP you can use your existing OPC server.

So, this would be "EXPERION --> OPC(Modbus/TCP server or client) -- > MBLogic(Modbus/TCP to web service) --> MES(web service)"

Again, this is my project, so if you have any questions on it you can ask me.

If the above doesn't answer your questions, then if you tell us how you were going to have the MES system talks to the Linux bridge, then I might be able to come up with another solution.

 

Hi,

I think Matrikon wil have a good solution for you. Try to contact it.

Regards,
Sulaiman

 

Remember that the Honeywell OPC implementations (HOPC) are famously incompatible with other versions of OPC and generally have had difficulty interoperating with other OPC clients.

Walt Boyes
wboyes [at] putman.net

 

At first thank you everybody for your help.

We mainly have two types or brands of PLC or controllers at our site, Honeywell and Siemens.

Years ago Siemens had something similar as Honeywells Network APIs called SOFTNET to communicate with UNIX systems, but they left to support this software for new releases of UNIX OS. To solve this we used an intermediate Linux machine with an applicom card which is able to communicate directly with our Siemens PLCs. Then we developed C programs using sockets to connect both machines (HPUX and Linux)in a server-client mode.

We have not been able to find any card capable to communicate directly with Honeywell S9000 and HC900 controllers, so we did it the way I explained it in the first post (using the SCADA/DCS as gateway to the field controllers).

These are the ways we have used to communicate our field signals with our self-made, Informix based MES system.

Yes M.Griffin, independently the way use choose, I think that a custom application is inevitable.

 

I would guess that you could implement one of the solutions that I outlined previously much more easily than you could add OPC directly to your MES system (if that's even possible). I'm not aware of anyone offering an MES solution that is really anything more than just a C or Java toolkit to write your own bridge.

There are some special OPC versions that offer an XML based protocol interface. However, they are so complex that everyone seems to take one look at them and give up rather than even attempt to use them in this type of application.

This is a big problem that a lot of people have. OPC was intended as a driver interface for DCS and SCADA systems. Integration to MES systems seems to be mainly custom programming though, as there isn't really any other straightforward way of doing this. Some people use OPC to stick the data into a database and then have the MES pull the data back out again using the database's normal interface, but that is quite a convoluted solution if you are after live data.

Most people doing MES type stuff seem to want a very simple web service interface (like the one I mentioned in option #3 in my previous reply). However, people doing automation type software seem very adverse to providing one for some reason.

 

Solutions converge to the following:

Use your custom C sockets programs in the HP-UX end to communicate with another custom C program in the Experion-OPC server end that read the field values from this server using OPC client primitives.

 

Traditional OPC is based on COM/DCOM. Thus it is tied to Windows.

But OPC XML-DA now uses web services (http/soap/xml). This is independent from operating system

Our HMI/SCADA project, http://pvbrowser.org, provides an OPC XML-DA client.

If your server only provides COM/DCOM, you might use a (software)Gateway like. http://www.dopc.kassl.de/ in order to connect to XML-DA

 

Hi,

For option 2, I can't get your point. What is the meaning of "install a Modbus/TCP server (using OPC) on the Experion system..."?

Thanks.
HL

 

In reply to hlliu: The "Experion system" is the SCADA/DCS system. The MES system can't talk to the Experion system directly because apparently the Experion system doesn't have any means to do so.

The reason for installing a Modbus/TCP driver on that system was to get an open protocol that other software could talk to. OPC was the suggested means of interfacing the Modbus/TCP driver to the Experion software. That was the means the original poster was considering using.

Once the Experion system was able to communicate using Modbus/TCP, there are lots of options available for interfacing it to other systems as Modbus/TCP is an open protocol. Both options 2 and 3 used this idea, but with different means of making use of it. Option 2 involved their interface software using a Modbus/TCP client library. Option 3 involved using MBLogic as a "bridge" to allow the MES system to use a web service protocol, which could eliminate the need for them to adapt their own existing bridge software.

OPC is a method of using Microsoft COM/DCOM to interface two different pieces of software where you don't have source code for either. Normally, one program is a protocol driver (e.g. for Modbus/TCP), while the other is a SCADA, DCS or HMI package. It's a complicated and round about way of doing things, but it's the method that a group of companies in the automation industry decided to adopt. There is a new version of the OPC spec that no longer uses COM/DCOM in order to try to eliminate a lot of the problems associated with it. However, most existing software uses the old COM/DCOM method.

The OPC protocol driver is called a "server", because it is one from the point of view of the SCADA/DCS/HMI system. The SCADA/DCS/HMI system sends a request for data, and the OPC server replies with the response. The SCADA/DCS/HMI system is considered to be an "OPC client" because it initiates the requests.

Where it gets confusing is that the "OPC server" (protocol driver) is usually also a "client" from the perspective of the industrial protocol (field) side. However, it could also be a "server" from both sides (OPC and field), depending on how the software was written.

For option 2, the Modbus/TCP OPC driver either needed to be:
A) an OPC server + Modbus/TCP server to work directly,
B) or else there needed to be another Modbus/TCP server in the middle to allow both the OPC driver and the MES bridge to talk to each other. The MBAsyncServer package in MBTools could do this.

For option 3, MBLogic can be both a Modbus/TCP server and a Modbus/TCP client simultaneously, so either type of OPC driver could talk to it directly.

Option 1 suggested looking at the OpenOPC library, but that still needs an OPC server in the system.