HMI & SCADA Development software

[dlscott 0]

Would someone please comment on the advantages of using one of the HMI development packages (Wonderware, RSView, WinCC, etc) to set up an HMI vs. using something like VB.NET and and OPC server software? I'm setting up a new system and am try to decide what advantages there are to spending the money for a runtime license to one of these packages vs developing the fairly simple HMI with SQL connectivity in VB.NET. Thanks in advance for your comments. Dave

[JesperMP 2]

Hi dlscott. The advantages of a do-it-yourself approach is that you can tailormake it to suit your needs. Also, if you have large numbers of HMIs to create, then it can be less expensive than buying a shrink-wrapped solution. The disadvantage of a do-it-yourself approach is that a highly skilled person has to create and maintain the software. Do not underestimate the "maintain" part. You have to follow the development of new hardware, new standards, new software (Windows !). If you are talking about a single project, then there is no doubt about it. Get a comercial product. You may want to do out of personal interest and because you are very proficient in VB and SQL. If you chose to do it yourself, then just of a matter of decency have a contingency plan for your company/customer in case you change job or similar. In our company we have a person responsible for making a HMI. The numbers are 10-20 projects per year and almost completely standardised. Even so, it is getting harder and harder to maintain. So we are actually more or less migrating the HMI he is making to a comercial product.

[dlscott 0]

Jesper, Thanks very much for the comments. This could definitely be something that ends up on several processing lines in our plants and the maintenance issue is a good one to consider. Thanks again, Dave

[GerryM 2]

Jesper is right on as far as maintaining the software goes. Another point, in alot of cases, is programming time. The commercial packages tend to take less time programming, and once programmed startup faster and are more reliable in the long term. The offset to programming time savings would be the initial cost is higher for the commercial software. In my experience, as the HMI gets more complicated the commercial software becomes more viable. If you already have vb.net and the hmi is simple go ahead and try it, just have a backup plan like jesper recommended. Edited 1 Sep 2006 by GerryM

[paulengr 44]

The HMI has built-in objects specifically to do "machine control" type things. It is already specifically designed to talk to a PLC network. VB has built-in objects to do "application" type things where the beginning and end of the system operates within the confines of the PC or the PC and the network. The HMI's are easy enough to use that electricians can frequently do "programming" jobs. Even if you had SQL connectivity in your VB program, it doesn't for instance include an easy way to display data trends. Finally, it is frequently difficult to work on a VB program because it consists of scattered code fragments everywhere. Every single screen object contains a little piece of code. An HMI isn't like that. It definitely has code fragments. But a good HMI designer will use as little code as possible and that code is usually in very "obvious" places.

[rajsiyer 7]

Hello friend; Even if you are very good with VB my advise to you would be to stick with a properly licensed SCADA, in case you are a practising engineer like me. Else, if you are professionally into software as a developer.. please go ahead and hopefully we all benefit. See, in the control of machines by various computers such as PLCs & associated software, Reliability is the dominant consideration with connectivity to other devices/software a close second. For experimental or laboratory "Display" rather than "control" purposes it is easily possible to rig-up a VB project as SCADA application. This is possible even with EXCEL as excel has ready interfaces to most databases and writing macros etc will take care of any needs for graphs/trends etc. If you are good at creating ACTIVE-X components, Internet explorer , with server-modules in PLC slots could take the place of scada. This is the way at least one SCADA I know works. It is called Scada-Portal and its made by ABB. It is when you need to record ALARMS and such events you find that a SCADA package is far more reliable than what you may develop single handed on VB. And what about recipes? and security/ access controls?..Statistical Quality control, smooth integration with OPC servers etc.. etc...unless you have a TEAM of GEEKS you cant do it within a reasonable time. Other than InTouch and Intellution(IFIX) most other scada packages themselves entail a fair learning curve. The most notorious(that I know) is WinCC from Siemens and RSView of AB. The use of WinCC requires at least intermediate VB skills. Even in Cimplicity, scripting is based on VB. All SCADA packages allow you to create your own ActiveX objects and act as a "robust container" for code/objects that you may develop. What I suggest.. please obtain a demo version of SCADA-Portal and take a look at learning it yourself. You will enjoy it especially since you seem good at VB. No other SCADA "Bridges" the VB skillsets with the Industrial environment's needs the way that ABB's SCADA PORTAL does. Even though it comes across as half-baked when compared to InTouch, it's conceptually a little futuristic( based on Objects and containing Structures). If cost is your consideration you can look up the Czech make ASPIC from Merz, famous for their wonderful but cheap OPC servers. Ellipse from Brazil is visually beautiful and relatively easily learnt. Then there is ASTRA from my India though I think it has copied a lot from InTouch. However.... In the world of SCADA, my favorite is CITECT from Australia. IT works with almost any PLC and has the largest collection of Servers. It accomodates and enriches your existing programming skills whether in C or VB. I could go on and on... I've taught InTouch to hundreds till about 2004, now my time is entirely into projects. So Bye for now and best wishes in whatever you takeup. Raj S. Iyer

[Sleepy Wombat 27]

[Nathan 7]

Dave, Don't let the licensing cost of HMI packages influence your decision to custom program your controls application. Jesper is dead on in emphasizing the "maintain" section. I've dealt with many custom programming installations that aren't that old, and work rather well, but are impossible to modify and maintain. After a couple of years when the technology changes it becomes considerably more difficult than dealing with an old HMI package (still a pain). I've seen such applications written in Delphi, C, VB, or whatever else. It's not the language that becomes obsolete as much as the "technology set", for lack of a better word. Applications I've run across have been DOS or UNIX based, which is difficult to support in terms of getting new hardware to work with the legacy code. Often times the technology of the communication layer to the device is the painful factor. Here's an example of difficulties on the "maintenance" front. In one case I dealt with, the computer was dying so IT ghosted (imaged) the hard drive, which caused the drive to fail. Even with the disks and documentation that the original programmer left, neither IT nor any local integrators could get the application back up. That particular machine was one of 3 that worked together, responsible for a distributed presentation layer - way ahead of its time. Your mention of SQL is good. All major vendors are moving in that direction. You should see continual support and collaboration with IT departments into the future. Besides, SQL databases are powerful, fast, and not very difficult to use. I would recommend that you evaluate HMI packages. They should allow you to create a controls application faster than you could with a programming language alone. Nobody will argue that you don't have as much flexibility with .NET, in theory you have much more, but if your time is worthwhile and the end user is interested in using/growing the project into future, consider "pre-canned" packages.