Control.com - Nerds in Control

I have to select an HMI package. Which should I select? Iconics, Wonderware, Citect, Intellution?

John

Is Ford better than Chevy or Chrysler? This will give you opinions but may not be the right answer for your solution.

Things you need to look at are what features are you after; Will these be simple HMI applications?
Do you need to integrate with historian packages or to a higher level management system?
Is redundancy required?
What PLC or controllers are you connecting with, and what networks?

Are there local distributors and integrators that you are able to access? What do other industries nearby use and are they happy with the local distributor and support?

There are a lot of 'pros and cons' with any package, it means you need to filter them out and work out your priorities. If you have minimal experience or exposure then training course are also in there as a priority.

All these packages are reputable which will make it a bit harder decision.

Regards,
Trevor

I have used Iconics and Citect before. I personally like Iconics better, theres a bit of a learning curve, but every software has that curve. The best part about Iconics is being able to change things on the fly even if your already running the application. If you are in the maryland area I can show you both products.

Crappy software, stupid tech support and bizarre programming has always been a high priority with Iconics. You'd have to nail me to the wall to show me different. I'll stick to Wonderware. It's easier, well thought out and I almost never need to request support. If I use Iconics, I should allow for at least 6 months of 'seminars' to fully understand their product. Yup... That's what I'll do... Sure.

I fully agree with Bob Wolff. Iconics is difficult to use. No memory tags available. A temp tag used in 1 window cannot link to other windows. I was told by the tech support to use the simulator OPC tags come with iconic to overcome this problem. Example, a simple calculation "count = count + 1". VBA script is required. If you decide to use some function from VB, VB6 need to be installed. Additional cost $$$. More problem came after your completion of project. When deployed to another PC without VB6, some scripts cannot run. Then I was told to install and uninstall VB6 while iconic is put to run. While uninstalling VB6 some files used by iconics was not able to delete. A pop up box appear. I was told to click on the ignore button until VB6 is fully uninstall. In this case, the file used by iconic is still intact while not violating the IP law. Isn't it silly. I was using Ver7 at that time. Not sure if the latest version has solved all these problems.

As for the memory tags needing scripts, you are incorrect. You can do a simple Tag = Tag + X right in the dynamic. I always use PLC tags for static variable shared between screens. PLC is more realiable than any PC...

It is not correct that you need to script memory/global tags. You can use the DataWorX32 global registers for this. Also most OPC servers (for example, Kepware) have the ability to have global persistent items, which are not connected to any device. Remember, Iconics' only communications server is the OPC server it is connected too. This makes it very fast in OPC/Device communications, but also puts requirements on the OPC server you use.

You can also use the Iconics Dataminer for global persistent variables. This is personally my favourite. As through a GUI interface, you can create and use (i.e. read/write too) global registers in a custom made database as e.g. Access or MS SQL. Very nice!

VBA, VBScript and JScript is very well intergrated into Iconics now. There is ScriptWorX32 (or ScriptWorX 2006) for global scripting. And locally in the graphical editor (GraphWorX32) it supports scripting for configuration mode and runtime mode. This means you can program code to run in runtime, e.g. change a value, or write something to a file. BUT also automate your graphical configuration. E.g. insert a simple rectangle object with VBA configuration coded to it, on a double click event fill out a form, and it creates a stack of graphics with parameter setup from the form info and your VBA code.

Very Nice!

Once again this comes down to personal preference. I read the ICONICS bashing posts above and wonder how much time they have really spent in ICONICS products and how much time they have spent in WW products. I'll bet WW was the product they used the most, not becuase it was better than anything else out there but becuase they know how to use it.

It's very easy to pick out things in each system that I don't like (ICONICS's licensing scheme, WW's lack of a true thin client, iFix's heavy reliance on VBA, etc...). All products will have some things you like and some things you don't.

My presonal preference is Citect, but I also have experience with ICONICS, WW and iFix. Given the choice between the 4 you listed, I would go with Citect becuase it is what I know.

JFB

> Crappy software, stupid tech support and bizarre programming has always been a high priority with Iconics. <

It's always easy to confict a supplier of SCADA software if you are playing in the garden of the neighbours. Wonderware, WinCC and ... are also good products we use it our selves and we use a lot of Iconics. But remember the resons selecting a product are also Viability, TCO, Exit Costs, Guaranty and Fit for Use.
So what I would like to say, there is no best or worst product if you do not know the selection criteria.

With Regards Ronald

Hi John,

Where are you located?

Hi, all!

Help me, please!

Do you have login to http://www.iconics.com?
I need to access knowledge base and documentation Genesis32 SCADA ver 9.

Alex
ICQ 216060501

If you have a Genesis system, your Iconics rep or system integrator should be able to get you in. If not, you should be contacting Iconics directly. All you need to do to access the secure documentation is to obtain a login from Iconics.

If you have a legitimately obtained Genesis32 SCADA ver 9, this should not be a problem.

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
wboyes@putman.net

Iconics has it disadvantage over it well protected license. Although a newly installed PC is given a 30 days trial period, it cannot be reused again even you have uninstalled and installed the software. This causes a very serious problem. Imagine if the USB license key was not detected by the PC due to some reason. The entire plant will be down for few day. Although the supplier promise that a new temporary soft license can be issued through a phone call, providing mac address of the PC information. The supplier does not give you an immediate re-trigger of the temp license.

Unlike Wonderware, base on mutual trust. A temporary Soft license can be sent to you via E-mail immediately without any question ask. Installation of License is much easier compare to Iconics.

Iconics will send you a new key as per trust like wonderware, no questions asked...

-rsr

No they won't. My plant is down now because they want us to re-up our support contract before they will help us. With Wonderware you can make a backup copy of the license file to reinstall if the hard drive fails. Then I don't have to waste time on the phone like I have with Iconics. Wonderware truly trusts their customers in my opinion.

SM

SM,

ICONICS does provide 30-day, temporary licenses as mentioned previously. If you need help or your plant is still down please contact me at the number below.

Robert Stanton
Inside Sales Manager
ICONICS Inc
(508) 543-8600
(508) 740-3316 cell

Robert,

I didn't personally reinstall the Genesis32 software. Our ENI tech did install and activate it, but didn't realize it was only 30 days. So it ran out.

Guess it is our problem since we didn't inform him about your software's 30 day of-the-wall license.

From a customers point of view... We bought the license, so why should I have to re-up my support to get a software key I already bought? Also, if we have a standby computer (that is turned off until we need it); why do we have to have a separate license? We are only using one computer/license at a time to run our process. If you didn't know everyone needs backups to their backups.

This is where WonderWare will beat you day-in and day-out.

In manufacturing it is all about uptime, not about how many people can steal someone's software. I would gladly pay 3 times more for software that I didn't have to contact support about for a key code.

We are running now. Thanks for your concern.

SM

From a customer's perspective it's good that WW support would give you the benefit of the doubt. That's important with running industrial software where time is money. I'd like to think that all the major vendors are supportive for this type of application - even though it was on you, the customer, for losing your key without a backup, then using on a borrowed/trial key for 30 days without getting yours back, then coming back to the vendor with the time crunch.

As to the comment about it being about uptime not software piracy - sure, but give me a break. Iconics bent over backward to get you support and you didn't take advantage of it. Then they helped you out of your self created tough situation. Vendors offer various combinations of keys, backup/restore methods, hardware keys, free trials, and other options.

As to paying 3 times more for software where you'd have the key - I get the point, but again, give me a break. That comes up time and time again after someone's been burnt. You could have paid 3 times the price - 3 Keys would have been more than sufficient. Or you could have paid a little extra for their support contract. Or you could have Ghosted the hard drive.

I feel your frustration and think that top notch support is important, but you have to draw the line somewhere. Blaming the vendor seems pretty harsh in this case.

I'm glad you're back running.

----
Nathan Boeger
http://www.inductiveautomation.com
Total SCADA Freedom

Nathan

Maybe I didn't provide enough info. We didn't lose the key. The hard drive failed so we needed a new key. Iconics is a real picky software and if you change anything your SOL.

I do admit 30 days should be enough, but it wasn't.

We ghosted the hard drive.....we even did Norton Livestate (or Backup Recovery as it is named now). The Iconics software looks at everything. It must look at the motherboard or other hardware serial numbers. It has never came up working for us from a backup. If you change any hardware you have to call.

So it is not as easy as you think. It is worse than winXP activation.

We did pay for their support for years. We let it slip this past year.

Wonderware's support could be canceled tomorrow and I could still run the plant because Their backup licenses actually run. Once again, I must say they trust their customers

How did ICONICS help me out? They made me pay support for software I already owned. Imagine if Bill gates charged you support everytime you had to re-install WindowsXP on a failed PC or if you changed the memory in it.

Blaming the vendor is really honest in this case.

You have to admit, We did paid support for software we already legally owned and didn't need support on.

In reply to SM: I don't have an opinion on Iconics versus Wonderware, but I can confirm that some software copy protection systems (and not just MS Windows) do look at hardware serial numbers. They typically look at serial numbers in motherboards, hard drives, video cards, and network interfaces. Some schemes don't allow any change at all, while others allow one or two changes. You can't image the drive and restore it on another one, because that's more or less what the copy protection system is trying to prevent.

As for the copy protection scheme in MS Windows, the new scheme used by MS-Windows Vista is much more strict than that used by MS-Windows XP. People are having problems even when they don't update any hardware. Even things like driver updates can trigger a system lock-out. You also have to keep re-validating the software every few months. The real pirates of course have already cracked the system, so it's mainly the honest customers who are having problems.

If you are using copy protected software for any essential function, you need to have a plan for recovering from lock-outs caused by the copy protection system. You might think of it as being another point of failure, just like a hard drive crash.

Thanks Michael for your post. I agree about having a backup plan. My point, if a software company wants to have a strict copyright protection plan... then offer 24/7 support.

I have called Microsoft at 3am in the morning for my home computer and got an Activation code for winXP. I didn't have to pay for their support either.

I never have to call Microsoft at my plant, we have a Multi-volume license. We paid next to nothing for the MVL.

My point ...Iconics has always been hesitant and slow about giving us a key over the years.

Just trying to give some insight on what others might face with them. Iconics has cost my plant a good amount of money. So, as soon as we can, we will convert it to Wonderware. I can assure everyone that.

SM

In reply to SM: With regards to "Multi-volume license" for MS Windows XP, I assume that refers to a form of what most people called the "corporate license". That is all changing with MS Windows Vista. You will have to network the plant PCs to a special license server in your plant, or connect them via the internet to Microsoft's license server.

Each PC then "phones home" to Microsoft on a regular basis (every few months) to get continued permission to keep running. If it can't reach the license server within a specified period of time, MS Windows Vista goes into a "limited functionality" mode which only enables enough features for you to contact Microsoft to re-activate the license for that PC.

Most people are hooking up to the internet every day, so they won't be aware of their PC "phoning home" to get permission to run. Things can be a bit different for a PC used in a plant though.

Right now there's still a hole in the system provided you use the MS Windows Vista version installed by certain PC OEMs on those OEM PCs (i.e. don't replace it with your bulk license). This was a special feature provided to those PC OEMs by Microsoft with great reluctance. It has been widely reported though that Microsoft wants to discontinue that feature and force everyone to go through the activation/re-activation process in order to close an activation loop hole (which people are taking advantage of by re-flashing their BIOS with OEM codes).

In other words, your software situation is about to get a lot more complicated over the next few years. Don't extrapolate your experiences with XP to Vista.

I can't help you with MMI systems. I agree though that copy protection and license activation methods are important evaluation criteria when selecting software. Those features are not put in there to make your life easier.

In Reply to SM: Why Wonderware?? Citect's support is also 24/7 and SCP certified. Hardware dongles too... Any reason as to the preference?

Nathan Slider (CCE v6)
Citect

That's unfortunate. It's bad when a vendor won't give you, the customer, immediate support in cases like that.

I understand the need for copy protection, but their licensing scheme does seem out of line. If it's that strict they should disclose it and give you a legitimate way to do a backup that works. I'm a fan of hardware keys. The new Vista scheme sounds outrageous too - I thought that of XP already. The redeeming factor is that you can call M$ and read 50 character serial numbers back and forth with their outsourced call centers and they'll re-activate you without question.

I totally agree with you in this case. It's amazing how much small customer service things like this can turn you onto or away from a company. I can think of one credit card company that I love and another that I despise largely due to similar minor acts of really good/bad customer service.

----
Nathan Boeger
Inductive Automation
Total SCADA Freedom

SM: You don't say where you are at, but I will assume in the US somewhere... ICONICS will provide you with a 30 day license to get you back up & running if you lost your license. Call them. If you don't know who your person is, email their NA Sales Director, m.hiefner@iconics.com.

I have had good luck with ICONICS. I have worked with most over the years. They all have their plus/minus, many stated in this thread. I have found more plus than minus with ICONICS.

Try contacting them on a holiday or one of their holidays. They have holidays that are a few days out of normal. It isn't 24/7 support like WW.

SM

http://pvbrowser.org
:-)

Why don't you look at a complete solution for your shop floor data collection by evaluating TrakSYS from Parsec? It offers HMI, MES and performance monitoring.

The best package I found is VTS from Trihedral Engineering. Good graphics, works most PLCs, hot backup capabilities... and the best part... it's fairly cheap. Google it!

My friends, I work with InTouch, Panorama, Citect, Fix, Monitor Pro, PCVUE and others and for me … I prefer PCVUE. It’s fast, easy, allow internal bits/registers/strings, changes online and redundancy, OPC client/server. If you want, you can develop the mimics on a different computer in the office and just copy the file to the customer computer, without stop the application, so no data is lost. The graphic interface is powerful and intuitive. There are schedulers, formulas, events, recipes, real 3D mimics (not perspective!!!). If you want an alarm window, just drag the object and resize, select number off lines, font, colors and all alarms will be displayed there. The same to logs, events and trends. The limit? Only the hard disk space and the memory. As I say, PCVUE only don’t make baby’s. ;)

Assuming you have a sophisticated project requiring detailed programming I advise using a dedicated flatpanel computer loaded with vb.net instead of Wonderware or Iconics. Also you will need an OPC server software package to communicate to things such as a PLC (I recomend INGEAR.com). Vb.net is FREE (NO LICENSE). Iconics' License is not reliable when booting up your computer. Sometimes it doesn't find the License and starts a 2 hour demo instead, which means your application will all of the sudden quit in 2 hours, causing pandemonium in your plant (VERY POOR). I have found Iconics to be very much more difficult than Wonderware, but why bother with these two when you can do anything they can do just using Visual Basic.net? Any engineer will be able to help you using vb.net, and you can surf for snippets of any strange code you may need. If you need help using Wonderware or Iconics, good luck.

Why pay them thousands of dollars?

You will find that writing and SUPPORTING a custom application is a far cry from "downloading random snippets of strange code". An good HMI system will save you significantly more money in man-hours than custom programming. As a PLC/HMI guy, you shouldn't need to worry about: data structures, memory leaks, and the like. Of course you could *theoretically* make a better application with a general purpose language. This is rarely the case unless you're big enough to have a full time programming staff (like Walmart).

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com/
Inductive Automation

I hate to say this, jimmy, but what you've said is plain silly. The advantage of buying from Wonderware, Citect, Iconics, Proficy (Intellution's new name), or any of the other SCADA/HMI software vendors is that you DON'T have to write it all yourself.

Now this might not be an advantage to you, personally, since you CAN write it.

But what if you are hit by a bus?

Somebody has to come in and clean up your code. If you buy from a vendor, the code is cleaner, commented, and they stand behind it.

Regarding the Iconics issue, that's a dead horse. Iconics has said repeatedly that that doesn't happen any more, if it ever did. If you have that problem, complaining here isn't the answer anyway. Talking to Iconics is the answer (unless of course, you don't have a licensed software copy-- then you need to PAY for it).

Why pay them thousands of dollars? Why not build your own car, your own TV, your own cell phone?

If you're as good as they are at what they do, by all means write some software, hire some coders, hire some marketers, hire some sales people, hire some managers, hire some tech support people, and compete with them.

That all costs money, and reasonable profit aside, that's what you are paying for.

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
wboyes@putman.net

As time goes by, this position makes less and less sense in a larger installation. I agree, if you have a small plant without support, then go for the license.

But as automation moves towards more and more centralized control, with more and more involvement with IT and the enterprise business systems, the customization required is beginning to overshadow the advantage to purchasing canned packages. Would I recommend a customer "roll their own" for a two node conveyor system? Not on your life.

But for a system where 6 production lines in one plant and 3 production lines in another plant all have to drop information on the desk of the VP Manufacturing at a headquarters building in a third city, and the IT guys (who really do have development skill) are in the thick of it, the canned packages just get in the way often times.

10 years ago it was cut and dried. 5 years ago it was starting to look cloudy. Today, you really have to evaluate on a case by case basis. The shrinkwrap vendors are working their butts of to stop this trend, and they might succeed and come out with packages that are cut and dried again, but they'll be on the order of SAP or Oracle Financials, not Quickbooks. In the long run, I really see control systems becoming part of the larger information systems in the future. And anyone who has ever been involved in an ERP roll-out can tell you that there is a ton of customization for every business out there. In 10 years, an automation specilist who doesn't know how to read a data definition is going to be like an auto mechanic who doesn't understand electronic ignition. Or like an automation specilist who didn't want to learn 4-20 ma because he didn't see what was wrong with 3-15 psi.

It's coming. We can either get on the bus, or we can get left behind. That part, at least, is cut and dried.

Michael
--
Michael Batchelor
www.IndustrialInformatics.com

I agree wholeheartedly that the level of customization and integration is expanding, which necessarily shifts away from a "precanned" approach and more closely resembles general purpose programming. This is the approach that Inductive Automation has been taking for the last 4 years. The big guys are making notable efforts in the "enterprise integration" and "distributed" departments.

I disagree that the market model is moving to resemble SAP or Oracle Financials. Companies are reluctant to shell out huge amounts of money for their control software, especially since we're not sitting in a .COM boom. Nobody has yet come out with a successful Quickbooks style rollout, but that's not to say that it isn't possible or won't happen. It is true that there's a lot of resistance to new brands among integrators and end users. I think eventually control software will be commoditized, but it won't be the same crap that you're used to dealing with. It will be flexible, powerful, and easy to integrate into your enterprise.

----
Nathan Boeger
Inductive Automation
"Total SCADA Freedom"

Frankly I do *NOT* think it is possible to do a "quickbooks" style roll out. The variability in manufacturing plants is far more than the differences between the commonly accepted accounting practices used in small accounting systems.

Maybe SAP is to big a generalization on my part, but you are absolutely correct that that control systems are becoming much more like general programming projects. (Let's hope they loose the similarity in the always late and over budget attributes.)

I do think, however, that the days of the canned packages are limited. If the canned packages were the wave of the future, then we would not have seen all of them get bought up into larger umbrellas in the past decade or two. Inductive automation is independent, but where is WW, Factory Link or Intellution.

Maybe the better example is to say that "control packages" of the future will be tools to be subsumed into the IT development environment. The concept of a "control package" with VBA embedded into it will be replaced by the general purpose programming IDE with a control component suite add-in. Think about how companies added "data grid" components to Visual Studio 6.0, and expand on that to become control system components for the Silverlight environment.

It's coming whether we like it or not. We can either get along or get run over.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

Michael,

I agree with your points. I think we're providing two perspectives of mostly similar views.

The "Quickbooks" style thing will NOT work out for pre-canned packages - even in specific industries. This has already proven to fail. Consider works like RS Batch. Fundamentally you're right, there's no "cookie cutter" solution to mass market. However, the part of the "Quickbooks" analogy that I see happening. Standardization and "cookie cuttering" the tricky programmatic aspects is possible - intercommunication, remote access, error handling, a stable platform to run on 24x7, etc. I think general purpose software developers usually don't make efficient industrial application creators, given that they're used to other types of development and not dealing with industrial control. IMO the convergence reinforces the wrench turner's need to be able to put a button on the screen and necessitates the IT guy's need to be able to control remote access to the plant. It may yield a few USB Swiss Army Knife totin' superheros, but I still see the separated specialization. The geek with the debugger and profiler will still be the one hunting out memory leaks. The "team of super-specialists" (SAP approach) gets excessively expensive, especially in terms of maintenance.

The "Future HMI" will certainly have flexibility characteristics of a general purpose IDE, but will necessarily be MUCH SIMPLER. I could see it evolving out of an existing HMI growing in programmability OR a custom version of an IDE that simplifies and specializes for industrial apps.

----
Nathan Boeger, MCSE
http://notanotherindustrialblog.blogger.com

> The "Quickbooks" style thing will NOT work out for pre-canned packages - even in specific industries. This has already proven to fail. Consider works like RS Batch. <

Agreed. For a single machine vendor, who can supply a "standardized" product, there may be something they can offer once it's customized. Consider a curing oven manufacturer. They may deliver 75 ovens a year of a particular type which have 5-10 optional components. I can see how a
product with a template tool like Factory Link uses would allow them to roll out a slick interface that appears "customized" to the end user. However, there's a boatload of engineering that goes into creating that template beforehand. And again, this is more of a tool for someone like
a field installer, not an ERP interface.

I have yet to see an automotive assembly cell that was "standardized" enough to try something like this.

> Standardization and "cookie cuttering" the tricky programmatic aspects is possible - intercommunication, remote access, error handling, a stable platform to run on 24x7, etc. <

In theory, much of this should be handled in the "control libraries" for the IDE add-in components. In practice, it isn't so clean.

> I think general purpose software developers usually don't make efficient industrial application creators, given that they're used to other types of development and not dealing with industrial control. <

I think this will change over time. We will not win the battle with IT so long as shipping production off to a place where it is cheaper to pay labor to so the work than to automate to do the work. We *MUST* necessarily make them into people who understand that keeping the machine running is paramount. I don't care if you think this is a "cross to bear" or an "ax to grind," we have to accept it as our lot. (Jeez, that sounds fatalistic. Note to self: Find a better way to say that to a CIO.)

> IMO the convergence reinforces the wrench turner's need to be able to put a button on the screen and necessitates the IT guy's need to be able to control remote access to the plant. <

One of our standard internal admonishments of the past few years has been that with a properly designed and implemented troubleshooting system on the interface, there is no for the wrench turner to ever put a button on the screen. Unfortunately, this is a lot harder to pull off on a one-off implementation than it is when you're making ten thousand of the same product. It's very difficult to foresee everything that can go wrong with the machine.

> It may yield a few USB Swiss Army Knife totin' superheros <

Yeah, but superheroes always come with a kryptonite heel. Some people love the role, but it's far better if Fred Flintstone can get the machine running again. At least, that's what we should strive for.

> The "Future HMI" will certainly have flexibility characteristics of a general purpose IDE, but will necessarily be MUCH SIMPLER. I could see it evolving out of an existing HMI growing in programmability OR a custom version of an IDE that simplifies and specializes for industrial apps. <

Time will tell what the final result is, but regardless, I'll stand by the line I wrote below. Change is coming. We can either get along or get
run over.
--

Michael Batchelor
www.IndustrialInformatics.com

In reply to Michael Batchelor: I think the market is changing, but it is not so much shifting as diversifying. I think there will always be a demand for small simple MMI packages with limited functionality, but there is also a growing market for production integration into large scale EPR software (e.g. SAP).

If you want a good analogy, consider the relationships between spreadsheets and ERP systems. Most businesses got spreadsheets before they got ERP financial systems, but the ERP hasn't made the spreadsheet obsolete. They both sum up money, but they are used for different purposes.

You speculated about development tools being "subsumed into the IT development environment". If that happens (and it's not unlikely), then these may be implemented as Eclipse plug-ins. Almost all of the large scale proprietary IDE development systems for IT projects that existed at one time have disappeared and been replaced by Eclipse. The vendors just implement their special tools as Eclipse plug-ins which allows you to use whatever combination of tools you need for a project.

I would not be surprised to see complex MMI and SCADA systems follow the same path and become collections of Eclipse plug-ins. This would allow developers to do MMI or SCADA development or ERP integration from within the same IDE and sharing tools between both.

As for embedded VBA going away, it's already gone. VBA is not only officially obsolete, but Microsoft no longer even sells new licenses for it to developers. VBA has been taken out behind the barn, shot, and buried. Anybody who buys a product which depends on it is buying a dead-end product.

Modern ERP and other large scale IT software systems are usually based on Java. An MMI or SCADA system that has aspirations of working closely with ERP systems either needs to be able to share code and libraries with them or else has to reinvent the wheel for every function where they work together. That in turn means that the natural language for these applications is Java, with Javascript for scripting. An MMI/SCADA system that ignores that fact is one that doesn't plan to work well with anything else that matters.

I don't know if this helps anyone trying to decide whether "Iconics (is) better than Wonderware, Citect, Intellution". I do think that people looking at these packages need to step back a bit and ask themselves if they have the full picture. Is the project going to be a stand-alone system, or is there some real prospect of it having to integrate into the business systems? If so, just how will that work? A clunky OPC interface may not be enough. Whatever method is used, I believe that MMI/SCADA systems will have to adapt themselves to the requirements of ERP systems, rather than the other way around.

Michael and Michael,

You both bring up excellent points. My comment about the SAP thing was that there's still software (package/plugin/library/whatever) that automation companies will necessarily provide (as opposed to the idea that general purpose languages alone will create mainstream end user industrial apps).

I'll use FactoryPMI here as an example because it touches on several of your points. FYI, it began life about 5 years ago as a Java IDE, Sun's Bean Builder (although our developers have been using Eclipse the entire time). Several "core" parts necessary were added to make it a usable distributed system: Web server, clustering services, serialization and launch (JWS) support, monitoring/configuration tools, database connection support, user authentication, auditing, etc. These are all things that a user expects to be reasonably "pre-canned" and solid. There are many others that are very useful and make good plugins (graphs, objects, reports, etc.).

There would have to be a substantial plugin set or starting point for the IDE HMI to really take off. (Recall my above post indicated HMIs gaining capability toward IDEs or IDEs getting "dummied down" without loosing too much flexibility). A good Java programmer wielding an Eclipse based HMI with mature industrial plugins could go on to do amazing things. It's my personal opinion that HMI programmers are more on the level of expressions, scripting (FactoryPMI uses Jython - could have easily been JRuby).

In any event, it's hard to contest that SCADA systems ARE getting more complicated and requirements are shifting toward MORE INTEGRATED and distributed systems. And Mike, I couldn't have put it any better:

>MMI/SCADA systems will have to adapt
>themselves to the requirements of ERP
>systems, rather than the other way
>around.

----
Nathan Boeger
http://notanotherindustrialblog.blogger.com

> In reply to Michael Batchelor: I think the market is changing, but it is not
> so much shifting as diversifying. I think there will always be a demand for
> small simple MMI packages with limited functionality, but there is also a
> growing market for production integration into large scale EPR software (e.g.
> SAP). <

OK, I can buy this. Just thinking out loud, perhaps the trap the the previous generation of products has been caught in is to attempt to be
all things to all people. I certainly can see that a small HMI package for production of completely stand alone machines has to remain viable. Although I'm not sure that items like the Automation Direct operator panels won't be what subsumes that market. Witness that WW, Intellution, Think 'n Do, and RSView ME (the only ones I have personal experience with) have tried to crack the "super-duper PanelView" market to varying degrees of success.

> You speculated about development tools being "subsumed into the IT development
> environment". If that happens (and it's not unlikely), then these may be
> implemented as Eclipse plug-ins. <

Well, we can say with absolute certainty that Ol' Bill will be working his butt off to make sure that it isn't Eclipse as the prevalent IDE, but that's a different can of worms, and not really relevant to the discussion of whether the HMI market is metamorphosing into an IT shop tool. Which tool set evolves to fill the niche is irrelevant to the ecological evolution of the niche itself.

> I would not be surprised to see complex MMI and SCADA systems follow the same
> path and become collections of Eclipse plug-ins. This would allow developers
> to do MMI or SCADA development or ERP integration from within the same IDE
> and sharing tools between both. <

And this is exactly the pathway that I see. This is the thinking behind my comment to Nathan's response a few minutes ago that we must necessarily make the IT guys into control guys as well.

> As for embedded VBA going away, it's already gone. VBA is not only officially
> obsolete, but Microsoft no longer even sells new licenses for it to
> developers. VBA has been taken out behind the barn, shot, and buried. Anybody
> who buys a product which depends on it is buying a dead-end product. <

And my comment was a hearty "Good riddance." I always thought it was just enough to be maddening, like starving to death outside an open kitchen window. Not enough tool there to let you really do anything, but enough to let you know that what you wanted to do was possible.

[...]

> I do think that people looking
> at these packages need to step back a bit and ask themselves if they have the
> full picture. Is the project going to be a stand-alone system, or is there
> some real prospect of it having to integrate into the business systems? If
> so, just how will that work? A clunky OPC interface may not be enough.
> Whatever method is used, I believe that MMI/SCADA systems will have to adapt
> themselves to the requirements of ERP systems, rather than the other way
> around. <

These are the questions that I think will precipitate the next wave of fallout in the HMI market. And I believe it is correct that we, not the ERP systems, will be doing the majority of the adapting.

MB

--
Michael Batchelor
www.IndustrialInformatics.com

Couldn't agree with you more, Walt.

----
Nathan Boeger
http://notanotherindustrialblog.blogspot.com
Inductive Automation
"Total SCADA Freedom"

I worked at one semiconductor/flat panel processing equipment manufacturer where I replaced several HMI/PLC packages running their various product lines with a single custom application framework using VB front end, OPC client/servers to I/O or PLCs/custom hardware doing the realtime operations. I cannot speak for the customer/factory side - but from our point of view as an equipment manufacturer we had several problems with the packaged controls systems which we felt required this:

1) We had five product lines and each one had a different control system hardware and software.
2) Each product from those lines could be configured radically differently - in essence each was custom product.
3) None of the control system packages was configurable enough to modify for each variation - i.e we would have had to make a special application for each variation which were nearly infinite.
4) We wanted one architecture framework which could be added to and modified by any of the engineers in the company.

Of course, the development of this product line architecture grew over time - updated, expanded and improved as we deployed on each new product line. Just my time on this effort required on the order of 1 million dollars over three years. Eventually the framework was running on every tool that shipped out of the plant, as well as internal R&D and test equipment.

So, it was a success. I am sure that we would not have successfully shipped those products on time and under budget without it. However, I think that the current versions of Wonderware and the rest are far more configurable. I would look long and hard before considering the custom programming approach.

I'm glad that worked out for you. Keep in mind that you'll have ongoing maintenance costs to keep the software running/current throughout its lifecycle. Works well if you keep up with it. I've been through a similar situation where the developers eventually dwindled off and the system worked fine until there was a problem. It's a painful task to try to jump into something like that after the fact. But you can't beat the programmatic flexibility of a general purpose programming environment.

----
Nathan Boeger
http://notanotherindustrialblog.blogger.com
Inductive Automation

I've got say it again. The days that an automation specialist can *NOT* understand a general purpose programming language are headed for the same status as the days of an automation specialist who tried to keep 3-15 psi the primary standard in the face of the march of 4-20 ma.

Sure, sure, 3-15 psi is still here, and we're in the process of installing 4 valves that operate on 3-15 psi right now. I don't deny it's still here and still important. I don't deny that 4-20 ma is still here and still important. I don't deny that the All-In-One HMI packages are still here and still important. I'm saying that the envelope is going to expand, and we'd better expand with it.

Of course the expansion will be slow. No plant cut out all their pneumatic lines and ran conduit overnight. It took years for electronics to take over. It is taking years for the fieldbus-of-the-week to take over. And it is going to take years for the general purpose programming language to take over, too. But it's going to happen, like it or not. We will be like the dinosaurs. We adapt of die. The ones that didn't adapt are extinct. The ones that did adapt soar as eagles today.

Michael
--
Michael Batchelor
www.IndustrialInformatics.com

You keep REPEATING that same oversimplified example without providing additional substance! I agree with you in concept but not degree. Consider the advent and widespread use of automobiles. I can change my oil, but that doesn't make me a mechanic. Even if I was a mechanic, that doesn't make me a design engineer. With specialization, I can be an engineer working on: aerodynamics, the computer, thermodynamics, the electrical or mechanical systems, the transmission, fuel delivery system, tires or any number of things and NOT KNOW ANYTHING about the rest. The more complicated the car gets, the more likely I become a specialist instead of a generalist (or need details taken care of for me).

I never suggested that an "automation specialist" wouldn't be able to "understand" a general purpose programming language. I agree that "pre-canned" wizards will need to take a back seat to programmatic flexibility. However THERE ARE SHADES OF GRAY that you CONTINUE TO IGNORE. We're discussing distributed systems that are large in scale, need to integrate with Enterprise systems, have complex requirements that span disciplines, and have increased security and availability requirements.

This is not something that EVEN THE MOST TALENTED PROFESSIONAL PROGRAMMER can write from scratch in a timely manner - with ANY general purpose programming language! THAT'S the role that I keep putting on the automation companies. The implementation is less important here than the necessity to have a standard framework to work from. Maybe it's their own development packages augmented with powerful scripting languages, or maybe it's a general purpose programming language augmented with APIs and a base platform from which to begin. Maybe an Open Source consortium establishes the base. The point is that Industrial Software has unique requirements and that you need a HUGE ECONOMY OF SCALE to justify writing your own software from scratch. Sure, it works for Walmart. Do you see anyone in any industry rolling their own apps from scratch? I don't. Increased requirements increase the necessity to have a solid framework. And never did I suggest an "All in one" approach. This is where standardization and interoperability is king.

You're repeated use of "things are expanding so we have to expand with it" is MEANINGLESS to me. Please elaborate on what actions we should take or specifics on what to expect.

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

> You keep REPEATING that same oversimplified example without providing
> additional substance! <

OK, this is a legitimate complaint. I haven't been very specific. Part of that is that I am grappling with this as much as everyone else. Part of it is that we're also working on projects, and all things considered we gotta eat.

I will try to pull together some of my thoughts and post them later this week.

> I agree with you in concept but not degree. <

I do think we have far more that we agree on than not.

Michael
--
Michael Batchelor
www.IndustrialInformatics.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

Michael,

I understand how it is to be busy with projects, especially startups. I look forward to hearing your thoughts on the matter.

We ~do~ have a lot in common - we're both arguing different points of the same shades of gray. I looked at the services that you guys provide on your web site - I think we're both experienced in that same software space of industrial automation between custom programming, pre-canned applications, and the merger with modern IT technology/enterprise systems, etc. Wish I'd met you guys when I was in Charleston (up to last summer). I'm in Korea these days...

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

I'd like to stick my head back in here, too, since it was me you originally disagreed with, Michael. In fact, I think we are "in violent agreement,"
rather than not.

I'm looking forward to your examples.

Walt

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
wboyes@putman.net

Well, just one of the examples is that right now I am writing a proposal for a machine that will use the Beckhoff panel PCs with .net. The troubleshooting interface is to be designed in the system, not someone using a laptop to watch the ladder execute. Every sensor and actuator will need to be observable from the screen.

Is it as simple to do as a PLC based system? No. But improving productivity is paramount to the customer. I don't think we can cut costs much longer by simply slapping a quickly sketched out automation system on a machine. It's too cheap to send the assembly line to a developing country for the cheap labor. The only way is to increase productivity.

And quite frankly, as the global playing field levels out even more, then the "cheap labor" of the developing countries will give way to their rising standards demanding even more increases in productivity rather than reductions in labor costs. Who can complain about that? A hundred years ago most of my farmer ancestors had never seen an electric light, although they had heard of them. My grandfather bought the first radio in the neighborhood about 1910, and it ran from a battery sitting next to it until the REA actually got power lines up. (And surprisingly, the grid bias battery was never replaced by a power supply. It used a battery for decades.) Now days no one in the neighborhood would even know what to do if the power is off for more than a few hours. In another hundred years I think the current extremely rural areas of China, India, and other developing countries will be just like the extremely rural area of North America my family came from. I hope no one on the face of the entire planet can imagine life without electricity.

MB
--
Michael Batchelor

www.IndustrialInformatics.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

843-329-0342 x111 Voice
843-412-2692 Cell
843-329-0343 FAX

I heartily agree. I knew we were in violent agreement. I've been pounding this particular topic in my bully pulpit for years now... and on Tuesday, this is going to be one of the central topics in the keynote speech I'm giving at the Texas A&M Instrumentation Symposium.

Walt Boyes
Editor in Chief
Control magazine
www.controlglobal.com
blog:Sound OFF!! http://www.controlglobal.com/soundoff
_________________

Putman Media Inc.
555 W. Pierce Rd. Suite 301
Itasca, IL 60143
630-467-1301 x368
wboyes@putman.net

I'm going to stick my neck out here and wait for the sound of the blade sliding down...

The difference between 3-15 psi (or 20-100 kPa for most of us) and 4-20 mA; and the various manifestations of digital bus is that as a user of compressed air or 24 V DC I did not have to know an awful lot about the details of the air supply or DC source - I could stick a regulator on the end of an air line or a regulated supply on an AC outlet and get on with the job. With digital systems that is not an option as the communications medium is heavily interwoven with the rest of the system. Just look at the details that need to be provided to configure a typical communications link for example.

I do agree that the automation professional has to get on and develop an understanding of the digital computer environment he/she will be using as a platform. But there are still problems with the pointy-haired manager attitude that "A 4-20 mA system is electrical isn't it? So Jo Electrician can deal with all our instrumentation systems." Saying that an automation professional needs a knowledge of digital systems and computer programming, etc. is not to say that someone with this knowledge can handle everything an automation professional has to deal with. There is a LOT more to the job that simply knowing the platform used for system communications and implementation.

Even when setting up an HMI, the practitioner needs to know how the operator thinks. A classic example was given by the editorial in InTech a couple of months ago - according to Greg Hale, we should be using all the bells and whistles developed for computer games to "enhance" the "experience" of the operator. Sorry Greg - flashing lights with fine gradations of colour and high-fidelity graphics do not necessarily enhance the operator-machine interface. The black panel from the old world with lights etc only if there was a problem was the outcome of a lot of ad-hoc development into what worked and what didn't. The fundamental problem of the automation professional is the control and monitoring of the plant. This requires first and foremost a knowledge of the physics, chemistry, etc. of the plant, secondly details of the equipment needed to interface with it and how best to use it, and then finally and a long way back details of the platforms used to do the job.

Unfortunately the pointy-haired manager syndrome mentioned above is likely to be even more alive and well and we are already seeing a number of computer jockeys entering the field and failing to appreciate the need to know a lot more than just how the platform works. Think of the absurdity of employing a pencil-maker as a technical writer because after all the writer uses a pencil ... (I know, it's a word processor these days, but you get the idea.)

The automation field needs a lot of widely different skill sets, preferably in one body. Failing that, the need is for everyone involved to at least appreciate the needs and issues of others in the group. I consider I have a good working knowledge of a modern SCADA/HMI system and know when I need to get help - but as far as getting into the innards of a software package, life's too short and there are too many other more interesting problems to deal with.

Cheers,

Bruce

Bruce,

I appreciate what you're saying here. Michael's point is that the skillset of an "automation professional" is growing - or at least evolving. I think we all agree with that point to a varying extent.

You bring out an EXCELLENT and UNDERSTATED detail to the table here that hasn't been adequately considered. The automation professional developing the operator user interface NEEDS TO KNOW THE PROCESS and OPERATIONS to work effectively. I wouldn't go so far as the chemistry/physics/etc. But they do NEED to be able to capture the project from the perspective of the operator. Extend this a step farther to management, who are looking for a different set of reports/data. You're example of the fancy bells and whistles is dead on. My personal opinion of why most industrial software SUCKS SO BAD is because good software design(ers) have taken a back seat to plant type people, who don't know software.

I think you're right on track!

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

Just an aside - a "successful" set of HMI displays for a plant needs to be duplicated. One set is basically "dead" except when something is happening (the 'Black panel'). This is for the operators to work with. The other has all the flashing lights, fancy graphics, and so on. This is for the CEO. Or is my cynicism showing?

Bruce.

I have used all of them. I feel Wonderware is the best software. Citect is cheaper but graphics are not like Wonderware. Wonderware is very easy to configure/develop, highly flexible. All the drivers are available & value for money suitable for complex application using C scripts. Go for WW if looking for cheaper option go for Citect. I will not recommend Iconics.

I have had boatloads of difficulty with Wonderware lately. They don't seem to be able to send the correct licenses or product updates to my end users... so bad and so frequent that I had to stop being the middle man to stop my reputation bleeding from Wonderware's recent incompetence in ordering.

It's my opinion that if you think Wonderware is the best, it's simply because you know it the best, as there are several better and cheaper products. I found the above comment interesting, because Wonderware is definitely one of the lower functioning graphics editors (Citect is easily more capable), at least for us that have near OCD traits with object placement/size in graphics development. Wonderware's object handles can be nearly unusable with really small objects, and the lack of a method to move an object pixel by pixel with the keyboard drives me crazy. Iconics is the best graphics editor I've used to date with object detail in mind. Citect is the most wide open with capability, which makes it harder to pick up.

Anyway, as long as people want to bend these HMI products out of shape with over complicated customization trying to make them behave like other HMI products they are more familiar with, there will be work for the rest of us who know how to use these products as intended.

Chris

Before anyone changes HMI/SCADA brands these days, they should seriously checkout Indusoft, probably the fastest growing, most powerful package on the market. They have been getting all kinds of design awards throughout the world lately and can outperform anyone at substantial savings with more drivers. Runs on all Windows OS and is the most powerful CE package in the universe.

And, no I do not work for them.

Terry Miller
FlashPoint Automation

Chris, I don't think you've seen Wonderware in the last year - vector based graphics, very scalable.

Good day,

I just want to find out from any one out there if it is possible to run a program like Active Factory (Invensys Wonderware) with Iconics? Will it be possible to run MatrikonOPC with it, as I was informed that it will not be possible to run Active Factory with Iconics?

Hope someone can assist!!!

Regards,
CJ

Iconics supports OPC, whether Matrikon, SoftwareToolbox, or Kepware, as far as I know. You might ask Iconics what MES or middleware they have that has the same functionality as Active Factory. Remember, Iconics is a direct competitor with Wonderware, so it is highly likely that anything WW produces won't be compatible with Iconics, and vice versa. Iconics has some very interesting middleware so take a look.

Walt Boyes
Editor in Chief
Control and Controlglobal.com
www.controlglobal.com
Mailto:wboyes@putman.net
Read my blog SoundOFF!! At www.controlglobal.com/soundoff

In what way do you want to run Active Factory with ICONCIS? If you are looking to grab data from ICONICS historical Databases then you can use OPC-AE (for Alarms) and OPC-HDA (for historical data). If you are trying to get real time data you would just go right to the OPC Server.

If you want ICONICS GENESIS graphics/displays/trends in your Active Factory /etc... I do not think this would be possible since each uses a different proprietary format. The ICONICS BizViz products do offer the same types of functionality as Active Factory so you may look into those products as well.

Good luck and let us know what you find.

J

CJ,

I want to inform you a little more on ICONICS products and capabilities. Iconics is a pure OPC client software package. Iconics LEGACY 32 bit products which have been around since 1997 pure 32bit and OPC to the core and certified on Vista and 2008 Server since the release of those operating systems is modular. The graphical package is an ActiveX control and an ActiveX container. The Alarming package is an Active X control and the Trending package is an Active X control. You could use Iconics Trending inside of RSView or Intouch to log your data directly to SQL as it does this out of the Box for example.

Iconics not only logs alarms and Trend data directly to SQL or Oracle for example. It will connect to any ODBC data source.

Runs on Win2000,XP,2000 server, 2003 server, Vista and 2008 server(By the way Kepware OPC servers will run on Vista as well.) I am not saying you have to use Vista. I am saying your SCADA investment is safe (You don't have to worry about it.) By the way this is the legacy stuff!!

Iconics has a complete BizViz offering as well as SCADA. Enterprise wide reporting on any OPC/ODBC/Web Service point with a browser delivered interface all built on .Net

Portal solution which is based entirely on SharePoint services.

OEE out of the Box for people who want to visualize real time machine information such as uptime/downtime/machine availability.

Bridging product that is also built with .Net can move, manage, and manipulate data from any OPC/ODBC/Web Service data point to any of the same. I know one manufacturing facility that uses ICONICS to move data between a LEGACY Oracle v7.1, SQL, and OSI PI server and contextualize them in a SQL table to provide it to an existing third party application that gets its data from SQL.

These business solutions also run on the same OS offerings as the SCADA products from ICONICS which is really everything 32 bit and above including Vista and 2008 Server

Not to mention GEN64 which I believe may be the first 64 bit SCADA offering for Vista and 2008 Server as well as a Hyper Historian which can log over 50,000 changes per second. Heck their 32 bit product will log 10,000 changes per second directly to SQL on a 2008 Server machine and their 64 bit product will log 25,000 changes per second directly to SQL on a 2008 Server machine out of the box. All of their products will run in a VM environment as well, which I am pretty sure Rockwell and WW will not. ICONICS can provide 100% uptime solutions for all of these products also.

They also have the first OPC-UA implementation in conjunction with Kepware.

I think I have covered the entire spectrum. It’s the best and most reliable Microsoft based solution on the market hands down for SCADA and SCADA connectivity to the Enterprise(Which may be why ICONICS was awarded Partner of the year by Microsoft in the ISV Software category this year.), and ICONICS is not locked in to the whole terminal services solution either which is a pretty stupid way to provide think client SCADA in my opinion. I mean if you want to do terminal services with ICONICS you can, but you don’t have to they have much better thin client solutions to offer such as WPF and Silverlight is right around the corner as well.

Oh also ICONICS does have connectivity for SAP just so everyone knows. Of course according to SAP their standard for connectivity from ERP to the automation network is going to be OPC-UA and according to ISA OPC-UA is going to be the standard for S88 and S95. Of course ICONICS already supports OPC-UA... ICONICS also integrates directly to Active Directory.

Good Day.

Iconics Genesis is a suite of applications. The customer can choose which applications to purchase. The customer does not have to buy the whole package. In my application, I use only GraphWorx and do alarming, trending and data logging with other packages. Genesis is also a 'true' OPC client. The Genesis applications read data directly from the OPC server, not from their own database. In my application, I have an OPC server reading 3000 points from several PLCs and DAS equipment but yet I have a Genesis license for 500 points. This works because no GraphWorx screen has more than 500 points. I can add any of the 3000 OPC points to any screen as long as I don't exceed the 500 point limit on a single screen. For a comparison, I've also used Siemens WinCC in the past. I had to purchase an unlimited point license because its applications read from its own internal database not directly from the OPC server. WinCC treats the OPC server as a separate device and uses its own communication driver to read data from the OPC server. All 3000 OPC server data points must be read into the internal database of WinCC before if they are to be used by a WinCC application. Which method is best depends upon your application but this is a fundamental difference in HMI packages.

Still now, Wonderware supports only OPC DA. It cannot support OPC AE and HDA. They use their own proprietary alarm and historical. If you use other SCADA software to act as OPC AE or HDA, you can use other AE & HDA clients connect to it. You have to choose proprietary or global standard. That means if you choose proprietary, you have only one choice. But if you choose global, there are many choices to satisfy to your requirements.