M$ vs Linux in Automation

E

Thread Starter

Eminent

Hello everybody on the list,

The discussion that has been going on with regards to Micro$oft versus Linux in Automation.

The Way an automation or instrumentation & Controls engineer would see his
requirement is

1. The Systems functionality.
2. The systems reliability.
3. The systems cost in comparison with other systems.

Functionality is measured, as availability of PID bock, maths blocks, analog
input linearization blocks, input signal conditioning blocks, totalizer blocks, discrete blocks and several such blocks. Again the success of systems depends on how good an algorithm was used while making the blocks. If the PID block is badly made, then the system will face failures and be driven out of the market.

Reliability. Measures such as MTTR MTBF and others. Redundancy of several types (processor redundancy, redundancy upto I/O level, TMR etc.).

So if a system is able to connect to the chosen field devices and has connectivity to other systems via drivers then the user is happy.

The cost of Instrumentation and Control is approximately less than 5% of plant cost.
The cost of cables and instrumentation is generally 80% of the Instrumentation cost. So in the end the automation or Instrumentation & Control Engineer is
fighting for 1 % on the Control room level.

There was a time when the plant life was supposed to be infinity and investments made accordingly, including the investments in automation. Now the entrepreneur believes that the future predictions are limited to a max of three years from hence or at the most five if the person is lucky. So cost for the day is considered most critical.

If I look around then today M$ or Linux are probably present in less than 5% in terms of quantity and price, in the automation scenario. The software segment is dominated here by proprietary and reliable firmware type platforms of AB, Taylor, Foxboro, ABB, GE, Toshiba, Nishko and others.

The visualization is getting dominated by systems on M$ platform with some
setbacks to the UNIX platforms of yester-years . There is some skepticism about M$ but since M$ figures mostly in visualization stages and not in the critical safety related stages of the plant, people tend to ignore this while selection of a system.

Once Linux spreads to the desktop then people may probably demand some
visualization on Linux. Until the time that Linux is established on the Desktop with good utilities (which are readily available today) and good Support (which is lacking in remote areas where the plants are located), it faces a disadvantage as a choice in the Automation platform. In fact selling on Linux may face certain disadvantages with users, scared and imagining Linux as a tool for the "technology savvy".

A large part of the discussion in the list has been conducted assuming that the user has a Computer professional's or a computer savvy person's skills, whereas the truth is that 90 % of the Automation end users in the world are not "that" computer savvy. They probably still have a procedure for taking a graphic printout written in their plant SOP manual and follow it rigourously and the catridge replacements are still done by the maintenance department
personnel.

The users need a user friendly system, with good support and functionality.

If your system lacks several process blocks, or good trending then the user is unlikely to select your system, be it on any platform. One trip could cause losses in millions and will cover the cost for tens of automation systems and hence price is still a issue related to reliability and the competition.

The price of M$ SCADA systems are less than the prices of DOS based systems. We were paying more for UNIX and DOS based systems in the yester-years than we are paying for M$ systems today. If you calculate the Past values and compare it with M$ costs the ratio could be 0.1 or lower. Linux, I must admit, has the potential to change the Scenario and make things even better.

M$ or Linux.
The winner will be the one who gives the functionality required by the user and the comparative cost factors and most important factor will be "how user friendly is the GUI".

Anand
 
A

Alex Pavloff

> Once Linux spreads to the desktop then people may probably demand some
> visualization on Linux. Until the time that Linux is established on the
> Desktop with good utilities (which are readily available today) and good
> Support (which is lacking in remote areas where the plants are located),
it
> faces a disadvantage as a choice in the Automation platform. In fact
selling
> on Linux may face certain disadvantages with users, scared and imagining
> Linux as a tool for the "technology savvy".

But it won't -- I don't think Linux will ever succeed in the desktop market
to the extent that it will in the server and embedded markets. However, I
also disagree with your point that this is needed before the system can be
used for automation.

> A large part of the discussion in the list has been conducted assuming
that
> the user has a Computer professional's or a computer savvy person's
skills,
> whereas the truth is that 90 % of the Automation end users in the world
are
> not "that" computer savvy. They probably still have a procedure for taking
a
> graphic printout written in their plant SOP manual and follow it
rigourously
> and the catridge replacements are still done by the maintenance department
> personnel.

> The users need a user friendly system, with good support and
functionality.

The end users need a system that does the job -- they don't need a web
browser/office suite/media player. As an HMI, they need to be able to hit
buttons. Find me one maintenence department nowadays that CAN fix common
errors on a PC installed in their plant. Remember -- all the engineers in
the plants were outsourced -- all you've got left is electricians.
Electricians don't have the training to deal with Windows OR Linux PLCs when
used as HMI/SCADA/whatever purposes.

> The winner will be the one who gives the functionality required by the
user
> and the comparative cost factors and most important factor will be "how
user
> friendly is the GUI".

The main thing that Linux has is a need for a smarter engineer setting up
the system. Push-buttons/charts/dials are the same on either system. What
a smart engineer can do is use his computer knowledge to setup a Linux
system with a fraction of the software cost that he would have to use for
Windows, and make it more reliable and flexible for new tasks.

And, by the way, folks, calling the Micto$oft just looks plain stupid. This
isn't slashdot. Its not necessary.
 
B
I haven't commented until now, as my forte is more towards understanding hardware, and general principles, rather than writing software. That
doesn't mean I'm not familiar to a greater extent than most industrial electricians with computers, and must agree with Alex on these points.

For instance, the other day one of our machines shut down, and could not be restarted. The Win v3.1-based HMI would start up, but generated a couple of error messages (that hitting the 'ignore' button allowed me to bypass), and
finally loaded the HMI. Once there, a user could type in a password and enter the system, but could not change any setpoints, and all the displayed values were frozen.

Several good electricians had been troubleshooting the machine for about 6 hours previous to my arrival, and one of my colleagues had found a backup of older program and datafiles I'd ZIPped up, downloaded the Guest setup
files via the Internet from the Iomega site, and installed them on the computer, and had the ZIP drive connected, but didn't know how to issue the
proper command line to start an unZIP to restore the original pathspecs and files from the disk.

Fortunately, he didn't try, because the root problem was that the NIC connecting the HMI computer to the machine processors (FYI - Opto22 Mistic controllers over ARCnet) had become unplugged. Once it was plugged back in normal operation ensued.

To my way of thinking, this type of thing happens because it involves a combination of three different areas of understanding - electrical
knowledge, computer knowledge, and systems experience, and troubleshooting skills in each. It also requires a "controlled fearlessness" and tenacity in troubleshooting, and the ability to avoid jumping to conclusions, and potentially making the problem worse.

If the scenario outlined above is typical, then I don't think it matters much whether the computer is running Winxx, Linux, OS/9, and so on, how
easy or difficult it is to set up the OS, or how pretty the GUI is. Typical electricians will tend not to find the problem (even though I'd like to
think our electricians would have eventually found the loose card in the above situation, what about the slightly more complex, yet functionally
equivalent issue of a bad NIC?), and it'll take someone like me who has a foot in both hardware and software worlds, and with decent troubleshooting skills anyway.

Even a simple problem like this required the troubleshooter to come up against the computer, and many still find this black box something to be
feared. I think this makes them hesitant to even look under the hood, and thus obvious things like an unplugged board are missed.

I haven't set up a Linux system yet (although I did pick up one of the distributions at Staples the other day, and am in the process of getting
other doo-dads to resurrect one of my older PCs), but, based on what I read in the installation manual and elsewhere, it doesn't look all that much more difficult. In fact, it might turn out to be in some ways easier ... it's probably easier to pick through the configuration files than it now is to find things in a Windows registry.

I don't have anything against Microsoft, except those things they cause for themselves, like some of the new licensing subscription schemes, which,
when/if employed, will add another dimension to maintaining HMIs built on their OS. However, it would be nice to have a choice to what OS my
applications run on, and, if Linux is as stable as it appears, this would be mine. What I'm waiting to see is Microsoft's reaction if one of the big HMI and/or PLC programming software players decide to make thir product available on Linux.
 
Hello Alex,
It seems that we are arriving at the same solution from two different angles,


----- Original Message -----
From: "Alex Pavloff" <[email protected]>

> > Once Linux spreads to the desktop then people may probably demand
> > some visualization on Linux. Until the time that Linux is
> > established on the Desktop with good utilities (which are readily
> > available today) and good Support (which is lacking in remote areas
> > where the plants are located), it faces a disadvantage as a choice in
> > the Automation platform. In fact selling on Linux may face certain
> > disadvantages with users, scared and imagining Linux as a tool for
> > the "technology savvy".
>
> But it won't -- I don't think Linux will ever succeed in the desktop
> market to the extent that it will in the server and embedded markets.
> However, I also disagree with your point that this is needed before the
> system can be used for automation.

"At the end of most fights, there is one fighter standing and another lying down"
Who wins the Desktop battle and focuses properly, will be found standing at the end of the fight. In another ten years time, and anyone can take
this down in their diaries if interested

"Every Desktop will be an Enterprise or a part of an enterprise"

With the speed and processing power available then, the present arguments will seem meaningless. If Linux is not there in the Desktop
then Linux will slowly be going out of other areas where it establishes itself today replaced by applications that the user is more comfortable
with.

And I am feeling unhappy, on hearing that Linux is not meant for the Desktop!
Look at the Scene below:

1. Company System Administrator loads windows, office and utilities on a machine used on the plant floor.
1. A Company System Administrator loads Linux, StarOffice and utilities on a machine on the plant floor.

2. User starts the system and logs in using his username and password foe eg: Anand and Password123
2A User starts the system and logs in using his username and password foe eg: Anand and Password123

3. User Opens his Office application and does some work like maybe finalizes a report.
3A. User Opens his Office application and does some work like maybe finalizes a report.

4. User Opens Mail (maybe OE or Mozilla or Netscape) and adds the report as attachment and presses send..
4A. User opens Mail (maybe Mozilla or Netscape) and adds the report as attachment and presses send.

I am unable to see great difficulties in using Linux as a desktop. I believe that many programmers would like to Scare people away from Linux or probably overcharge for services provided on Linux platform and hence such propaganda is being resorted to. I believe that many applications have near equivalent if not better applications in Linux. In addition these are either free or available at very low cost. So why shouldn't Linux Suceed on the desktop!

Except for Gaming where windows platform today provides such a variety, there is very little that the Linux desktop may be unable to provide
except for slower releases of device drivers.

> > A large part of the discussion in the list has been conducted
> > assuming that the user has a Computer professional's or a computer
> > savvy person's skills, whereas the truth is that 90 % of the
> > Automation end users in the world are not "that" computer savvy.
> > They probably still have a procedure for taking a graphic
> > printout written in their plant SOP manual and follow it
> > rigourously and the catridge replacements are still done by the
> > maintenance department personnel.
> >
> > The users need a user friendly system, with good support and
> > functionality.
>
> The end users need a system that does the job -- they don't need a web
> browser/office suite/media player. As an HMI, they need to be able to
> hit buttons. Find me one maintenence department nowadays that CAN fix
> common errors on a PC installed in their plant. Remember -- all the
> engineers in the plants were outsourced -- all you've got left is
> electricians. Electricians don't have the training to deal with Windows
> OR Linux PLCs when used as HMI/SCADA/whatever purposes.

The end user generally prefers as many goodies as are available. even if he were to load Linux, he could still get browser (Netscape 4.76 with
Red Hat 7.1 or Lynx), He gets a lot of tools plus c programming facility, plus multimedia players. What is lacking is a good VCD player which is resolved by MTVP with some limitations. Plus he gets all the features of Linux. I will agree that plant floor people have lesser capabilities when it comes to fixing PC problems and rely on a System engineer and hence weather M$ or Linux does not matter to them and hence need not bother
the Automation List. It belongs to a Linux or M$ list which is abundant elsewhere. Electricians and Automation personnel still rely on the IT department for problems related to Windows or any other OS.

> > The winner will be the one who gives the functionality required by
> > the user and the comparative cost factors and most important factor
> > will be "how user friendly is the GUI".
>
> The main thing that Linux has is a need for a smarter engineer setting
> up the system. Push-buttons/charts/dials are the same on either
> system. What a smart engineer can do is use his computer knowledge
> to setup a Linux system with a fraction of the software cost that he
> would have to use for Windows, and make it more reliable and flexible
> for new tasks.
>
> And, by the way, folks, calling the Micto$oft just looks plain stupid.
> This isn't slashdot. Its not necessary.

No Automation party calls Microsoft at least in this part of the world, they contact Automation Solution providers like ABB, AB, Schnieder,
Rosemount, Toshiba etc. and the innumerable System Integrators and Consultants, who are instrumentation and control people. They get M$ or
HP-UX or UNIX or Linux or QNX or whatever is the platform of their system including DOS, I DOS etc. The client sees this as a solution
without going into details of what is the platform. If it fails, then it is a system failure and if it succeeds, then the system is successful. I believe that the above statement reinforces the need to stop arguing about M$ or Linux in the long run. We are Automation people and we need to spend more time on discussing things that relate more to automation.

Our world is Automation and not Operating System Alone.

Anand
 
R

Ranjan Acharya

Speaking of Windows XP authorisation. Can anyone imagine at 02h00m in the morning trying to authorise a new copy of Windows XP over the telephone for an HMI that went down in the middle of a noisy messy steel mill, has no back-up, cannot easily be moved, has a membrane keypad ... Probably a bit of an alarmist case, but having to call Microsoft to authorise a system if it cannot be connected to the Internet is hopeless.

Perhaps this might make a few vendors think about using either versions of XP that do not require authorisation or versions of other OSs (that would
crash a lot less too).

Correct me if I am wrong, but Windows NT 4 had a nice long product life cycle. Windows 2000 is already being replaced, and many vendors have not
even finished porting their applications from DOS/NT/Other to Windows 2000. Now Windows XP is here and we start all over again - plus we have to put on hip waders to get past all the hype about ".NET". My new Dell 8000 will not even run Windows NT. I still have to support DOS as well as NT. Perhaps it is time for some less-well-known industrialised ruggedised laptop that has a
simpler set up that will run DOS, NT, 2000 and XP with the minimal ammount of hassle. Of course, it will need a monster hard disk to support all the different applications. May be I should start making them factory-configured to run for various industrial OEM families.

<clip>
I don't have anything against Microsoft, except those things they cause for
themselves, like some of the new licensing subscription schemes, which,
when/if employed, will add another dimension to maintaining HMIs built on
their OS. However, it would be nice to have a choice to what OS my
applications run on, and, if Linux is as stable as it appears, this would be
mine. What I'm waiting to see is Microsoft's reaction if one of the big HMI
and/or PLC programming software players decide to make thir product
available on Linux.
</clip>
 
C

Curt Wuollet

Just curious, Why is the desktop so meaningful to automation? I have
many systenms that have absolutely no relationship to a desktop nor
is there any pressing need for them to be. This is a red herring.
I don't write software for desktops, the software I write controls
things. I haven't been talking about what Tillie in accounting uses,
Tillie can use anything, For controls systems the requirements are
somewhat more stringent and performance or lack thereof on a desktop
is irrelevent. Hell, I don't even have a desk. I agree that the
relevence alarm is ringing but I didn't go there. Why does every
discussion re Windows end up talking about anything but automation?
I talk about stability, they talk about popularity, I talk about
programmer productivity and the advantages of OSS and they talk about
ease of use for electricians and embedding things in Word documents.
This tends to confirm my position that that there is very little
about Windows that _is_ relevent to automation and control.
What matters to me are reliability, communications, access to the
internals needed to effectively control and instanciate hardware,
, realtime concerns, productivity, flexibility and initial and
continuation cost to me and the customer. You know, automation stuff.
If you want to talk about embedding graphs in reports, you've got the
wrong department.


Regards,

cww
 
In the end we all have the same concern - making money. Your approach is to emphasize the differences between automated control and the rest of the enterprise. At the same time the industry is seeing the benefit of seamless
I/O between controls and the rest of the enterprise. Your approach quickly creates a separation between the enterprise and controls, because you limit the integration between the enterprise and controls by picking a different
operating platform than the rest of the enterprise.

The other approach is to try to make the same operating platform work for both worlds. The people that are successful at that get a huge gain, because they have a much tighter integration between controls and the enterprise. The cost of doing business is lower because there is less work required to integrate the information flow. The cost of support is less
because there isn't a need to have a separate group of people to support the controls operating platform.

In lean manufacturing terms one might say that your approach can lead to local optimization at the expense of the enterprise. I am not saying that this is what is happening with you. Or, that there isn't a time for being different. I am just saying that for those of us that are capable of using NT as the controls operating platform we can save our company money and provide a more robust solution.

Maybe Tillie doesn't need to get realtime feedback from a control system, but it might be very important for her to know the status of an order that is running through some machines. She may be a design engineer that is working on a quality problem and she might be receiving a stream of data that she is running through an algorithm to trap an event.

By utilizing common technologies I have less specialists to maintain in my operations staff. I save time and money and I am better suited to close the information loop that runs through controls and completes the supply chain.
 
J

Joe Jansen/ENGR/HQ/KEMET/US

The disparity of interoperation is not the fault of the Linux users tho. I will concede the fact that NT on the machine will give you a greater
ability to tie in with the 'office' machines. The question to ask tho, is why is it that way?

NT is not more stable. Say what you will, MS agrees with me. NT is simply not the most stable OS out there. And Linux, as accepted by every study not paid for by MS, is more stable than NT. Therefore, wouldn't it be ideal to get the integration offered by NT with the stability offered by Linux?

What should be happening then, is all of us, as integrators, engineers, etc. should be telling MS that we want communication that is truly open.
Not open to other windows platforms, but open like TCP/IP is open. If MS would define a standard for interoperability that isn't closed behind NDA's and licensing entanglement, we would see a matching component for Linux, and all would be good with the world. We could paint our faces and change our names to Sky...... You know the rest of this rant.

In any event, Linux users and programmers would love to see MS open up something that would let us communicate with their office software. I
prefer Linux on a machine because it is more stable. That is a simple fact. Why can't I get it to cooperate with a MS package? Ask MS.

--Joe Jansen
 
M

Michael Griffin

At 13:21 09/07/01 -0400, [email protected] wrote:
&lt;clip>
>The other approach is to try to make the same operating platform work for
>both worlds. The people that are successful at that get a huge gain,
>because they have a much tighter integration between controls and the
>enterprise. The cost of doing business is lower because there is less work
>required to integrate the information flow. The cost of support is less
>because there isn't a need to have a separate group of people to support
>the controls operating platform.
&lt;clip>

If I understand your thesis correctly, you are suggesting that in order to have efficient communications between the production machinery and the rest of the company, all production machines should use PC style computers with identical operating systems, which are also identical to the operating systems used in the office.
Without addressing the issue of what that particular operating system should be, I would like to say that I don't see this approach as
being practical. First, I don't see how such a situation could be established (except possibly in the case of an entirely new or re-built
plant). Secondly, I don't see how such a situation could be sustained over the long run.

I could describe the situation in a typical plant which makes this so, but I don't think it is necessary. We are all familiar with how any plant is a collection of machines of various ages and origins. In other words, in any normal plant, variety is a fact of life. You can (and should) try to limit it on the new equipment which you have custom built, but you will always have exceptions.

Furthermore, the office computing system will be subject to change without notice, and without reference to whatever engineering plans you may have made. I think you have grossly oversimplified the office software systems in your statements. The ERP software which runs your business (e.g. SAP) may be hosted on a computer system on another continent, and those computers may be - what? A mainframe? A collection of Unix boxes? Who knows? That hardware and operating system choice is up to the company which is
running the computer centre, not you or I.

Given this situation, there will always be a need to translate and interpret the data between various incompatable systems. Therefore, if a universal "sameness" of systems is not realistic, why make it a criteria?

You mention an example of a design engineer wanting to get data or someone in accounting wanting the order status from the production machinery. This is a subject I have researched in detail, and I can assure you that the ability to see a sensor state is utterly useless to these people.
Each machine needs individual programming to convert the particular logic states into common abstract concepts, there must be suitable
application software to record the data and present it in a form which the users can understand, and there must be a means to connect the two together. Of these three areas, the third (communications) is in almost all cases the
easiest to solve and has been solved many times already. If you wish to connect a Windows system to a production machine, then you use a suitable
OPC server. The OPC server talks whatever communications protocol is required, and the actual operating system used (if any) in the machine is irrelevant.

In any large engineering project which I am familiar with, the first step is to break the overall project down into smaller pieces. Each piece should be as independent from the others as possible. The interfaces between them should be simple, well defined, and stable over time.
In the example we are talking about, what a customer would really want is one or more common communications protocols, NOT a common operating system. A seamless enterprise is not much use if it isn't a flexible one. Flexibility in this case means the ability to deal with things that weren't in your original plan. Any system which depends upon a snapshot of what
exists today, will be obsolete and abandoned before long.


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

Kenneth E. Woodard Jr.

The argument to link the enterprise to the control systems can have great benefits to the enterprise? There is no real requirment for them to be on the same operating system, with the interconnectivity tools available today. It would be nice for someone in the industry to come forward with some case studies that compare or establish the savings of conversion to a M$
enterprise from an M$ entrprise using LINX or QNX or ?

Regards,
Ken
 
Good points.

I do not expect an existing site to be standardized on one technology, computing or otherwise. Even with a new site you will have vendors or situations that force a break from the standard. Nevertheless, it makes good sense to standardize as much as you can. My philosophy is to use as much off-the-shelf computing equipment as possible. I am also following the direction I see the commercial automation software market going.

Computers aren't everything and won't be everything. PLCs are still a useful technology that warrants use.
 
C
Yes there are some lines of business that can benefit from data flow into the enterprise system. But is is ridiculous to infer that you need NT for that and it provides cost savings and a more robust solution. I think all of my UNIX and Linux customers would strongly disagree.
That is predicated on an all Microsoft world and that is hardly the case. That will be a self fulfilling prophecy if monopolization is allowed to continue, but many systems that are true enterprise systems are not Microsoft systems for reasons of robustness if not cost. These
systems provide a great deal more flexibility than Microsoft systems because they will work with other systems as well. Actually the trend
is towards more diversity rather than less. The point on talent I find rather humorous. I would sell my stock in your company if you have the
MCSE's looking after your control systems. I get most of my private business from people who "don't need professional administrators".

Regards

cww
 
C
There are lots of case studies, unfortunately they tend to be post decision support. That is, whatever we decided on, now that we finally got it working, must be the best in the world. Weren't we smart? I have seen the reality and case study and sometimes it would be hard to recognize that they were the same project. And
there are a lot of infotisements, you know those things that look like a magazine or may be in a magazine. Some well known companies even publish their own magazine. You will never see a comparison between their largest advertiser and a free system, no matter how robust. For example, try to find Linux information in the automation
trade press. If they have it at all it is seldom comparative. Even the people who do analysis clearly show who comissioned the study.
Propaganda is alive and well.

Regards

cww
 
What I have found is that NT integrates with NT better than Linux does. I have also found that if I have two operating systems to support then I need two talent pools. Is that understandable?

I made a good living implementing UNIX and Linux solutions. But once I gave NT a fair chance I found that it worked well. And, by using it I had the luxury of having so many software and hardware options that my life was made much easier. I also believe that the ability to interface with the enterprise is highly important. No, I don't think the CEO needs to see the status of a sensor. I never said that. I said that I find that NT provides me with a less expensive, more robust interface to the enterprise. I see NT, the software tools that are available today, and TCP enabled devices as a much needed key to closing the supply chain loop through the plant floor.
 
B
Even for you this is sort of unfair. It would be pointless to compare a system that is actually usable by virtually everyone to a system that can
only be used by a very small group of very skilled people. The ABs of the world are not competing against Linux, because its really no competition right now. The cost-benefit ratio is so far towards AB (at least for general purpose PLCs) that it would be like comparing an ox cart to a modern diesel truck.

Until there is a softplc like piece of software that runs on Linux, AB does not have to worry about the tiny little piece of the market that they are losing to Linux.

Bob Peterson
 
I

Icayan, Erwin

I believe that you are mistaken about the qualities of NT to interface to the enterprise system. IBM DB2 and Oracle 8.1 on LINUX have outperformed these same databases on any current MS platform. This is the main interface to the enterprise, MES, or MRP systems. The cost is also less. There are benchmark tests available in various sites like IBM.

Erwin Icayan
 
M

Michael Griffin

At 11:52 11/07/01 -0400, [email protected] wrote:
&lt;clip>
>What I have found is that NT integrates with NT better than Linux does.
&lt;clip>
I have heard this statement from several sources, only more generally phrased as "NT integrates with NT better than with non-NT", rather than just exluding "Linux". I wonder if you could explain this in more detail, keeping in mind that the subject is "M$ vs Linux in Automation", not "Windows vs. Linux in Accounting"? How does this affect my ability to
collect cycle time values from a machine tool (we are obviously not talking about I/O networking)?

While I expect to hear dark mutterings from Mr. Wuollet about "NT doesn't integrate well with other products" I am surprised when I hear about NT integration problems from people who *like* Windows NT.

To make this subject a bit less nebulous, I will give us an example application we can make reference to. Suppose I purchase a production
machine as a finished product from an OEM. Let us also suppose the application program which runs this machine has a feature in it which provides information which I want to monitor. (If the application doesn't do this, then there is no reason to try to communicate).

Now, if the method the machine uses to communicate with outside systems is a standard industrial protocol (e.g. Modbus TCP), then what
difference does the operating system (if any) it uses make? Or rather, do you have something else entirely different in mind when you say "integration"?

**********************
Michael Griffin
London, Ont. Canada
**********************
 
hello
Do you work in the IT department or the I&C. If you are in automation (I&C) then you are unlucky to have OS as your burden. However, if you are in IT and still have to maintain two talent pools for two OS's, it is really very sad. Linux training is available for peanuts and the same people who maintain the other OS's can maintain Linux.

Linux is not very tough. Try installing Linux, Red Hat Installation (i would recommend 7.1 as i have used it), it is a cake walk. You can even hire Linux experts for a couple of days and maintain linux systems.

Linux integrates well with NT. Linux is not just an operating system. You get a ftp server, a mail server, httpd server, c/c++ programming tools,
graphics manipulation tools, and much more. Your good programmer can use these tools and make life really easier for you. I will agree here that the
tools may not be as user friendly or popular as Windows programming tools, but they are for free and that much reason for trying to use them. The
argument that you get more with NT for less is no longer, a valid one.

The issue why NT or Linux should figure on this Automation list is not weather Microsoft is out there to make dollars, or Linus is a saint giving
goodies for free. The automation lot has paid for simple DOS and UNIX based systems through their nose and then some more for bug fixing and upgrades which would make Microsoft seem a charitable organization. And the Automation industry can afford to pay much more for systems provided they have their uses.

NT, it is well known now has to undergo a boot cycle in 90 days. I have seen applications hang in NT and you get a Dr. Watson error message, which I find difficult to diagnose. And you are then unable to start the required service (Say a DDE driver). Which means that though your SCADA application is working and your OS is running, you cannot use the system. Worse still is the fact that the operator gets the same temperatures and pressures shown on the screens, if he is not alert and has skipped the Dr. Watson Message your
plant is in "heap big trouble senor". Now the system needs a reboot (after losing sleep on three consecutive nights and traveling 20 minutes to site on a midnight, I made a written procedure which explained how to reboot the system. the username and password were written down on the procedure so that people at site could do it). If your implementation is poor then you will see some production loss or trip in this scenario. In my case though the implementation was goos, two operators had to go to site near the
"converters" to read the temperatures, as the temperatures were coming from a MTL, 8000 series MUX-Demux on Modbus system and connected to the COM port. Plus another one to the back of panel instruments.

In the case of Linux, you could kill the process and start another process for I/O handling. Thus the SCADA on Linux would start showing real time
values. Reboot is unnecessary unless you have allowed some trojan or worm entry into your system. Following proper guidelines, you can ensure that the need for reboots is avoided. This means a lot for I&C fellows. Of course the front end applications need to have robustness built on them otherwise the solidity of Linux is lost.

I have also seen a popular OCS system Hang on HP-UX, and we had to reboot the operator interface.
Once Linux, has many installations in I&C, then the real issues will come forward. OS is robust, but robust applications are needed to make Linux in Automation a real alternative.

Anyway, as I have already written in the list before, to me the issue of OS is not a necessarily I&C discussion. We are forced to take the OS given by our I&C vendor. The end user still thinks in terms of the SCADA from
Rosemount or SCADA from Moore or the PLC from Allen Bradley and so on. OS is less than 5 % of our business, though it is very important. I would
generally opt for a robust Operating system, which does not hang or give other problems.

Anand k Iyer
 
S

Sam Moore Square D Company/Groupe Shneid

Michael Griffin wrote:

>At 11:52 11/07/01 -0400, [email protected] wrote:
>>
>>What I have found is that NT integrates with NT better than Linux does.
>
>I have heard this statement from several sources, only more
>generally phrased as "NT integrates with NT better than with non-NT",
rather
>than just exluding "Linux". I wonder if you could explain this in more
>detail, keeping in mind that the subject is "M$ vs Linux in Automation",
not
>"Windows vs. Linux in Accounting"? How does this affect my ability to
>collect cycle time values from a machine tool (we are obviously not
talking
>about I/O networking)?

I find more tools for interfacing with I/O on NT then I do Linux. In that sense it is easier to interface to I/O.

>While I expect to hear dark mutterings from Mr. Wuollet about "NT
>doesn't integrate well with other products" I am surprised when I hear
about
>NT integration problems from people who *like* Windows NT.
>
>To make this subject a bit less nebulous, I will give us an example
>application we can make reference to. Suppose I purchase a production
>machine as a finished product from an OEM. Let us also suppose the
>application program which runs this machine has a feature in it which
>provides information which I want to monitor. (If the application doesn't
do
>this, then there is no reason to try to communicate).

Once you have a documented standard you can specify the standard with your vendors. Like a lot of people have stated you should arrange to get the source (not to the operating system but the application). We go to the point of specifying the protocols and data formats that will be used.

I am not saying that you will always get a vanilla plant, but you try.

>Now, if the method the machine uses to communicate with outside
>systems is a standard industrial protocol (e.g. Modbus TCP), then what
>difference does the operating system (if any) it uses make? Or rather, do
>you have something else entirely different in mind when you say
"integration"?

If I am getting a computer as part of a machine then I want the computer to run the operating system that my people (or a lot of contractors) know how to support. Depending on the project we may specify an interface of ModbusTCP, OPC or SQL. We use a COM object at the ModbusTCP interface point.

Once you have the data in the NT environment, COM, then it is very easy to drive the data into desktop applications or custom applications that we have written.

If we used Linux on the plant floor then we would have automation software tools to pick from. It would not be feasible to try to get the data
directly into COM. We would then drive the data into an SQL server and access it from the NT desktop. This is an okay arrangement it is just less flexible.

If I used Linux on the desktop I would probably use it on the plant floor. I drove a company to use UNIX on all desktops. The first was the
DECstation. DEC discontinued the architecture after a couple of years. I then standardized on SPARCstations. I then switched to Linux and then very soon after that I switched to NT.

My staff kept coming in with a lot of frustration. They wanted to use the same applications they used at home. When I was using DEC and Sun computers I told them to go buy a $5000 computer for their home. No one did. When I
started Linux I setup an install disk and tried to support their computers at home. This was a huge failure.

The mistake I made was driving the business by the selection of the technology. There was no question that UNIX was better. I think that Linux
is better at core operating system functions than NT. However, *for me* this benefit is purely technical and if you look at the entire picture NT
is the way to go.

Just an opinion.
 
C
> Even for you this is sort of unfair. It would be pointless to compare a
> system that is actually usable by virtually everyone to a system that can
> only be used by a very small group of very skilled people.

Actually, it is unfair to continue spreading the FUD that our system is only usable by gurus. No basis.

> The ABs of the
> world are not competing against Linux, because its really no competition
> right now. The cost-benefit ratio is so far towards AB (at least for general
> purpose PLCs) that it would be like comparing an ox cart to a modern diesel
> truck.

More FUD, no basis.

> Until there is a softplc like piece of software that runs on Linux, AB does
> not have to worry about the tiny little piece of the market that they are
> losing to Linux.

That much is true, but we weren't talking about what AB worries about, we were talking about the availability of objective information. The trade
press is demonstrably and obviously biased towards solutions that involve advertisers.

Regards

cww
 
Top