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

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

 

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 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
[email protected]

 

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'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"

 

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
[email protected]

 

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