P

Patrick Barker

What are the top 5 features you look for when looking for HMI software. I work for Mobiform Software which has an HMI Software solution called Status Vision Designer. www.statusvision.com We are trying to break into the market with some great software and I am making sure we have all the right features in place.

J

James Ingraham

As a machine builder, my take is probably different from most people's. I need an HMI to run a single system, not a big SCADA system. So I've got at most three controllers I need to talk to, and usually only one. Most of the data I display is discrete, rather than process.

1) Flexibility. Especially with buttons. I need to be able to click a button and do several things as a result of one click. Set a tag and open a screen, maybe. Or set several tags. Have the button look different depending on tag states that aren't necessarily the same tags that the button operates on. RSView32 was pretty good about this, but FactoryTalk View (which is RSView32s replacement) has some limitations here.

2) Communications. It's got to talk to what I need to talk to. For me, that's mainly Allen-Bradley PLCs and Fanuc robots. Bear in mind that all the fancy OPC stuff requires an OPC server to talk to, so I have to think about whether I'll need to buy OPC servers for my devices, and what it will take to get the HMI software to talk to them. FactoryTalk View is really nice when talking directly to A-B PLCs because you can use a tag out of the PLC directly in a screen without having to create a tag in the HMI and mapping it to the PLC tag. Very slick. Difficult advantage for someone else to overcome.

3) Hardware. I'm perfectly cable of buying a PC, or industrial PC, loading Windows on it, and loading software on it. And installing all the patches. And the OPC servers if needed. And maintaining it. And, and, and... Or I can just by a PanelView Plus from A-B and not worry about any of that. I don't like have to administer Windows on the factory floor, and neither do my customers.

4) Ease of use. I don't want to fight the software. I just want it to work. WonderWare InTouch has all kinds of fancy features, and there are lots of people out there running critical systems on it. But I found I was constantly trying to get around the way it wanted to do things to make it do what I wanted.

5) Name recognition. I'm selling a machine to a customer. If I say "Allen-Bradley" they nod and smile. If I say "Siemens" they nod, at least. But if they've never heard of the vendor of major components of the system they are not likely to buy my machine.

Hope that helps.

-James Ingraham
Sage Automation, Inc.

S

Steve Myres

"1) Flexibility. Especially with buttons. I need to be able to click a button and do several things as a result of one click. Set a tag and open a screen, maybe. Or set several tags. Have the button look different depending on tag states that aren't necessarily the same tags that the button operates on. RSView32 was pretty good about this, but FactoryTalk View (which is RSView32s replacement) has some limitations here."

I'd expand on this or maybe it's offering a counterpoint. I use a HMI that in the beginning was intended to automate lab applications. So it came to be this kind of weird thing where it was really good at all the stuff you had to find workarounds for in the majors' packages, but stunk at the normal bread and butter MMI tasks.

Like there was no built in pushbutton object, or rather there WAS, in the Windows sense, and there were like ten different things you could do with it including attach your own script code to it, but there wasn't a normal momentary MMI, control panel pushbutton where all you had to do was fill in the tag address. You had to write script to do that. And if you had an element that set a value, you couldn't get it to read the associated value from the PLC instead of just echoing back the value you entered. If you wanted to force it to read the value FROM THE PLC, you had to set the display to read a different register, and transfer it within the PLC.

So to your "flexibility" I guess I would say "Study the creation of an MMI, and make one step processes for the 90% tasks, without taking out the flexibility for the other 10%."

M

M Griffin

I have some comments on what James Ingraham had to say rather than points of my own.

>I need an HMI to run a single system, not a big SCADA system. So I've got at
>most three controllers I need to talk to, and usually only one.

Mobiform isn't very clear where they think their software fits in the market. Is it a small and simple HMI? Is it a big SCADA system? Is it something else? Who is the intended user base? The average PLC programmer, or an MS DotNet software developer? They don't have a clear message here.

>1) Flexibility. Especially with buttons. I need to be able to click a
>button and do several things as a result of one click.

That's actually pretty easy to do with an HTML/SVG/Javascript based system. You can add as many "onclick" event handlers to a button as you want. I'm not sure how that would work with a Silverlight based system though (which is what Status Vision is).

>Set a tag and open a screen, maybe. Or set several tags.

Do you have some actual use cases for this that you would like to describe? That might be easier to relate to than an abstract description.

>Have the button look different depending on tag states that aren't necessarily
>the same tags that the button operates on.

There's no reason why that should be difficult to do. There's no reason why a click event handler should have to write to the same tag as is used for display update, and there are many reasons why it shouldn't do so.

>2) Communications. It's got to talk to what I need to talk to.
>For me, that's mainly Allen-Bradley PLCs

You've just hit on the biggest problem that any HMI system has to deal with. AB does not play nice with other children. Or, let me turn that around. If you have decided on using AB PLCs (and the same is true for some other vendors), then you have also decided that you're not going to communicate with anything else without a lot of effort and expense. There isn't much that a third party software vendor can do to fix that.

>Bear in mind that all the fancy OPC stuff requires an OPC server to talk
>to, so I have to think about whether I'll need to buy OPC servers for my
>devices, and what it will take to get the HMI software to talk to them.

The funny thing is that the OPC side of an OPC server is usually a *lot* more complicated than most of the actual industrial protocols they connect to. When the HMI software can simply talk the actual industrial protocol directly then the whole system is drastically simplified.

>Windows on it, and loading software on it. And installing all the patches.
>And the OPC servers if needed. And maintaining it. And, and, and... Or I
>can just by a PanelView Plus from A-B and not worry about any of that. I
>don't like have to administer Windows on the factory floor, and neither do my
>customers.

There are two aspects to this. One is whether or not the HMI software is relatively self contained so you don't have a lot of components to install, configure, and maintain (with all the usual version compatibility problems). If you need MS Windows Server OS, MS Sequel Server database, MS IIS web server, several OPC servers, and some software proxies to tie things together, then you have a big, complicated system that is expensive and time consuming to install and maintain. That effort is only really worth while if you have a very large system with very large amounts of data streaming through it.

If on the other hand you have just a few PLCs and operator panels, then what you want is something simple that is easy to install and maintain. Load capacity requirements in this case are negligible and the software package can be designed to be self contained. Costs can be much lower because you can install it on any PC and you don't need to license any extra third party software (except an OPC server if you're stuck with a closed protocol).

As far as hardware goes, I think the current tablet / iPad craze is going to have big impact on the small HMI market. Someone can take the basic hardware reference designs for an Android or Chrome OS tablet, take out the wireless hardware and battery, add in an Ethernet port and a serial port, and have a basic touch screen HMI panel that they can have made on the same production lines as the mass market consumer products. This can be used with a graphical HTML 5 type web based HMI. PLC vendors could build the web servers into their PLCs provided they used a simple HTTP/JSON protocol. This is technically quite feasible and not at all difficult to do and could be done as a firmware upgrade to the web server modules which many of them already sell.

>4) Ease of use. I don't want to fight the software. I just want it to work.
>WonderWare InTouch has all kinds of fancy features, and there are lots of
>people out there running critical systems on it. But I found I was
>constantly trying to get around the way it wanted to do things to make it do
>what I wanted.

There can be a conflict between "ease of use" and "do things the way I want it to". The "easy" way to make things easy is to make the default behaviour work the way you think the users will want. The more features that you add however, the more difficult it is to do this. That's why it isn't really practical to make one software package that serves the whole market.
>5) Name recognition. I'm selling a machine to a customer. If I say
>"Allen-Bradley" they nod and smile. If I say "Siemens" they nod, at least. But
>if they've never heard of the vendor of major components of the system they are
>not likely to buy my machine.

If the package cost a lot of money, then the customer wants to know that they won't be left with an orphan if the company goes out of business. If it's cheap (or free), then that doesn't tend to be a problem. To put it another way, the level of concern is directly related to how likely it is to put a hole in the maintenance budget if it ever has to be replaced. If we are assuming small, simple systems (as you described), the main cost is going to be software licenses. For very large complex systems the configuration and programming time will be more important.

P

Patrick Barker

Thanks James,

I appreciate the feedback. I think our software offers most of this. Minus the "Name Brand". This is just going to take time to build up a customer base.

P

Patrick Barker

Thank you very much for your feedback, I would like to comment on a couple of your points.

>Mobiform isn't very clear where they
>think their software fits in the market.
>Is it a small and simple HMI? Is it a
>big SCADA system? Is it something else?
>Who is the intended user base? The
>average PLC programmer, or an MS DotNet
>software developer? They don't have a
>clear message here.

Status Vision Designer is very scalable, meaning that we can target a small process or larger process. There is no limit on the size of job you are doing. Also we have tried to design the designer to where anyone can sit down and use it regardless of their background. If you wanted to do some code behind or scripting then you would need to know .NET.

>That's actually pretty easy to do with
>an HTML/SVG/Javascript based system. You
>can add as many "onclick" event handlers
>to a button as you want. I'm not sure
>how that would work with a Silverlight
>based system though (which is what
>Status Vision is).

Status Vision Designer can create projects for both Windows or web Solutions. And you can have the button do as many things as you want with the onclick even in both windows and Silverlight.

Another thing that Status can do is that it is not tied down to OPC, so we can extend or have the customer extend the software to talk with any protocol that you are using.

Thanks again for all the comments.

J

James Ingraham

Me: "1) Flexibility."

M Griffin: "That's actually pretty easy to do with an HTML/SVG/Javascript based system."

Fair enough. Of course, I'm only aware of one such system.

M Griffin: "Do you have some actual use cases for this that you would like to describe?"

Sure. I just did a project where the main screen had a layout of conveyors. Whenever a drive faulted, it would turn red. The obvious thing to do would be to click on that conveyor and go to a screen that shows the diagnostics for that drive. I had such a diagnostic screen. However, in PVP / FTView ME there is no way to go both set a tag and then call a screen. I could make the screen pop up, but it would be showing the diagnostics for whichever drive had last been selected through buttons on the diagnostics screen. There's a startup macro feature, but it can't know which button was pressed. The way this screen was designed, the PLC moved the data from whichever drive was selected to one set of tags that were displayed on the diagnostics page. Instead, I could have used a parameter file and had the screen use the parameters passed in. But that would have meant (a) creating 30 different parameter files for the 30 drives, (b) when you selected the drive you want from the diagnostics screen itself you have to close the screen and re-open with the new parameter file, causing a screen "flash" that's annoying, and (c) albeit minor, parameters don't work in preview mode so you have to run the whole project to test that one screen.

Another example. This same project had a display for editing recipes. In FTView ME, when you have a numeric input you can set an "Enter" tag. Whenever I see the "Enter" tag go high, I latch a "Need to Save" bit, and when that's on I start flashing the save button. If, however, you have some yes/no tags to be set with buttons, you can't set both the tag and a "Need to Save" signal. There is a macro button in FTView ME, which gets around the problem. However, it introduces a new one. When I put a Yes / No selection on a screen, I actually put both a Yes and No button, and whichever is selected turns green. Well, you can't change the color of a macro button in FTView ME. So now you have to add an additional widget that looks like the macro button but colored green, and hide the macro button in the right state, and layer them on top of each other, for both states. Big pain.

Me: "Have the button look different depending on tag states that aren't necessarily the same tags that the button operates on."

M Griffin: "There's no reason why that should be difficult to do. There's no reason why a click event handler should have to write to the same tag as is used for display update, and there are many reasons why it shouldn't do so."

I agree completely, but there you have it. In FTView ME, the state of the button only depends on either it pressed / not pressed state or in the case of Interlocked pushbuttons the state of the tag the button writes to. Note that RSView32 and InTouch don't have this problem.

M Griffin: "You've just hit on the biggest problem... If you have decided on using AB ... you're not going to communicate with anything else without a lot of effort and expense. There isn't much that a third party software vendor can do to fix that."

InTouch manages to have a direct driver to A-B. With EtherNet/IP, it should be possible for anyone to talk straight to Logix CPUs. Not that EhterNet/IP is particularly easy to implement, but it's not THAT hard. So while I agree that there's a kernel of truth to your statement (no ProfiNet for example) I don't think it's quite as bad as you make it out to be, or quite as bad as it used to be.

M Griffin: "The funny thing is that the OPC side of an OPC server is usually a *lot* more complicated than most of the actual industrial protocols they connect to."

That is funny, isn't it? And despite OPC's openness, it's pretty rare to see OPC stuff for OSes other than Windows.

M Griffin: "When the HMI software can simply talk the actual industrial protocol directly then the whole system is drastically simplified."

Agreed. Again, InTouch manages this for a lot of different devices. Rockwell does it only for their own stuff. Not sure about any of the other HMI packages.

M Griffin: "...whether or not the HMI software is relatively self contained so you don't have a lot of components to install, configure, and maintain... If on the other hand you have just a few PLCs and operator panels, then what you want is something simple that is easy to install and maintain. Load capacity requirements in this case are negligible and the software package can be designed to be self contained."

Even if the software itself is one nice little application (or how about just an executable with no install?) you still have to administer the machine. You've got to keep patches up to date and possibly lock down features. This is true regardless of OS. And there's still a big fight between IT and operations as to who is responsible for that machine.

M Griffin: "As far as hardware goes, I think the current tablet / iPad craze is going to have big impact on the small HMI market..."

I can only hope.

Me: "4) Ease of use."

M Griffin: "There can be a conflict between "ease of use" and "do things the way I want it to".

True enough. But consider my macro button example above. There's a way to do things, but it's a royal pain. Compare that to other HMI packages that have a Color Animation attribute for buttons. And even though InTouch has buttons we decided they sucked so bad we'd make our own. Or consider the direct tag addressing that FTView ME uses when talking to A-B PLCs, vs. having to have an HMI tag mapped to a PLC tag, and when your screen doesn't work right you have to check that you're looking at the right tag on the screen and then check that the HMI tag is set up correctly, and then check that the HMI software is communicating with the OPC server. So while I agree that the trade off of flexibility and ease of use can be a fine line to manage there are nonetheless things that can be done that are clear winners.

Me: "5) Name recognition."

M Griffin: "If the package cost a lot of money, then the customer wants to know that they won't be left with an orphan if the company goes out of business. If it's cheap (or free), then that doesn't tend to be a problem."

You'd be surprised. Most of my customers will happily pay through the nose to get something that says "A-B" on it, regardless of alternatives. This is true in lots of places. Look at MS Office vs. OpenOffice.org, or Outlook vs. Thunderbird, or Windows vs. Linux. Okay, all Microsoft stuff. How about AutoDesk? You can get DoubleCAD XT, SolidEdge 2D Drafting, or DraftSight for free. Alibre is half the price of AutoCAD LT, and it actually competes with the even pricier Inventor. None of these, incidentally, directly support SVG import or export. We're stuck with AutoCAD / DWG.

Well, THAT was long winded. Sorry. Hopefully somebody will get SOMETHING useful out of this exchange.

-James Ingraham
Sage Automation, Inc.

C

curt wuollet

M Griffin: "The funny thing is that the OPC side of an OPC server is usually a *lot* more complicated than most of the actual industrial protocols they connect to."

James: "That is funny, isn't it? And despite OPC's openness, it's pretty rare to see OPC stuff for OSes other than Windows."

That reminds me of the end of the summer when I was off from teaching. I was driving between locales on some moving errands, exploring a N/S highway that went from nowhere to nowhere. I saw an old white haired guy hunched over in the ditch. I thought he might be sick or hurt, so I stopped where there was a shoulder and walked over to where he was. It was hot and there was an overpowering stench like something dead, but when I got close, I saw that he was moving. He had a big bag full of aluminum cans and he was skinning a big doe that was roadkill. I asked what he was doing, making conversation, even though it was obvious. He straightened up and bummed a smoke. He said "That hide, salted and dried, will buy me food and some smokes, more than all the cans I find in a week". "And the d*mn fools just leave it lay 'cause it ain't worth nothing with that stinking carcass attached." I gave him the pack and walked back to the car pondering the wisdom there. OPC might be a good thing if we could separate the two. But what a job.

Regards
cww

M

M Griffin

>Sure. I just did a project where the main screen had a layout of conveyors.
>Whenever a drive faulted, it would turn red. The obvious thing to do would be
>to click on that conveyor and go to a screen that shows the diagnostics for
>that drive.

I guess then there's a need for a stock button that both selects a screen and writes to the PLC/controller then? That's now on my to-do list.

>Another example. This same project had a display for editing recipes.

I think that what this example really means is that a simple recipe manager should be part of an HMI system. You shouldn't *have* to be writing recipe systems using buttons and indicators. It should be a higher level function that you just call and use after configuring the recipe elements and memory locations.

>InTouch manages to have a direct driver to A-B. With EtherNet/IP, it should be
>possible for anyone to talk straight to Logix CPUs. Not that EhterNet/IP is
>particularly easy to implement, but it's not THAT hard.

The problem isn't technical. The problem is that AB claims you have to license it from them and they impose some very onerous terms and conditions which extend well beyond just a matter of cost. That's a show stopper for many people. It's not like Modbus/TCP where they just say "here's the spec - have at it".

>And despite OPC's openness, it's pretty rare to see
>OPC stuff for OSes other than Windows.

Well, classical OPC is completely designed around MS Windows (MS "OLE" is the "O" in "OPC"). To use OPC on any other OS you would have to duplicate a good part of MS Windows. That's been done, but I can't say I have much confidence in the reliability of the emulation. The new version of OPC has dropped COM/DCOM and I believe now uses something based on SOAP (another mistake in my opinion), but I haven't seen it used much. It supposedly is no longer tied to MS Windows. Software on other operating systems tends to either use package specific extension mechanisms or to simply put the protocol directly in the software (I've done both, as there are pros and cons to each method). These days there's only a handful of protocols that really matter. The only reason to want to support Ethernet/IP is if you are writing an HMI or SCADA system that will talk to AB PLCs, and as you can imagine AB would rather have as much of that market for themselves as possible.

>Even if the software itself is one nice little application (or how about just an
>executable with no install?) you still have to administer the machine. You've
>got to keep patches up to date and possibly lock down features.

Since this thread is talking about an HMI that will run on some sort of computer, we can take that as given. On top of that you have to look at what the HMI system itself requires. If there are a lot of additional components then there are a lot of additional patches, features, and configurations to worry about. If all you want is an HMI panel for your PLC and the software vendor shows you a system diagram that's got more lines and boxes on it than your corporate data centre, then you know that is a product to avoid. If on the other hand you need to scale up to the size of that mine in Australia that everyone used to be so fond of talking about, then you need something more complex to spread the load and provide redundancy.

> "5) Name recognition."

>Most of my customers will happily pay through the
>nose to get something that says "A-B" on it, regardless of alternatives. This is
>true in lots of places. Look at MS Office vs. OpenOffice.org, or Outlook
>vs. Thunderbird, or Windows vs. Linux. Okay, all Microsoft stuff. How about
>AutoDesk? You can get DoubleCAD XT, SolidEdge 2D Drafting, or DraftSight for
>free. Alibre is half the price of AutoCAD LT, and it actually competes
>with the even pricier Inventor.

Most of your examples are simply cases of proprietary file format vendor lock-in. Why do people use AutoCAD? Because everyone else does and you need to be able to open and save their files. The same goes for MS Office. And why do you use MS Windows? Because you need it to run MS Office and AutoCAD. Microsoft uses a similar business strategy to AB and Siemens. All their stuff (usually) works with their other stuff, but it doesn't work with anyone else's unless they need it to fill in a gap with something they don't have themselves. Once they've got their foot in the door they have a pretty good chance of sewing up your business for everything else you need.

With Outlook vs. Thunderbird you're comparing apples to oranges. Thunderbird is a standard SMTP/POP Internet mail client while Outlook is just the front end for Exchange which is a proprietary mail/calendaring system that happens to also have an Internet mail gateway. The closest comparable system to Exchange is Domino which is from IBM, whom I assure you don't have any name brand recognition problems. Corporate mail systems and Internet mail systems are two completely separate things. As for why so many businesses use Exchange, well Exchange is closely tied into Active Directory which is closely tied into MS Windows - does this start to sound familiar?

Large Internet mail systems mainly use open source mail servers which few people outside of that business have ever heard of. For them economics and performance matter above all else, so they make it their business to find and use the best software there is no matter whose name is on it.

To go back to your AB name example, yes there are people who will buy anything that says "AB" on it just like there are people who will buy anything that says "Apple" on it. Most people aren't rabid fans however, they're just risk adverse. If the choice is between a $2000 package from AB and a$2000 package from somebody they've never heard of, then they'll pick AB. They'll worry that the "nobody" company will go out of business and the package will turn out to have bugs that never get fixed and they'll be left holding the bag after the original integrator has long since gone on to his next project. You have to offer the customer some genuine reward for the risk, which means either the cost is significantly lower, or the AB version is missing some functionality that he actually needs while the other one has it.

The HMI market is pretty mature and there are already lots of products on the market that will do the job just fine. To make an impact you've either got to be a lot cheaper or you've got to offer some genuine advantage over everything else. And by "genuine advantage" I don't mean "we've got some lovely buzzwords here". I mean it has to do something that the customer has always wanted to do with their control system but has not been able to up to this point.

J

James Ingraham

I agree with just about everything in M Griffin's post. I particularly agree with this gem:

"The HMI market is pretty mature and there are already lots of products on the market that will do the job just fine. To make an impact you've either got to be a lot cheaper or you've got to offer some genuine advantage over everything else. And by "genuine advantage" I don't mean "we've got some lovely buzzwords here". I mean it has to do something that the customer has always wanted to do with their control system but has not been able to up to this point."

In fact, this is true of a lot different classes of products. I feel this way about most of the sensors, safety products, motors, drives, servos, communication protocols, circuit protection, etc., etc., etc. I have recommended numerous times on Control.com to make choices based on relationships with vendors and customers rather than on technical details. It is, for better or worse, one reason we stick with Allen-Bradley. We have it, we know it, our customers like it, and it does what we need. Getting us to move to another platform would require something REALLY special.

Of course, I'd love to see something really special. Cut my development time in half? Yes, please! But I haven't seen anything truly revolutionary yet.

-James Ingraham
Sage Automation, Inc.

M

M Griffin

In reply to Curt Wuollet: OPC tries to be a "universal driver interface". This has advantages and disadvantages. The advantage is that you have a good choice of protocol drivers. The disadvantage is that it has to include everything plus the kitchen sink so far as features are concerned, which makes it more complicated than most people need.

There's really two different markets for protocol drivers - assembly line manufacturing, and process industries. For the former you want something simple with low overhead and fast scanning rates. With the latter you want a lot of features, lots of shared I/O, but relatively slow scan rates. OPC originated in the SCADA market and so was designed around criteria that mattered to it.

There is something called DBPC based around DBus which is attempting to provide (it's still under development) a similar capability to OPC and provides a lot of the same features. At the other end of the scale there is also something called RLib (PVBrowser uses this), which just does the basic generic I/O scanning.

If we step away from the high level view and focus on practical applications though, then the "universal solution" starts to look a bit less attractive. I will just look at factory automation as that's what I am most familiar with, and leave SCADA systems aside.

1) Making something "universal" adds a lot of complexity from the user's point of view. You have to deal with the application's view of the data (e.g. a PLC data table), translate that to OPC (or equivalent) tags, and then further translate that to the field device's view of things. It's easy to get confused with all those levels of indirection.

2) You add a lot of overhead when programs have to communicate with each other for data. If you have a soft logic system then what you want to do is to move the data between your I/O scanning system and your logic engine as efficiently as possible. Adding an extra step which involves a lot of interprocess handshaking and data conversion can be a serious bottleneck. That isn't a problem if you are getting your data through RS-232, as you are just sipping data through a straw. If your connection is now through Ethernet, then the data is potentially coming through what amounts to a fire hose.

3) Running the I/O scan from a separate program than the actual user application means the two are not very well integrated. There are "gaps" between them that can make troubleshooting anywhere from stressful to impossible.

So, when you look at these two considerations the ideal solution would seem to be to just put the protocol driver directly in your program and have your program deal with the data in its original form. However, that's got two problems of its own.

A) That works fine for two or three protocols. It doesn't scale up very well to dozens however.

B) The protocol data models don't always line up. Consider for example Modbus and SBus, which conceptually are very similar. However, while Modbus has coils, discrete inputs, 16 bit holding registers, and 16 bit input registers, SBus has inputs, outputs, flags, and 32 bit registers. So now your have to figure out how to map one concept to the other (although you still have to deal with this problem with OPC, you're just doing it in a different place there).

So, a reasonable compromise would seem to be to support a few protocols natively and then have an extension mechanism to allow adding more.

You also have to consider what your goals are. If you want to write an HMI application that will talk to lots of different PLCs of various vintages, you have to support a lot of protocols. Realistically though, just a handful will cover most of the market.

On the other hand if your goal is to write software that will be used *instead of* a PLC, then you really only need a very few protocols. You need an I/O solution and it would be silly to target anything other than Modbus/TCP for that because it has such a wide selection of hardware from a variety of vendors. Most PLCs only support one or two protocols so if you can do better that that you are ahead of the game there.

C

curt wuollet

Hi Michael

> In reply to Curt Wuollet: OPC tries to be a "universal driver interface". This has advantages and disadvantages. The advantage is that you have a good choice of protocol drivers. The disadvantage is that it has to include everything plus the kitchen sink so far as features are concerned, which makes it more complicated than most people need. <

To my way of thinking, it's a horrible kludge bandaided on to avoid getting close to and actually fixing the real problem, which is way too many other horrible kludges. I understand the data diversity problem, and the universal argument. I submit that they simply went the wrong direction.

Everything we are doing and expressing and sending and receiving on our computers ends up as a very small set of very well understood protocols. The meaning is largely conveyed by public and published standards. This seems to be working fairly well for the vast diversity that is the Internet There seems to be way to send and interpret nearly anything, most vastly more complex than the small universe of automation needs. It works on standards. Pardon me for being a bit hyperbolic here, but the object crowd tells us the right way is to send one bit of switch data and a whole bleeping manual to tell us what it means, simply to avoid standardizing and keep their miraculously clever sequencing of bits secret. And add several layers of secret and poorly understood software to do it, and installing a tollbooth along the way. Not to mention tying an odious albatross in the middle of your network cable to do so. Perhaps I was mistaken before, OPC would still smell even if we managed to peel it from the rotting carcass. Or do I misunderstand? :^) That could happen, I'm a firewood guy, not an automation guy at the moment.

Regards
cww

P

pvbrowser

The goal of our software http://pvbrowser.org was to provide a solution that is strict client/server. The whole logic is located in the server. The client is a "simple" browser which does not have to be modified.

- client/server architecture
- use separate daemons for different protocols
- use shared memory and mailboxes to connect these daemons with the visualization
- provide a library for different protocols
- provide daemons (based on the above library or a foreign library) that are only configured by an ini file.
- generate/maintain the server by an IDE
- user only codes "slotFunctions" that handle events
- use high level programming language (C/C++ or Python)

S

Steve Myres

Curt,

Get a PLC on that splitter, man. It's like butter, everything's better with a PLC! ;-)

M

mgriffin2

In reply to curt wuollet: I think there is a need for something that does what OPC does in large scale SCADA applications where you are collecting data from potentially hundreds or thousands of independent sources. You can have a data server which runs independently of the actual SCADA functions and which handles just the polling and data conversion. You could even have multiple data servers if the load was high enough or you needed redundancy. However, that doesn't necessarily mean that I think that anything called OPC will necessarily continue to exist. I'll get back to this point later.

If you want to see the sort of issues that OPC tries to deal with, the best source of information that I've seen is this web site:
http://www.freedesktop.org/wiki/Specifications/DBPC
That is a spec by someone who is trying to create an OPC equivalent based on DBus. You can see that the sort of things that he is worried about is when to refresh a tag (e.g. "on demand"), how long a data point should be cached, etc.

In typical factory automation applications you just have a much smaller number of I/O, but you want to repeat your polling operations quickly with minimal overhead. That is, you want to get the data from your inputs into your control logic and back out to your outputs with minimal overhead. You may not have thousands of points, but for what data you do have you want to update all of it continuously. That means for factory automation tasks, what you really want is a simple but consistent driver API. Most protocols are not really *that* difficult. Dealing with RS-232 or RS-485 timing and handshaking can be hard, but Ethernet removes most of that difficulty so long as it's a simple client/server protocol (which most are).

The big problem has been the sheer number of different protocols. However, it seems that with each generation of systems that number is getting whittled down to fewer and fewer. Once it gets down to a small enough number of significant ones then the justification for having OPC even for SCADA more or less disappears. At that point, it becomes worth while even for SCADA vendors to just build their own data server with the protocols directly in it. Then they can design the data server to work better with their SCADA system and a lot of software design problems disappear. At that point SCADA vendors will be asking themselves why all that money that gets spent on OPC servers doesn't go into their own pockets instead of someone else's.

In the long run I think that for factory automation AB will have their protocol, Siemens will have their's, and everyone else will coalesce around something else (possibly Modbus/TCP, or an evolutionary development of it).

C

curt wuollet

I tried that Steve, and it didn't work out very well. Maybe if I was using one of those hydraulic splitters instead of a maul......

Regards
cww

C

curt wuollet

Hi Michael

> In reply to curt wuollet: I think there is a need for something that does what OPC does in large scale SCADA applications where you are collecting data from potentially hundreds or thousands of independent sources. You can have a data server which runs independently of the actual SCADA functions and which handles just the polling and data conversion. You could even have multiple data servers if the load was high enough or you needed redundancy. However, that doesn't necessarily mean that I think that anything called OPC will necessarily continue to exist. I'll get back to this point later. <

The problem I see is everyone making up their own dataset, it just gets bigger and bigger and more incompatible and unmanageable. OPC is one of the agents that allows this.

> If you want to see the sort of issues that OPC tries to deal with, the best source of information that I've seen is this web site:
http://www.freedesktop.org/wiki/Specifications/DBPC
That is a spec by someone who is trying to create an OPC equivalent based on DBus. You can see that the sort of things that he is worried about is when to refresh a tag (e.g. "on demand"), how long a data point should be cached, etc. <

I confess that I have not delved the depths, mostly because an MS only solution
seems to be a bad idea from the getgo. Putting more detail back in the
application would ease the issues and make a simpler more universal go between
feasible. As would be any two entities actually trying to do things the same way.

> In typical factory automation applications you just have a much smaller number of I/O, but you want to repeat your polling operations quickly with minimal overhead. That is, you want to get the data from your inputs into your control logic and back out to your outputs with minimal overhead. You may not have thousands of points, but for what data you do have you want to update all of it continuously. That means for factory automation tasks, what you really want is a simple but consistent driver API. Most protocols are not really *that* difficult. Dealing with RS-232 or RS-485 timing and handshaking can be hard, but Ethernet removes most of that difficulty so long as it's a simple client/server protocol (which most are). <

Yes, they are separate worlds but both would benefit greatly from standardization rather than expanding the rat's nest.

> The big problem has been the sheer number of different protocols. However, it seems that with each generation of systems that number is getting whittled down to fewer and fewer. Once it gets down to a small enough number of significant ones then the justification for having OPC even for SCADA more or less disappears. At that point, it becomes worth while even for SCADA vendors to just build their own data server with the protocols directly in it. Then they can design the data server to work better with their SCADA system and a lot of software design problems disappear. At that point SCADA vendors will be asking themselves why all that money that gets spent on OPC servers doesn't go into their own pockets instead of someone else's. <

Unfortunately, while that is a good trend, it's still too many for the type of transparent, ubiquitous networking that would become a non-issue. And I have a hard time seeing the upside of all that fragmentation, even from the perspective of the perpetrators. That is, I don't think it would stand business analysis that it makes money over adopting a common standard if one existed. OPC is an example in this regard. Everyone + dog holds their nose and uses it because despite the roadkill attached, it is a standard, in an arena that apparently needs a dictator to standardize. As commoditization proceeds, (and it will, this stuff is simply not that exotic) roll your own will make even less sense. As I've said before, what is needed is some truly independent mover to end the madness. The cost savings could be enormous for everyone involved. Maybe when China Inc. steps up the cost pressure or we get some weed out some other way:^)

Given the outlook for manufacturing in the "first world", the majors could become irrelevant if they ignore the trends.

> In the long run I think that for factory automation AB will have their protocol, Siemens will have theirs, and everyone else will coalesce around something else (possibly Modbus/TCP, or an evolutionary development of it). <

For a while perhaps.

Regards
cww

S

Steve Myres

Oh yeah, if you want to improve a maul with a PLC, you need one of those metal behemoths from the 70's cause in that case you judge by mass!

P

pvbrowser

> In the long run I think that for factory automation AB will have their protocol, Siemens will have theirs, and everyone else will coalesce around something else (possibly Modbus/TCP, or an evolutionary development of it). <
>
>For a while perhaps.

I think the above protocols will remain.
The future might be OPC UA where the server is integrated within the PLC. OPC XML-DA is easy but the binary protocol is not that open.

T

Tallak Tveide

Given the amount of flack that OPC gets in this thread I would be surprised if a scada based on silverlight gets a lot of attention, especially in this crowd. OPC suffers from being based on dcom, which is a deprecated MS technology. Why start with a new HMI based on silverlight which is now officially dead (according to MS official future plans), and is tightly coupled to windows (troubled by malware and instability) and hoards of MS proprietary standards (XAML etc). And on top of it all i guess you'll require the hated internet explorer to access it

Don't get me wrong - it probably makes sense to a lot of people (which is why we're struggling with OPC at the moment), and for all I know you might sell shitloads, but for me this whole thing is all wrong

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

So to answer the original question

- based on open standards
- scripting in ruby, javascript or python (or all)
- licensing that doesn't restrict the number of terminals
- client server
- not having to deal with a mess of taglists etc
- of course super stability
- not tied to any operating system
- a good system for collecting data

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...