It so happens I _have_ Sotz Monster Maul around here someplace, probably left over from the last depression/energy crisis. The newer fiberglass handle mauls are much easier to interface and safer in explosive environments. And you don't have to bring it inside because your gloves are frozen to it. My shoulders remember the Sotz well. But next year's mauls will fix all the bugs with this years mauls and they'll have demos on You Tube.

Regards
cww

 

Well, you're kinda getting ahead of the game. Anything with MS on the box is an unquestionable necessity for automation. They had to go with Silverlight because work was stopped on the products based on Microsoft Bob due to availability. The list of MS failures to choose from is quite limited due their being replaced by innovative new failures all the time. It's tough to have to go dumpster diving for your automation needs. Anything based on XML is probably a winner because not only has it been successfully perverted by MS, but it provides the means for even more vague definition. It will even encompass splitting maul semantics without any rule violation. I think it will be replaced with high rel automation interfaces based on the MS Home Entertainment package and Kinect technology.

There are no more viruses and malware, those are actually security challenges to test your security and MS will simply shut down those pesky infected systems. Remember. it's all your fault, and Redmond has it and it's minions under control.

Well, it's getting cold in here again.

Regards
cww

 

IN reply to pvbrowser:

> The future might be OPC UA where the server is integrated within the PLC. <

There's two problems with that. The practical one is that OPC UA is not exactly a light weight protocol. It would consume quite a bit of CPU power to handle it. The not so obvious problem (from the PLC vendor's point of view) is that if it worked it would effectively provide a common protocol for talking to PLCs. If the major vendors wanted that, they could have done that at any time in the past 20 years without waiting for OPC.

> OPC XML-DA is easy but the binary protocol is not that open. <

OPC UA comes in two forms - XML and binary. The XML form is a large, heavy weight protocol based on SOAP. That may possibly be an improvement on COM/DCOM, but in my opinion they would have been better off with just about anything else. SOAP originated in the IT industry, and there it has been pretty widely recognized as a failure and people have gone on to using simpler things.

At some point the OPC UA designers came to the realization that SOAP is simply to complex and verbose and it is not practical to get acceptable performance out of it on embedded devices. They then came up with an encoder/decoder which turns the SOAP messages into a binary format. As of the last time that I checked, I there was no specification in existence for this binary format.

 

In reply to Tallak Tveide:
> Given the amount of flack that OPC gets in this thread

OPC isn't taking flack for something they've done. They're taking flack for trying to solve a problem that shouldn't exist in the first place. The fundamental problem is that certain vendors want to keep the protocols required to access their hardware to themselves. Trying to provide a technical solution to a political problem always produces in a less than satisfactory result. In that sense, OPC is taking the flack that should be directed at those vendors.

> Show me something based on HTML, SVG or the canvas element and things are looking brighter... <

Well, I'm doing that:

http://sourceforge.net/projects/mblogic

I don't want to high jack the thread, but I'm just replying to show that this is indeed quite possible from a technical perspective.

> So to answer the original question
> - based on open standards
> - scripting in ruby, javascript or python (or all) <

The server is written in Python, and the client is written in Javascript. You don't have to do any scripting though to use it.

> - licensing that doesn't restrict the number of terminals <

GPLv3

> - client server <

Yes

> - not having to deal with a mess of taglists etc <

Configuration is straight forward.

> - of course super stability <

I haven't seen any problems there.

> - not tied to any operating system <

Releases with Linux and MS Windows versions. People tell me the Linux version also runs on Mac OS/X, but I don't have a Mac to test so I don't do official releases for that.

> - a good system for collecting data <

The latest version logs alarms and events. I'm not trying to create a SCADA system though.

> To my knowledge Ignition delivers most or all of this, and I guess is the kind of competition your up against, if someone should one day decide to leave the big brands... <

Ignition is a SCADA system, and I don't think it's really the same thing as Mobiform's Status Vision (or to what I am trying to do either). From what I can see of Mobiform's software, they are more of a basic HMI with a few added features.

I haven't tried Ignition, but from a the information they provide it looks like a very impressive piece of software. It's also a pretty expensive piece of software, but that end of the market usually is. Mobiform doesn't seem to have any lists prices, which usually suggests their stuff isn't cheap either.

 

In my opinion people here are not really up to date concerning OPC. OPC-UA does not depend on DCOM at all. There are already implementations available and adapters allows it to work with the older OPC implementations.

Although I think creating on OPC client is not all that difficult, there are also several good tool-kits around that make it even easier.
OPC doesn't make things more complicated. In fact it goes back to the basics of what data is. It has a value, a timestamp and a quality. Data-items come from a server, are grouped together and have a unique identification. Nothing more, nothing less.

Working on bigger DCS systems OPC is a good solution for us. Using the same code we can now get (and write) data from virtually any system, big or small, in a secure way.

People building smaller systems should not forget that maybe, at some point in time, their solutions need to be integrated in a bigger picture.

Having said that, any HMI I use will have to support OPC as well as other open standards. It should also allow us to create HMI's that are compliant with the Abnormal Situation Management consortium guidelines.

 

The "Browse" function in OPC UA is a good concept.
Thus you can explore the data that is available.

On the other hand Modbus (RTU/Ascii/TCP) is all you really need. I only miss float variables.

Our concept simply uses
- shared memory for the cyclically read variables
- mailbox for sending variables to a daemon
Now you may have several daemons each even talking a different protocol to a PLC or fieldbus and exchanging variables with the HMI server by the shared memory and the mailbox.

For talking to the hardware we can use our own library (rllib) (Modbus ...) or foreign libraries.
For example http://libnodave.sourceforge.net/ for Siemens PLC.
For example an OPC UA client library you may buy.

Thus for us it does not really matter which protocol to use. We are flexible.

 

In reply to Rudi:
>OPC doesn't make things more
>complicated. In fact it goes back to the
>basics of what data is. It has a value,
>a timestamp and a quality. Data-items
>come from a server, are grouped together
>and have a unique identification.
>Nothing more, nothing less.

That may be the case in large scale process industries. In typical factory automation applications however, *none* of those items other than the value are of any relevance or interest. The communications channel can be thought of as just an extended PLC backplane.

>People building smaller systems should
>not forget that maybe, at some point in
>time, their solutions need to be
>integrated in a bigger picture.

There's no reason why that would involve OPC however. OPC is just a popular interface between SCADA systems and their drivers. The actual communications with the field takes place using protocols such as Modbus, Profibus, etc.

>Having said that, any HMI I use will
>have to support OPC as well as other
>open standards. It should also allow us
>to create HMI's that are compliant with
>the Abnormal Situation Management
>consortium guidelines.

I had to look that name up in Google because I've never heard of them before. Their brochures say: "ASM a registered trademark of Honeywell International". They want to sell me a set of guidelines on how to design an HMI display. I can't see the connection here with OPC.

If we go back in the discussion a bit, you will see that I was drawing a distinction between the needs of SCADA systems (where OPC originated) and typical factory automation applications. One wants to monitor a large plant, while the other usually just wants to replace a push button panel with something programmable. In the latter case, simplicity and low cost are paramount. Some of the software that has been mentioned here is $10,000.

Let's put things in perspective here by creating some sales categories. Here's the categories that I think matter (including all third party software, such as OPC drivers):

1) $0 to $100. The open source ones are of course $0. Customers will probably see this range as low (financial) risk.

2) $100 to $500. This may be the price point as which an unknown vendor has to be to get customers to take a risk on them.

3) $500 to $2000. You can charge this kind of money if you have a big name behind you.

4) More than $2000. This is where most SCADA systems fall (often $10,000 and up).

Since we are talking strictly about software, I have excluded the products which combine hardware with embedded HMI software.

 

Since this turned into an OPC discussion:

Opc has done a lot of good things. Interoperability, symbolic names instead of addresses, endianness and low level stuff has been taken care of

So at first glance OPC is great stuff, and many don't understand what the problem is

- OPC is not an open standard. Getting access to the specs is not cheap. The end users have no way of debugging OPC themselves because of this

- OPC requires windows, and I think this is the main reason that no (?) plcs have integrated OPC servers at this date

- OPC servers I have used have severe stability issues and poor scalability and use too many resources. See this in the light that OPC does not DO anything

- Different vendors implement different subsets of the spec and interpret it differently, so interoperability between different brands is still difficult

- in year 2011 we should not have to deal with systems that dont communicate over normal networks (no comms between different domains without reducing machine security to a ridiculous low level)

Many of these things are based on OPC being COM

 

In reply to M Griffin:

Nowhere do I see in the original question that this is about small systems only. So, my apologies to those who don't want to read about some of us relating to HMI requirements for bigger systems.

In these bigger systems we usually do care about the quality and the timestamp of a value but in places where we don't we can just ignore it. In bigger systems there are generally also several servers providing data so also that one is relevant. Other protocols also have things like "device ID".

All this was in reaction to the comment that OPC makes things more complex by adding unnecessary features. In my opinion it does not, it actually simplifies things - for us.

Indeed, OPC is not meant for communication with field devices. However if we have a packaged unit on the plant (the smaller system that needs to be integrated - and we do have tens of those) I'm not interested in direct communication with field devices and that is where OPC comes in handy for us.

The ASM consortium, indeed a group in which Honewell worked together with several of their customers, spend several man-years figuring out what works and what doesn't when building HMI's (the scope was actually broader than just HMI). The investment was huge so I can see the logic behind the fact that the results of these studies are not freely available. Anyway, I just saw it on Amazon for something like 115$. This discussion is not about ASM so I will not discuss it further but there is one thing I want you to think about. If a screen object changes color from green -usually means OK - to red - usually means bad stuff - do you think we are helping the operator when we do that ? Hint: 20% of the male population is color-blind and guess which colors are for them generally most difficult to distinguish from each other. I don't know about you but I've seen several HMI's doing that.

Anyway, if I build an HMI it has to be compliant to these guidelines so any system I would use would have to allow me to do that.
You cannot see the connection between ASM and OPC because there is none - of course. But then again, this discussion wasn't about OPC originally.

Kind regards

 

>Since this turned into an OPC discussion:<

Not my intention but I just noticed so much misinformation.

> Opc has done a lot of good things. Interoperability, symbolic names instead of addresses, endianness and low level stuff has been taken care of

> So at first glance OPC is great stuff, and many don't understand what the problem is.
> - OPC is not an open standard. Getting access to the specs is not cheap. The end users have no way of debugging OPC themselves because of this <

I don’t see how having the specs would help an end user debugging. Either the client is using functionality that the server doesn’t support or there is a security issue. One can do a lot using the free tools that are on the internet.

>- OPC requires windows, and I think this is the main reason that no (?) plcs have integrated OPC servers at this date <

A misinformation I already addressed before. Unified Architecture does not need windows.

Did you know there is a 100% Java OPC-DA client implementation available on sourceforge. It still uses DCOM but the client implements its own version. No DLL’s are used. I don’t know in how far this is tested on other operating systems .

>- OPC servers I have used have severe stability issues and poor scalability and use too many resources. See this in the light that OPC does not DO anything <

The servers I’ve used so far don’t use a lot of resources. A few megabytes of memory and between 1 to 5 % CPU. I did come across one or two that had stability issues but this may have more to do with the quality of the programmers than it has with OPC. See this in the light of moving 5000 values per second in a secure way.

>- Different vendors implement different subsets of the spec and interpret it differently, so interoperability between different brands is still difficult <

Also my experience but when documented I think it’s ok. I think there is a minimum set required. Also note there is an OPC certification program and OPC test tools. Although I generally use the (free) Matrikon software to do testing.

>- in year 2011 we should not have to deal with systems that don’t communicate over normal networks (no comms between different domains without reducing machine security to a ridiculous low level) <

Short answer: you don’t. As OPC UA doesn’t use DCOM, DCOM security doesn’t get in the way any longer. But also DCOM can be configured to use only two ports. I agree that not a lot of people know that. For the rest the only requirement is that both systems have the same user with the same password.

Further OPC tunnels exist already for a long time- living of the fact that most people don’t know the above.

> Many of these things are based on OPC being COM,

Indeed, although DCOM is well tested (millions of applications have been using it for many years) and in relation to security very powerful, if is also very often misunderstood.

 

In reply to Rudi:

>A misinformation I already addressed
>before. Unified Architecture does not
>need windows.

One of the problems that OPC UA has to deal with is that it is based on SOAP. The SOAP standard is huge, incomplete, poorly specified, and contradictory. Nobody implements the whole spec, and everybody who implements part of it implements a different part. The result is that compatibility between different SOAP implementations is rather poor except for the most commonly used functions. If you're lucky you can find enough working overlap between different implementations to be able to do what you need for a specific application. This is why most of the IT industry has written off SOAP as a bad job and gone on to using simpler things (primarily REST web services).

If you look at the OPC literature you can see that the SOAP implementation they regard as the "gold standard" is the one in Microsoft's Dotnet libraries. The end result is that while OPC UA is in theory platform independent, in reality there is a platform dependency on MS DotNet that lies below the OPC level, just not to the same degree as there was with COM/DCOM. Any implementation on any other platform is starting with a serious handicap in that regards. Yes theoretically alternate implementations are possible (as you said, it's been done), but I doubt that it is possible by just sitting down with a copy of the OPC UA spec and doing what it says. You would have to spend a lot of hours pouring over XML dumps trying to reproduce all the bugs and quirks in Microsoft's libraries. I've actually had to do this before with SOAP (although not for an OPC project), so it's not just a theoretical concern.

The OPC Foundation is not responsible for the problems with SOAP. However, I think it was a rather unfortunate decision on their part to use it. Seven years ago when they started on OPC UA the problems with SOAP were not quite so readily apparent. The IT world however moves at a faster pace and by the time OPC UA is used on a significant scale it is quite conceivable that the IT industry will have largely abandoned SOAP. If that happens, who is going to maintain the SOAP libraries? The whole OPC UA spec might have to be ported to yet another platform.

>The servers I've used so far don't use
>a lot of resources. A few megabytes of
>memory and between 1 to 5 % CPU. I did
>come across one or two that had
>stability issues but this may have more
>to do with the quality of the
>programmers than it has with OPC. See
>this in the light of moving 5000 values
>per second in a secure way.

Actually, 5000 values per second does not amount to a very large application if this was a factory automation project. If you had a 20 msec scan rate (which is not particularly fast), then that's only about 100 I/O. It's hard to judge what your numbers mean however, as I would expect the main overhead to be not internal to the server or the server's field communications, but rather in the application to OPC server communications which has to go over COM/DCOM. Finding the actual overhead attributable to OPC would be very difficult without constructing a special benchmark application. I would be interested in seeing any actual benchmarks that anyone has if such a thing exists, as I have seen lots of complaints about OPC being slow but no actual numbers. To put things in perspective however, I have seen a Modbus/TCP client poll a Modbus/TCP server using TCP/IP over localhost at a rate of millions of coils per second.

As for stability problems, COM/DCOM programming is notoriously difficult to do and many OPC servers have a long history of memory leaks. Typical MS Windows programs that use COM/DCOM only run for short periods of time before shutting down. OPC servers however are meant to run indefinitely, and so any memory leaks at all will eventually result in a crash. I've seen this happen and the issue has come up here a number of times before. It's not something that is inherent to OPC itself, it's just that it is very difficult to write a good OPC server (i.e., one without serious bugs). Some vendors manage to do it, but I doubt it was easy for them.

>Nowhere do I see in the original question that
>this is about small systems only.

The response was to your statement that "it goes back to the basics of what data is. It has a value, a timestamp and a quality. Data-items come from a server, are grouped together and have a unique identification. Nothing more, nothing less." Those characteristics may be desirable for some applications, but they are unnecessary for many others and they certainly are not fundamental to what data is. There was some previous discussion to the effect that some of the things that OPC tries to do may be desirable for some applications (large SCADA systems in particular), but are not desirable for other applications. In other words, OPC is not a "universal solution" to industrial communications. I don't think such a goal would be either feasible or desirable.

>All this was in reaction to the comment
>that OPC makes things more complex by
>adding unnecessary features. In my
>opinion it does not, it actually
>simplifies things - for us.

Many of the complaints that are commonly heard are from people who just want a simple driver and don't want most of what OPC does.

>there is
>one thing I want you to think about. If
>a screen object changes color from green
>-usually means OK - to red - usually
>means bad stuff - do you think we are
>helping the operator when we do that ?
>Hint: 20% of the male population is
>color-blind and guess which colors are
>for them generally most difficult to
>distinguish from each other.

This is a bit off topic, but complete red-green colour blindness is actually rather rare. What is normally the case is that there is some impairment of colour perception such that certain mixed shades of red or green appear to be more of a muddy brown. Pure reds or greens (and most shades close to those) are normally perceived quite clearly by most "colour blind" people. This is why red and green traffic lights still work. Most people who are "red green colour blind" won't know it unless they are tested with specially designed test patterns. There are of course also people who are blue-yellow colour blind, and there are people who have no colour perception at all. Again though, these are rare.

>But then again, this discussion
>wasn't about OPC originally.

And I want to be clear that I think that OPC is taking a lot of the flack that is really meant for the automation vendors who want to limit the degree to which anyone else can communicate with the equipment they sell. Typically, the only option they will allow is via one or a few OPC servers. That's not a good solution for many applications. This leads many people to try to use OPC for applications for which it isn't suitable, and OPC ends up taking the blame for the problems that result.

 

>> - OPC is not an open standard.
>Getting access to the specs is not
>cheap. The end users have no way of
>debugging OPC themselves because of this
><
>
>I don't see how having the specs would
>help an end user debugging. Either the
>client is using functionality that the
>server doesn't support or there is a
>security issue. One can do a lot using
>the free tools that are on the
>internet.

For me this has been an issue ;-) I don't see why the spec must be licensed.

>>- OPC requires windows, and I think
>this is the main reason that no (?) plcs
>have integrated OPC servers at this date
>A misinformation I already addressed
>before. Unified Architecture does not
>need windows.

A lot of my arguments do not apply to OPC-UA. But in my everyday life, no one yet uses OPC UA. It is a different protocol than OPC, and drivers are still rare. So this argumentation does not really help me much.

>The servers I've used so far don't use
>a lot of resources. A few megabytes of
>memory and between 1 to 5 % CPU. I did
>come across one or two that had
>stability issues but this may have more
>to do with the quality of the
>programmers than it has with OPC. See
>this in the light of moving 5000 values
>per second in a secure way.

Come on. 5000 values per second is not a big deal IMHO, and should not consume 5% CPU on a computer. I believe my argument stands.

>Further OPC tunnels exist already for a
>long time- living of the fact that most
>people don't know the above.

I believe that we should not have to rely on such tools - a standard firewall solution should be enough. For most people, the bigger problem is lack of communication, not lack of security.


>> Many of these things are based on OPC
>being COM,
>
>Indeed, although DCOM is well tested
>(millions of applications have been
>using it for many years) and in relation
>to security very powerful, if is also
>very often misunderstood.

I have not yet touched many of DCOM's other shortcomings. IMHO it's just the wrong technology.

But hey - given todays status quo, any serious HMI should support both OPC and OPC-UA ;-)

 

In reply to M. Griffin

Could you please tell me the difference between
OPC XML-DA and OPC UA with the XML data.
OPC UA binary protocol is different of course.

We have implemented OPC XML-DA using
libcsoap, libxml2 and nanohttp
and tested against
http://www.dopc.kassl.de/

You can find our implementation within:
http://pvbrowser.de/pvbrowser/tar/pvbaddon.tar.gz
directory: pvbaddon/daemons/opcxmlda/client

 

In reply to pvbrowser: I don't know what detailed differences there may be between OPC XML DA and OPC UA. Both are based on SOAP and both carry their historical OPC COM/DCOM concepts into their new SOAP implementation. However, I don't know what if OPC XML DA is forward compatible with OPC UA. OPC UA does add a lot of new features that OPC XML DA didn't have relating to things like alarms and historical data access. However, these may or may not affect simple data access.

I do however very strongly recommend reading the following if you have not already done so:

Diplomarbeit: SOAP Interface For An Internet/Fieldbus Gateway
http://violin.qwer.tk/dusty/thesis/html/index.html

PyOPC: A Python Framework for the OPC XML-DA 1.0 Standard
http://pyopc.sourceforge.net/docs/html/index.html

Both are by Hermann Himmelbauer who performed the work as part of his university thesis.

For anyone else who doesn't want to read the whole thing, here's two pages which are of particular interest:

OPC - Object Linking and Embedding for Process Control
http://violin.qwer.tk/dusty/thesis/html/node17.html

Conclusion and Future Work
http://violin.qwer.tk/dusty/thesis/html/node79.html

 

In reply to M. Griffin

Thanks for the links

 

In reply to M Griffin:

> Nobody implements the whole spec, and everybody
> who implements part of it implements a different part.

As long as the OPC server and clients implement the same part I think it’s OK. We are not creating general web-services so compatibility between OPC implementations should be enough.

> (as you said, it's been done),
I was referring to an OPC DA client, written in Java, using DCOM but without using any DLL’s.

> Actually, 5000 values per second does not amount
> to a very large application if this was a factory automation
> project. If you had a 20 msec scan rate (which is not
> particularly fast), then that's only about 100 I/O.

When referring to HMI I think 20ms is serious overkill. 4000 to 6000 values per second is what I see typically in our DCS system on one OPC server servicing 4 displays. We have 20 of those. They are DELL 490 machines and there hardly is any CPU usage when I monitor it.
I think there are three major causes for slow OPC communication:
1) Forcing the OPC server to do synchronous reads all the time. This is often done when async reads don’t work, not realizing this is only because of bad security configuration.

2) Slow devices or slow (e.g. serial) communication with the device.

3) Forcing the OPC server to do device reads all the time. In combination with cause 2 is this a real killer.

We typically refresh our screens every 4 seconds (maybe the process industries have slow operators ) except on rare occasions where the system switches to one second. Not because the OPC server cannot go faster but because first it is not required and second because of the load on the network of the underlying system - item 2 above.

> As for stability problems, COM/DCOM programming is notoriously
> difficult to do and many OPC servers have a long history of
> memory leaks. Typical MS Windows programs that use
> COM/DCOM only run for short periods of time before shutting down.

My experience with a lot of C/C++ programs which I bring back to, among other flaws, the missing garbage collector in these languages.

> OPC servers however are meant to run indefinitely

Ours do for long periods and when stopped it is usually for other maintenance on the PC’s.

> The response was to your statement that "it goes back to the basics
...

We can keep on for a long time here because one can find things in every protocol that are "not so useful for me in this application". I certainly agree with ...

> I don't think such a goal would be either feasible or desirable.

> This is a bit off topic, but complete red-green colour
> blindness is actually rather rare.

This remark is missing the point of my statement but maybe you might want to read this:
http://en.wikipedia.org/wiki/Color_blindness
If I show my son something red and something green he cannot differentiate.

What OPC mainly brings to us is that we have an HMI solution that can read and write data from and to many different systems and devices using only one code-base.

Can I add attachments here (?) because I used to have some document (PDF) on OPC benchmarking. If I find it again I can send it.

 

In reply to Rudi:

>Can I add attachments here (?) because
>I used to have some document (PDF) on
>OPC benchmarking. If I find it again I
>can send it.

If you upload the file to any free file host such as rapidshare, megaupload, or sendspace, then you can post the URL here. Alternatively, you could just post a short summary as text here. Don't put yourself out unnecessarily however if it's a big problem.

 

http://rapidshare.com/files/442224123/Performance_And_Throughput_of_OPC.doc

http://rapidshare.com/files/442224124/performance.doc

 

In reply to Rudi: Thanks. I spent a bit of time and read over them and have a few observations. Both documents are from the 1990s, so it's not possible to easily compare them to any tests we might do today (computers today will be faster).

However, the following bits of information from "DCOM, OPC and Performance Issues" are particularly interesting. This test ran a custom made client in a tight loop to read data as fast as possible. I will be quoting the results which read 100 items (numbers) per iteration.

1) The client and server are on the same PC - "Local Server -1 Client". This did 625 transactions per second.

2) The client and server are on different PCs - "Remote Server -1 Client". This did 66 transactions per second.

Running the client and server on different PCs made a factor of nearly 10 difference in performance. The client and server in this case were only at about 10% CPU usage (as opposed to 50% each for the local test). However, that is because something else other than the server and client was now the bottleneck.

3) Test #2, but using 4 clients - "Remote Server - 4 Clients". Each client ran at roughly 45 transactions per second (for a total of 187 if you add them all together).

Per client performance was slower again, but the aggregate (all 4 added together) was higher. Server load however was the same as in test #2.

From this it would appear that running the OPC server and the client on separate PCs could result in a huge drop in performance, rather than the increase that might otherwise be assumed would result from adding extra hardware.

It also looks as if the way the server was written *may* make a difference in how it performs. I say *may* because I don't know how much difference is attributable to DCOM handshake overhead, or how much the server can really do about it.

From this I would conclude:

A) Anyone using OPC in an application where performance matters needs to benchmark the exact configuration they intend to use. There is no point in using generic benchmarks.

B) OPC servers and clients from different vendors may behave differently. For that matter, servers from vendor "X" may or may not work optimally with clients from vendor "Y".

C) This subject *is* complicated, and there's probably no simple answer here.

 

1. Highly distributed or Web launched - don't need to install client software to run on a new computer. The lighter the better from an installation/running perspective.

2. Ubiquitous - can run on any platform (Windows, Linux, Mac, etc). Usually this means Java - could be Flash of HTML 5.

3. Full featured - supports alarming, pdf reporting, animation, etc.

4. Mobile - new trend. Can use on iPods, iPads, Androids, etc.

5. Strong integration with existing systems. Good multi-vendor SQL database support, MES/ERP integration.

Ignition by Inductive Automation supports all of these.

I would add that OPC-UA support, good security, an "IT friendly" design (ie, works with Active Directory, industry standards, etc), scaleability, clustering, and robust scripting environment are more features that I would look for.

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com
"Design Simplicity Cures Engineered Complexity"