Software Quality

R

Richard Dewees

I have 3 Advantech PC's doing process control.
The one that has been in the longest has been running for 2 years without any failures. It is in a dusty environment where the temperatures can fluctuate from 40-90F. I also have a Compaq desktop sitting right next to it that has been there almost as long and it hasn't failed me either (and it cost half as much).

The Hardware I am using is the PCA-6176 series in the IPC6098 Industrial PC Chassis.

Rick Dewees
Ocean Kayak
 
M

Michael Griffin

We have had desk top PCs in a production environment controlling test equipment for up to 8 years (or more) without problems. However, those
tend to be the exception. The AT&T 6300 (which was actually an Olivetti) was particularly good (one of these was the 8 years or more computer).
I would expect to see at least 2 years without trouble with a desk-top PC. However, most of them will fail eventually, sometimes in less
than 2 years. We have in the past used desk-top PCs in equipment, usually in a Rittal PC enclosure (fan ventilated with filters).

We are attempting to both reduce the frequency of failure, and to reduce the time required to repair a computer system and get it running again without having to call a technician in during the night or on a weekend and without losing too much production (air freight to Europe can get horrendously expensive).

To accomplish this, we are looking to make the items which we have found to fail most frequently (such as hard drives and power supplies) easier to diagnose and replace. Our interest in passive back planes comes from recent difficulties we have had in getting replacement motherboards with the right combination of ISA and PCI slots.

At the moment I am in correspondence with the local Advantech rep (operating out of Toronto) with whom I intend to resolve the technical questions I have. I have never dealt with them before, so I would like to thank you and Bill Sturm for your opinions on the company itself and their products.

**********************
Michael Griffin
London, Ont. Canada
**********************
 
C

Curt Wuollet

Hi Dave

An excellent and well reasoned analysis. I have few comments.

Dave Lillie wrote:

> On the documentation sub-thread:
>
> While pdf provides great printing capability, it suffers from some of the
> same proprietary usability issues as Microsoft's legacy winhelp, and
> present compact html doc format. The issue is that these proprietary
> formats are either difficult, slow, or $expensive to use from an
> independent search program's perspective.

Yes, pdf is the only defacto "standard" that is reasonably capable and portable. It is not without major problems, merely more so than the others.

> Why is independent search important? The ability to "text search" for user
> supplied keywords across a collection of documentation/manuals is an
> amazing productivity enhancement. As it is very rare for any of today's
> systems to come exclusively from one vendor: The ability to integrate
> documentation search across an ad hoc collection of various vendor docs -
> including your own custom documentation will become increasingly important
> as evolution continues (I.E. as young "Google Savvy" Engineers & customers
> begin to demand productive documentation design).

Absolutely.

> There is one more major issue besides index/search, which demands
> attention - Document Design. There is a difference between the design of a
> hard printed manual, and the design of a hyper text based (or web based
> document). As we all know, "refer to chapter 12 section 3" in a hard
> printed manual is a nuisance, while the equivalent "hypertext link" (in
> proper context) in an html document is a wonderful thing that reduces the
> clutter of "optional" or "obnoxious clarification" information, tables,
> etc. Hypertext clearly aids in user comprehension due to it's ability to
> encapsulate supplementary information and naturally cross reference
> associations. Hypertext provides the ability to bind to dynamic,
> up-to-date (I.E. relevant) information such as catalogs, news, and events.
>
> Unfortunately a solution that adequately addresses the requirements for
> both hard and soft documents is not here yet. I do not believe that the
> techwriting community has agreed upon an "Open System" documentation
> design that both embraces hypertext, and provides an organized way to
> print out the procedures, configuration tables, and job aids that are
> needed to operate offline. If the techwriting community embraces, and
> abides by the W3C - good things should be happening soon. If on the other
> hand, they get hooked into old Macintosh print format (pdf), or the next
> "gimme your wallet" Microsoft scheme, it is going to be a long bumpy ride.

The big problem here has been that the exclusive adoption of MS products for tools has implied their "standards" across the board. There is obvious merit in that approach but, it purposely scuttles any other options and inhibits cooperative efforts to really solve the problem. That's a very high threshold to overcome. And it's hard to get Windows users to care because it "works for them".
>
> Hopefully this issue can be resolved using W3C standards and an
> application Open Source implementation that prevents certain vendors from
> convoluting it. (note: application open source extends past Linux to
> include Windows & Unix. Examples - NetBeans, Castor, JBoss, PostGreSQL. I
> had to clarify, as I have seen postings on this list that use Linux and
> Open Source as synonyms)

I was worried until the W3C apparently decided that patented "standards" were not in their best interest. Nothing is final yet. We may yet be
without an objective and uncorrupted standards body. If they yield, all we will have is the OSS community.

I have made a special effort to be inclusive in this discussion as it affects everyone. The list is actually much longer here than in the general computing population. It's not simply Windows VS
everyone else. e.g. A surprising number of folks still need DOS.

> I do not claim to be a documentation expert. I have had experience
> managing a program that attempted to fully integrate the documentation,
> help, and website of 14 independently developed products. I have had
> experience managing a program containing Open Source applications and
> development tools. I question whether .hlp. .chm, .pdf, .vendorwhatever
> will help us get where we need to go. I hope that some form of XML
> compatible html, combined with CSS and an open, standards body endorsed, reference implementation will materialize.

We can only hope.

> The documentation issue extends well past the boundaries of Manufacturing
> or Industrial Control. It will most likely be solved by the general
> software industry under the "eCollaboration - workflow" category, as
> opposed to being solved in our smaller "cManufacturing" realm.
>
> In summary - The technology exists to completely solve this problem.
> Unfortunately we do not have a coordinated effort to leverage it ......
> yet.

And certain nearly omnipotent parties will be frantic and desperate to prevent or derail it. Hopefully there is enough enlightenment
to cause them to fail.

> My 2 Cents,
>
> Dave Lillie
> Software Program Manager
>
> (Opinions expressed are mine alone, and should not be associated with the opinions of my employer - Rockwell Software Inc.)

I don't think you have to worry about that :^) at least the misassociation.

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
M

Michael Griffin

At 06:17 31/10/01 -0500, Ranjan Acharya wrote (quoting another source):
<clip>
>"There are substantial numbers of people out there that openly despise
>Microsoft ...
<clip>
>absorbed in an horrifying monopolistic quest for world domination.
>To them, Microsoft is a group of Evil Troglodytes ...
<clip>
>The next paragraph points out that most people are somewhere in the middle
>(IIS is particularly bad!). We need to strive for that kind of balance on
>The Automation List.
<clip>

So I guess the balanced point of view would be that Microsoft is only moderately evil, and it only wants to dominate part of the world
(presumably the part with all the money). I'm sure that Mr. Wuollet would be a gentleman and concede that much.
(I'm sorry about this comment, but I couldn't resist when you handed me a line like that!)

>Postings with questions regarding a problem with
>RSView, for example, need responses with direct solutions; not responses
>espousing the merits of WinCC (or vice versa). The same goes for Linux or
>Windows.
<clip>

Mr. Acharya has a good point. It sometimes pays to think twice before sending a message. We'll all be here the next day if you still think you have a point to make. I have tossed more than a few of my own messages in the scrap bin rather than sending them.

The Moving Finger writes; and, having writ,
Moves on: nor all they Piety nor Wit
Shall lure it back to cancel half a Line,
Nor all they Tears wash out a Word of it.
(Omar Khayyam)

**********************
Michael Griffin
London, Ont. Canada
**********************
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Sorry, but this is absolutely untrue. I can brag up a server running 2, 3 4 or more years, and that is considered a very good system. PLC's run for decades without downtime. How many of us have systems still running on the "new at the time" PLC-2? Stating that a PLC will crap out more often than a PC is absolute fallacy.

--Joe Jansen

Paul Jager wrote:

>... The most frequent argument we get is reliability, but this is a
perception. We've seen on this list that Siemens, Allen Bradley PLC's
crap out more often than a properly tuned server. And of course for
computing power PLC's are even close....<
 
V
Ranjan, I really like your reply. It is short, sweet, and to the point. I wholeheartedly agree that pointing out how "Linux would have done
a better job" in response to a question for help on RSView is a non-answer at best, and a sharp stick in the eye at worst.

The question that begins with "I've got a problem with thus and such..." implies that all the design and selection decisions have already
been made long ago ... Let's *help* that person; not guffaw and tell them "well, if only you'd done this or that, you wouldn't be in this spot".

Regards,
jfv

John F. Vales
[email protected]
 
M
Paul Jager wrote:

<clipped>
>We've seen on this list that Siemens, Allen Bradley PLC's crap out more
often than a properly tuned server.
<clipped>

I must have missed that posting. Who compared servers to PLC's and said they have fewer failures?

Sincerely,

Mark Wells
President
Runfactory Systems Inc.
http://www.runfactory.com1235 Bay Street, Suite 400
Toronto, Ontario, Canada M5R 3K4
Ph. 416-934-5038
Fax 416-352-5206
 
C

Curt Wuollet

Hi Joe

Sounds like we have to switch brands.
The GE PLCs we're using are good but not that good. They, in aggregate, are running about as well as the Linux boxes or a little worse. But the Linux boxes require maintenance though seldom requiring downtime. Once I get rid of the fans and hdd's...?

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned
Industrial Automation Software For Linux. mat.sourceforge.net.
Day Job: Heartland Engineering, Automation & ATE for Automotive
Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to
Linux.
 
C

Curt Wuollet

Hi Micheal

All my effort since joining the automation list has been advocating some sort of balance. Even with the LPLC and AutomationX it's 666:2.

> <clip>
>
> So I guess the balanced point of view would be that Microsoft is
> only moderately evil, and it only wants to dominate part of the world
> (presumably the part with all the money). I'm sure that Mr. Wuollet would be
> a gentleman and concede that much.

Absolutely, So far they haven't dominated the Lake Superior Agate business and they've left ditch digging and septic pumping alone along with cutting pulpwood and rock farming. So they don't have everything in Mille Lacs county. I do have to evict them to use any computer and it's tough doing automation without patronizing them. But yes, it's only a problem if I'd like to make a living. It'd sure be nice if I didn't have to build my own PLCs to have reliable tools and run Linux.

Regards

cww
 
P
I have a new name for the PLC- it's a Pathetic Little Computer. Imagine any critical business or operation say a government service, a highly popular web site, banking services, etc. - running on PLC's. Obviously it can't be done. Yet from a computing standpoint this is what we blindly and faithfully do for industrial applications. This approach is hurting the industrial business. There is a lack of available computing power, lost opportunity of data distribution and computational flexibility, and finally the total cost of ownership.

It's not a simple question of Server more reliable than PLC, etc. My statement is that a server pair can and does deliver the required
reliability with benefits far exceeding what a PLC based platform can provide. I should point out that proper server SOFTWARE is a critical
element in the non-PLC equation. This market has some top solutions and is developing at a rapid pace.

In my travels to various sites I see a lot of scared engineers, with a personal fear of innovation. As a group we are not very open-minded. Those that combine business savvy and technical prowess are rare. Even rarer still are those that can interface with management executive.

Yes the PLC of course has less moving parts than today's servers. Taken for face value the PLC might eek out a server for uptime, but you are costing your company a hefty price overall with such loyalty to a Pathetic Little Computer.

Paul Jager
CEO
www.mnrcan.com
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Wow! This has gotten almost funny! After reading your post, I decided to head over to your website in hopes of finding something with a bit more substance. What I found was even more amusing. Your gleeful renaming of the PLC, and your outright hostility to them is more than apparent. I guess the reason this is funny is because while I was still in school, I was being told by people to not bother learning PLC's, since they will be gone in a year or less anyway. That was over a decade ago. I seem to
detect the same attitude from your site: PLC's are gone, and anyone who buys one is obviously clueless. I find nothing on your website that is
beyond nine months old. Have you been around longer than that?

OK. Now to address the posting:

---
I have a new name for the PLC- it's a Pathetic Little Computer.
---

Cute.......

---
Imagine any critical business or operation say a government service, a highly popular web site, banking services, etc. - running on PLC's. Obviously it can't be done.
---

Gee. you mean I can't load Oracle onto my Micrologix? Boy, this thing *must* be a piece of garbage! This is simply a case of right tool / right job. What about a 'mission critical' medical process? Or a food processor. I can guarantee that anyone who needs absolute uptime isn't running a PC control.

---
Yet from a computing standpoint this is what we blindly and faithfully do for industrial applications. This approach is hurting the industrial business. There is a lack of available computing power, lost opportunity of data distribution and computational flexibility, and finally the total cost of ownership.
---

A properly deployed system does not suffer from any of these problems. You cannot take a 10 year old installation, and compare it to a PC based
installation today, and then point out the differences. Where was -your- system 10 yrs ago? The point is that by properly combining the
technologies, be they PLC, PC, Network, HMI, etc. you can get a system that is far more robust than any one of these alone. Just as I would not try to use lights and buttons as the sole UI on a system of any complexity, you cannot honestly tell me that it is cost effective and justifiable to use a PC on *every* control system.

---
It's not a simple question of Server more reliable than PLC, etc. My statement is that a server pair can and does deliver the required
reliability with benefits far exceeding what a PLC based platform can provide. I should point out that proper server SOFTWARE is a critical
element in the non-PLC equation. This market has some top solutions and is developing at a rapid pace.
---

You were the one that made the reliability statement originally, I believe. What exactly do you now mean by "server pair"? Are you suggesting that the only way to make your system more reliable is by having two of them? Is that cost effective against a Micrologix 1000 with 16 I/O points? Remember, you are the one saying that PLC's are useless. I am not saying PC's are useless, just not the best solution for every problem.

---
In my travels to various sites I see a lot of scared engineers, with a personal fear of innovation. As a group we are not very open-minded. Those that combine business savvy and technical prowess are rare. Even rarer still are those that can interface with management executive.
---

I think you are mistaking 'fear of innovation' for fear of having to support some PC based nightmare whose rapid pace of development means
patches, upgrades, and bugs. The reason that induistrial controls are not on the bleeding edge is because we have no time for firmware and control software that needs constant patching. I have never experienced a PLC processor going into the equivelant of a 'blue screen'. (yes, I realize that PLC's have no screen. DUH! What I mean is that the processor doesn't just go out to lunch because an I/O driver was written wrong and created a memory leak, or whatever....)

---
Yes the PLC of course has less moving parts than today's servers. Taken for face value the PLC might eek out a server for uptime, but you are costing your company a hefty price overall with such loyalty to a Pathetic Little Computer.
---

"Might eek out"? ROFL! Let's see. at the last plant, we had to redesign the RSView apps and PLC programs so that the process could continue while
the PC rebooted, since it went down about every 4 to 6 months. RSView on NT. No extra software, no games, all service packs applied, blah blah
blah. It was a noisy environment that the PC was in. But guess what? Sometimes that is the environment that you get. Also, I am not costing my company anything by using the proper tool for the job. I guarantee that what I am doing with a PLC, you cannot do with a PC for the same price and same capabilities. And what I *do* use a PC for is the best use of a PC in *our* production environment

Looking at the website, specifically products.phtml, that looks like a lot of computing power. I notice that you have a hot standby machine in the loop. Is that to indicate that reliability is defined as redundancy? Also, you make the statement that:

"Field components are typically accessed via (E)ISA or PCI boards inside the control servers, an integrated Soft PLC enabling many different
combinations. Typical cycle times (to perform all the control tasks and send data to and from the field devices) are from 20 to 100 milliseconds"

A couple things on that. One, I have noticed that (E)ISA bus is disappearing from new PC's. How do you intend to support systems that still rely on (E)ISA cards to communicate? Or do those get dropped? What if my process needs a faster scan time? Most my stuff runs in the 5 to 10
msec time frame.

Lastly, on the website, I read your tirade against PLC's that is disguised as a FAQ.

You state:

"WARNING: For all of you out there wiring your 1761-NET-AIC devices to these terminals to interface to .. a SLC-500/01/02/03 processor beware. If you short the terminals the program in the processor is lost. "

Since most times, this is a one time connection, I feel comfortable comparing this to the time I was installing a CD-ROM drive at home, and
mistakenly plugged the power connector in upside down. Oops. Guess that is comparable to not paying attention and shorting the terminals together. Unfortunately, I couldn't just reload the program and go again. My PC did not have adequate protection against me being an idiot, and therefore I wound up buying a new CD ROM drive, and my power supply went out a month later. I believe the (PC) has a firmware bug. (Paraphrasing your website).

Of course, you answer your own imagined problem on the same page:

"(Of the) SLC memory corruption instances there were only a few in which a fat green wire to a solid ground didn't solve the problem."

Are you sugesting by comparison that I can run my PC solutions without a ground terminal?

And, of course:

My (P)athetic (L)ittle (C)omputer has never gotten a virus.
My (P)athetic (L)ittle (C)omputer never has operators loading games on it.
My (P)athetic (L)ittle (C)omputer never stops running because of an I/O driver getting corrupt.
My (P)athetic (L)ittle (C)omputer never has a hard drive crash.
My (P)athetic (L)ittle (C)omputer has near-zero boot time requirements.
My (P)athetic (L)ittle (C)omputer can keep a complete application backup in a EEprom for when the program does get dumped. Of course, My (P)athetic (L)ittle (C)omputer never dumps the program when handled properly.
My (P)athetic (L)ittle (C)omputer can continue to run without a screen.
My (P)athetic (L)ittle (C)omputer can continue to run without a keyboard.
My (P)athetic (L)ittle (C)omputer can continue to run without a mouse.
My (P)athetic (L)ittle (C)omputer doesn't rely on hardware that is revving every 6 months. I can find A (P)athetic (L)ittle (C)omputer **exactly**
like the 5 year old one that my forklift driver just speared on his fork.

And for the record, although control.com reserves the right to post all of the discussions here on their website, I want to make sure that -none- of
my comments in this or any other posting get re-posted on your or any affiliated companies website.

--Joe Jansen
Controls Engineer

The opinions expressed here are mine, not my companies, blah blah blah.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

In an effort to turn this into a useful thread:

A couple years ago, I was at the NMW show in Chicago, and saw an Omron PLC that had been built onto a PCI card. The processor lived inside the PC and controlled I/O using various fieldbus flavors. The PC was able to access PLC memory natively through the PCI bus.

I was wondering if anyone has ever used or seen one of these in operation. We just got approval for some prototype equipment where we plan on using Omron PLC's with DeviceNet, and I thought that if nothing else, this would be an interesting academic exercise to investigate.

Thanks!

--Joe Jansen

 
A

Anthony Kerstens

Modicon had something similar. It was a 984 processor combined with an SA85 (Modbus Plus)card. It could be programmed using the same software as their other processors, but was limited in memory as it was contained on the card
and isolated from PC hardware. It was not a PC PLC, but a PLC residing on a PC card.

The only case where I seen one was on a line I upgraded 4 years ago. I ripped it out and put in a Modicon Quantum processor. The main complaint against it was it had to go out to MB+ to get it's I/O, which was too slow for certain points.
The Quantum had direct access to I/O in its own rack.

Mind you, something like that would be great as a testing/simulation tool.


That said, with PLC's incorporating ethernet now, I wouldn't even think about using something like that. I'm currently happy with flipping bits and doing small amounts of math with a PLC, and letting a PC deal with sql, recipes, and other such stuff. From my perspective, if a database or PC goes down, the machine must still run.

Another concern is several instances I've had where memory and HD's were stolen from locked-up plant floor PC's on midnight shift (presumably, but someone with keys). It's not a software quality issue, but software cannot be considered
in a complete vacuum. The choice to go with a PLC is just as much about hardware as it is about software, if not more.

Anthony Kerstens P.Eng.
 
N

Nathan Boeger

Interesting article! The post is dated, but still very relevant. In my opinion consumers shouldn't put up with paying forced "maintenance fees". I think that they should be able to reasonably expect their software to work properly and bug fixes should be included. For example, Inductive Automation is paving the way with industrial (SQL datbase driven web launched SCADA) software that is reasonably priced and you don't keep paying for again and again. FactorySQL and FactoryPMI go above and beyond by including unlimited upgrades, including support, and not charging artificial fees (concurrent clients, tag count, developer software, etc).

The industrial software business is dated in its practices. HMI programs are getting bigger and more bloated instead of tighter and more efficent. These companies should take a hint from the open source community. They should seek to lower their lines of code. They should leverage existing developed technologies (databases, reporting engines, networking protocols, GUI tools, etc) to avoid writing their own buggy crap whenever possible. Low cost, high quality software that gets the job done is not too much to ask in this industry. If integrators and manufacturers quit supporting this practice we'd have moved a giant step in the right direction.

--
Nathan Boeger
http://www.inductiveautomation.com
 
Top