Engineering Effectiveness (was Communication protocols)

M

Thread Starter

Michael Griffin

At 13:40 18/08/00 -0400, Dave Ferguson wrote:
<clip>
>By "full time IT person" I mean that new users, security, HMI and
>DCS revisions, PLC automated backup system, server tape
>backups, user "help desk" issues, network management (software
>and hardware) etc.
>
>Like most management people I work with and for, you seem to
>think that because it is "automated" means that it just sets up and
>runs itself.
<clip>

I am quite well aware of what is involved in automated systems. I will also say that I have the impression that you seem to be doing a lot of
routine work that probably duplicates the efforts of your computer department.
Can your IT department handle the user account administration, tape backups, etc. remotely over your network? This is routine work for them. The "help desk" issues - are these something special for the MMI or DCS system, or are these general Windows issues? If the latter, then again can your "IT" department handle this?
Your IT department of course can't handle changes to the MMI or DCS software, but then this is not "IT" work by any stretch of the imagination.


>To add a loop in the field or change a calibration requires a huge
>outlay of personell time that management needs to realize.
>
>For instance to change the range of a level loop requires, the actual
>recalibration, documentation, DCS database revision, graphics
>revisions, links to upper level range change, database change in
>upper level system, graphics changes in upper level system and
>documentation, drafting, data sheets etc. THIS DOES NOT
>HAPPEN AUTOMATICALLY.

Except that adding or re-ranging an instrument is not something that can be considered an "IT" activity, or related to Windows NT in any way. I was curious as to what sort of full time "IT" type work it was you found
yourself doing.

>Managers better wake up and realize that this gets done with my
>salary not 100 small PLC's.

The 100 small PLCs example was intended to put the cost of routine "IT" type activities in perspective. If using 100 PCs in control activities requires the full time administrative efforts of one person to deal with Windows NT problems, that would be far too much unproductive effort for my situation. Perhaps your circumstances are different, I am certainly in no
position to judge.
I'm not saying that you are not working hard at what you are doing, I'm just wondering why it is you have to work so hard to maintain something. 100 small PLCs don't require any IT type maintenance at all. Perhaps though I am misinterpreting what you said about doing "full time IT" type work for the production related PCs.

I was going to give you a long story on how I reached my point of view, but I've erased that, and I'll just give you the summary.
We found ourselves in our own operations continually making minor program (and other) changes to machines to accomodate new models, changes to existing products, adjust timers values, etc. Several years ago we came to
realise that if we kept doing what we were doing, we would be spending all our time on routine tasks, rather than concentrating on making actual
improvements and preparing for new business. We had a choice of either keep doing what we were doing, only do it harder, or to change course and
approach things differently. We chose the latter.

This wasn't an upper management or business consultant head in the clouds sort of decision. Upper management was oblivious to the problem. This was actually forced on management by a few engineering staff who wouldn't take no for an answer.
We can't roll back the clock, but we can stop repeating our mistakes. New equipment, and retrofits to existing equipment are designed
from the perspective of minimising engineering and maintenance involvement in "routine" tasks. As a simple example, if there is a timer in the program whose preset may possibly need to be adjusted then there is a screen on the OP (operator panel) which can be used to adjust it. If it needs changing, the operator changes it on the spot.
We're not perfect or in any way exemplary by any means. We have though (at least most of us) realised that we have a problem and are
changing our ways of doing things.

I will perhaps give you a more involved example. I am currently working on a project to automatically extract production statistics (down
time, cycle time, etc.) from our production equipment and make it available to whomever may need it. I have received some very invaluable help in this project from other members of this list whom I cannot thank enough.
One of my definite criteria in this project is that the system must require as little initial configuration as possible, and minimal subsequent engineering administration. There will be no additional personnel dedicated to routine maintenance of this system. If this could not be achieved, then the project would be dropped until such time as it can.

To achieve this, I identified several areas which needed to be addressed:
1) Any new computers required (which will run the application software) will be give to our "IT" department to look after. They already
worry about things like operating system upgrades, back ups, hardware maintenance, back up power, adding and removing user accounts, network
nonsense, etc. They can very efficiently handle another piece of hardware and the user account administration. To ensure they do look after it, I want to physically locate it in their server room. They are quite agreeable to this, and in fact seem to be delighted that someone actually wants to talk to them.

2) There must be no special software to be installed on users' computers in order for them to get at the data and reports. It must be "web deployed". This is the route which certain office type software is taking, so our IT department already installs web browsers on all computers.

3) I want to use the existing office type ethernet network to connect production lines to the application server (hence my search for an
ethernet gateway - particularly one which doesn't require much configuration). I don't want to run my own network cabling and re-route it every time the production floor is rearranged.

4) The application software must be easy to use and flexible enough to allow users to manipulate the data in ways which suit their own needs. I don't want to have to be creating new report screens every time someone has an idea for a special report.

5) All components of the system (except of course PLC program modifications) are to be off the shelf. I don't want to develop anything.
This is not something which is a core technology for us. We just want to better identify where to make production efficiency improvments.

6) The initial system must be able to be scaled up to cover the entire plant by simply adding more of the same hardware and software. My
initial prototype can be handed as a working example (together with a complete implementation report) to outside contractors to expand it later,
or perhaps I can do it myself gradually.


I could go on, but I think you get the general idea. I think I could whip something together myself for less money, but that only looks at the initial outlay, not the recurring costs. The recurring costs are not just the cost of my salary, but the opportunity cost of not concentrating on doing the things I do best. I am not using my time effectively if I duplicate the efforts of other people. I am not saving my company any money if I create a system that cannot be maintained without my constant efforts.


>My entire point was that NT works if you know what you are doing
>just like AB works if you know what you are doing or Fisher-
>Rosemount works if you know what you are doing or UNIX works if
>you know what you are doing. Usually not liking something comes
>from not taking the time to learn it.
<clip>

I believe though that we already discussed the fact that Windows NT takes a considerable level of skill to be truly proficient at getting it to work properly. I have also noted that you appear to be one of the few people who are able to routinely do so. You certainly sound to be much better at this than I am.

Why however is it that I can pull a PLC right out of the box and use it but most people can't do that with a PC that cost several times as much? Is there an operating system somewhere inside a Siemens PLC? I don't know, do you? If there is, I've never had to tune it. There certainly is one for a PC, and if you are using one called Windows NT you have to jump through
hoops before you can even begin to worry about your application.
It is the application after all that that you bought the PLC or PC for. The only justification for even having an operating system is to provide routine services for the application software. The operating system
should be irrelevent but it seems to be the thing that everyone is complaining about. Why is that?

I've asked a major and very reputable industrial PC manufacturer about how Windows NT could be made to interact with their hardware. They don't know anything about Windows except how to stick the CD-ROM in. Are they stupid? I don't think so, but Windows NT seems to be just as big a
mystery to them as it is to everyone else. Why is this?

Something seems to be fundamentally wrong with the computer systems we are using. I renamed this divergent thread "Engineering Effectiveness"
because I don't think we are making effective use of our time if we are worrying about operating system problems. If I want to worry about Windows
problems, then I'm in the wrong business.



**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
D

Dave Ferguson

> I am quite well aware of what is involved in automated systems. I
>will also say that I have the impression that you seem to be doing a lot
of
>routine work that probably duplicates the efforts of your computer
department.
> Can your IT department handle the user account administration,
tape
>backups, etc. remotely over your network? This is routine work for them.
The
>"help desk" issues - are these something special for the MMI or DCS
system,
>or are these general Windows issues? If the latter, then again can your
"IT"
>department handle this?
> Your IT department of course can't handle changes to the MMI or
DCS
>software, but then this is not "IT" work by any stretch of the
imagination.

I agree with you on this issue but our problem is that the IT dept is very small and has always been a mainframe "business" environment and has not had to deal until very recently with "real time responses". What we found was they were not as worried about taking the network down with a misconfigured machine or switch because while their users screemed, we continued to make
paper. This of course is changing but unfortunately their dept. remains the same size. In our case this is a management issue whereby the IT dept would have to be changed in order to provide 24/7 response etc. This is happening
but very slowly, in the mean time, yes a couple of us are stuck tesing cables and doing server backups etc. as well as process updates and
engineering. On the one hand it is a duplication of efforts, on the other hand we are very good at many things (opinion not fact) and I would not
trade the "handyman" knowledge for anything (maybe this is why there are issues with noone knowing anything anymore and counting on so many vendors) I am not sure.........I am glad I knew DOS when I went to windows and I am glad I knew 3.0 when I went to 3.1 and 3.11 and 95, 98 NT 3.0, 3.1 etc...........I knew where it came from so I understood the changes to the system.

>>For instance to change the range of a level loop requires, the actual
>>recalibration, documentation, DCS database revision, graphics
>>revisions, links to upper level range change, database change in
>>upper level system, graphics changes in upper level system and
>>documentation, drafting, data sheets etc. THIS DOES NOT
>>HAPPEN AUTOMATICALLY.
>
> Except that adding or re-ranging an instrument is not something
that
>can be considered an "IT" activity, or related to Windows NT in any way.
I
>was curious as to what sort of full time "IT" type work it was you found
>yourself doing.

My point here was that as we are pushing information to these IT types of systems we are running into IT/engineering issues of "change management". This is the constant battle of Engineering vs IT. I personally think that we
are merging in the middle in a muddled grey area that hasn't quite shook out yet. But for me and I tell my managers this all the time........."There is no point in spending effort on counting widgets that we did not make"..............In other words Optimize the process first and then count or monitor its quality but make them right first..........(Engineering)

> I was going to give you a long story on how I reached my point
of
>view, but I've erased that, and I'll just give you the summary.
> We found ourselves in our own operations continually making
minor
>program (and other) changes to machines to accomodate new models,
changes to
>existing products, adjust timers values, etc. Several years ago we came
to
>realise that if we kept doing what we were doing, we would be spending
all
>our time on routine tasks, rather than concentrating on making actual
>improvements and preparing for new business. We had a choice of either
keep
>doing what we were doing, only do it harder, or to change course and
>approach things differently. We chose the latter.

We wrestle (sp) with this all the time, unfortunately that ever widening grey area is eating up time.......

> I will perhaps give you a more involved example. I am currently
>working on a project to automatically extract production statistics
(down
>time, cycle time, etc.) from our production equipment and make it
available
>to whomever may need it. I have received some very invaluable help in
this
>project from other members of this list whom I cannot thank enough.
> One of my definite criteria in this project is that the system
must
>require as little initial configuration as possible, and minimal
subsequent
>engineering administration. There will be no additional personnel
dedicated
>to routine maintenance of this system. If this could not be achieved,
then
>the project would be dropped until such time as it can.
>
> To achieve this, I identified several areas which needed to be
>addressed:
> 1) Any new computers required (which will run the application
>software) will be give to our "IT" department to look after. They
already
>worry about things like operating system upgrades, back ups, hardware
>maintenance, back up power, adding and removing user accounts, network
>nonsense, etc. They can very efficiently handle another piece of
hardware
>and the user account administration. To ensure they do look after it, I
want
>to physically locate it in their server room. They are quite agreeable
to
>this, and in fact seem to be delighted that someone actually wants to
talk
>to them.
>
> 2) There must be no special software to be installed on users'
>computers in order for them to get at the data and reports. It must be
"web
>deployed". This is the route which certain office type software is
taking,
>so our IT department already installs web browsers on all computers.
>
> 3) I want to use the existing office type ethernet network to
>connect production lines to the application server (hence my search for
an
>ethernet gateway - particularly one which doesn't require much
>configuration). I don't want to run my own network cabling and re-route
it
>every time the production floor is rearranged.
>
> 4) The application software must be easy to use and flexible
enough
>to allow users to manipulate the data in ways which suit their own
needs. I
>don't want to have to be creating new report screens every time someone
has
>an idea for a special report.
>
> 5) All components of the system (except of course PLC program
>modifications) are to be off the shelf. I don't want to develop
anything.
>This is not something which is a core technology for us. We just want to
>better identify where to make production efficiency improvments.
>
> 6) The initial system must be able to be scaled up to cover the
>entire plant by simply adding more of the same hardware and software. My
>initial prototype can be handed as a working example (together with a
>complete implementation report) to outside contractors to expand it
later,
>or perhaps I can do it myself gradually.

We have been working on a similar effort for the last 5-7 years and it has helped a lot and it was kind of my point with the Inernet not going away
reference. We have built some fairly advanced diagnostic systems that self monitor the process and e-mail, page and cell call when something goes
wrong. We set up the criteria that we would monitor every day and then let the system notify us. This system won some Microsoft Windows World Open awards as well as Rockwell Soft Automation awards. Today they are relatively routine systems but that is because of advances in the technology and communications in my opinion......

> Why however is it that I can pull a PLC right out of the box and
use
>it but most people can't do that with a PC that cost several times as
much?
>Is there an operating system somewhere inside a Siemens PLC? I don't
know,
>do you? If there is, I've never had to tune it. There certainly is one
for a
>PC, and if you are using one called Windows NT you have to jump through
>hoops before you can even begin to worry about your application.
> It is the application after all that that you bought the PLC or
PC
>for. The only justification for even having an operating system is to
>provide routine services for the application software. The operating
system
>should be irrellavent but it seems to be the thing that everyone is
>complaining about. Why is that?

I think that as I tryed to explain (but not very well apparently) that in my opinion the computer is like one of those "Leathermen" 10 tools in one
things. Where as a PLC is like the screwdriver in the leatherman. The PC was not designed to be "Controls" only box. It was designed to allow the
secretary to do memo's and the accountant to use spreadsheets and the engineer to do complex 3D and the Controls guy to control his machine.
Unfortunately with those all in one tools, if I need to cut tile, I can do it but not very well.

I think that as one of the new sections of this Leatherman is the control arena, there are vendors and Microsoft partners that are showing them the need for us to have a better knife in this toolbox and it is improving. Unfortunately you have to know a lot more about the box and OS to tweak it for the function you want. If it just had the "knife" option like a PLC, it would be a lot easier to understand and optimize.

As I tried to say but again not very well, I am a believer and have been for quite a while in the need for "one window" and I never thought it was going to be possible but think that like it or hate it, the Internet browser may be that Window or some concoction of it. As I said I do not care if my information is on a UNIX box, NT box etc. I just want it. I just want the info, I don't care where it comes from. Unfortunately as I "don't care" more and more I eventually don't understand the underlying technology that brings me the info. And as a designer of these systems I get to the point where I must count on more and more vendors to help me accomplish things.

> Something seems to be fundamentally wrong with the computer
systems
>we are using. I renamed this divergent thread "Engineering
Effectiveness"
>because I don't think we are making effective use of our time if we are
>worrying about operating system problems. If I want to worry about
Windows
>problems, then I'm in the wrong business.

Unfortunately as this is becoming (and we could argue all day) the defacto standard and as I said it is a "Leatherman tool" you need to know how to
Optimize it for what you are trying to accomplish. Again this is the problem with trying to make "one box fit all". And the same goes for Linux or anything else. Everyone raves over "Open" source code but I am not a C++
programmer or a good VB programmer or a good machine code programmer etc. So having the source code or being able to modify it to me is even less
desirable because (my point) I don't know the first thing without laying out the effort to learn it, about rewriting the code to optimize it for myself. (I hope that came out right).

I enjoy the discussion, I apologize for the spelling mistakes, I am on a handheld and trying to type while on vacation at the cabin and being
distracted by darn fish biting, what a problem to have.

I think we are somewhat on the same page and I agree that if I could and it is getting better, I would push the IT functions to the IT dept. time will tell for me. Hopefully the grey area shakes out, in the meantime our company has created what is called the "Systems Groups" that kind of live in that grey area until it shakes out...........We deal with everything and yes we
duplicate efforts but we are at least making the others focus more on these issues because they are now worried for their jobs.......Good vs evil ?? (Management decision)

Dave Ferguson
Blandin Paper Company
UPM-Kymmene
DAVCO Automation
 
M

Michael Griffin

>I agree with you on this issue but our problem is that the IT dept is very
>small and has always been a mainframe "business" environment and has not had
>to deal until very recently with "real time responses". What we found was
>they were not as worried about taking the network down with a misconfigured
>machine or switch because while their users screemed, we continued to make
>paper.
<clip>
Our own IT department has had to evolve because of pressure from the need for continuous and reliable SAP access for production control as we have cut our average inventory levels. Our network and general computer systems are much more reliable today than they were 5 years ago. The pressure for this though didn't have to come from engineering. I'm not going to change the way they work, so I try not to get too far ahead of them.
We have a few pieces of equipment (test systems) which need network access to log data. They are however designed to continue to operate locally if the network is down, and to resume logging data when the network comes back up. I haven't been directly involved in this particular project, so I can't say how well it has worked in practice. The objective though is to make the system tolerant of network problems. Fortunately for us, the office network is not a critical part of the process. The production machines will
still continue to run without it. We intend to keep it this way.

As we consider things such as automatic production statistics collection or engineering document managment (drawings, PLC programs, etc.)
for our own use though we've also come to realise that maintainance and administration are things that have to be considered right from the
beginning. These things take as much careful planning and consideration of long term costs as a good machine design does. However, these are things which most people in our business are not used to dealing with.

>I am glad I knew DOS when I went to windows and I am glad I knew 3.0 when I
>went to 3.1 and 3.11 and 95, 98 NT 3.0, 3.1 etc...........I knew where it
>came from so I understood the changes to the system.
<clip>
The nice thing about DOS was that it was simple enough that it was easy to figure out how it worked without making a career out of it. CP/M
wasn't much different. UCSD P-System was more sophisticated, but still understandable.
Windows though, is another story. This morning I had to reconfigure the network access for my computer (Windows 95 laptop) based on some vague general directions from our IT department (tbey were busy with the rest of a big network change, and couldn't remember exactly how to do it for Windows 95). After I was finished, I could see that what I accomplished was actually fairly simple, but Windows seems to have turned it into something much more obscure and complex than it really needed to be.

>I think that as I tryed to explain (but not very well apparently) that in my
>opinion the computer is like one of those "Leathermen" 10 tools in one
>things. Where as a PLC is like the screwdriver in the leatherman. The PC was
>not designed to be "Controls" only box. It was designed to allow the
>secretary to do memo's and the accountant to use spreadsheets and the
>engineer to do complex 3D and the Controls guy to control his machine.
>Unfortunatelly with those all in one tools, if I need to cut tile, I can do
>it but not very well.
<clip>
It's too bad that someone can't come out with a "better" Windows - at least better for me. I would guess that all of my PC applications could
be solved by a simple standard system that was designed with industrial test systems in mind. I would gladly sacrifice performance for reliability and ease of maintenance. Someone could probably make a very nice business for
themselves selling to people like me. Unfortunately someone can't do that - at least not with Windows.


>And the same goes for Linux or
>anything else. Everyone raves over "Open" source code but I am not a C++
>programmer or a good VB programmer or a good machine code programmer etc. So
>having the source code or being able to modify it to me is even less
>desirable because (my point)
<clip>
I wouldn't want the source myself either. I have no interest in becoming an operating system hacker, at least not during working hours. I've written a few 10,000 - 15,000 line 'C' programs, but these were applications directed more closely to what I am supposed to be doing. I ought to be able to just *buy* an operating system that does what I want.
If someone like National Instruments packaged up a tested and pre-configured version of Linux with their Labview or other software, then I would be very interested in looking at it. Software for test equipment is something they do for a living, and they can spread their investment over a larger market than I can. They have a Linux version of Labview, but it seems
to be a version oriented to the academic market (limited number of drivers if I recall). So far I get the impression that they are still getting their feet wet in this area. It's something I need to think about though.

>I think we are somewhat on the same page and I agree that if I could and it
>is getting better, I would push the IT functions to the IT dept. time will
>tell for me. Hopefully the grey area shakes out, in the meantime our compnay
>has created what is called teh "Systems Groups" that kind of live in that
>grey area until it shakes out...........We deal with everything and yes we
>duplicate efforts but we are at least making the others focus more on these
>issues because they are now worried for their jobs.......Good vs evil ??
>(Management decision)
<clip>
If the factory floor and the office are to come closer together, I would say that the office needs to change as much (or more) than the
factory. If the "Systems Group" is a way of bringing people together from your IT and engineering groups it sounds like a good idea. Maybe it should be a permanent thing, not a temporary one. What I wouldn't want to do though
is end up taking on the IT department's job as well as my own.

I have an interesting story that is somewhat related to this. We installed SAP a few years ago (I managed to stay far away from this one). This project wasn't given to our IT department though. The IT department maintains the physical infrastructure, but the SAP group is separate. Also, the person put in charge of it wasn't a computer hacker, but a production
supervisor. He was of the hard driving no nonsense school (I'm sure we've all seen similar examples). This was all quite a novelty for us at the time. We expected to see him chewing up computers in frustration at not seeing things happen fast enough.
This group of course had all the technical support they needed within their group and from outside, and guidance from people who had done it all before. The point though was to keep them focused on serving production needs.
The people from production knew all about moving parts around and how customers can change their minds 10 times on each release. The computer
people know all about making computers do things. I believe that the concern was that if the project was simply handed over to the IT department it would take forever and end up as something which was of no use to anyone. Just
because someone knows a lot about computers and networks doesn't mean they know what those computers ought to be doing.

**********************
Michael Griffin
London, Ont. Canada
[email protected]
**********************
 
Top