LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

OS updates for production test platforms

This is not a LabVIEW question as it is a general test software question. I work in the aerospace industry where the production lifetime of a part can be 20 years or longer. Many production test sets in my lab use old PCs with old OS versions. These test sets use standard GPIB communication with standard instruments like power supplies, DMMs, etc. So there is no need to support old custom hardware with old drivers. The old PCs cannot use new tools like TortoiseSVN or newer versions of LabVIEW or TestStand. They also have a lot of trouble with networking. Some do not even have USB ports so you must use 3.5" floppies.

 

My question is this: should production test sets use the same standard PCs that are used in the office, and updated every three years, or is it better to let the system stay static forever? In the short term, you save time migrating the old software to a new PC or OS. In the long term you create a support nightmare with multiple versions of ancient OS. Is there a rule of thumb as to which way to go?

 

0 Kudos
Message 1 of 6
(2,359 Views)

@joshxdr wrote:

This is not a LabVIEW question as it is a general test software question. I work in the aerospace industry where the production lifetime of a part can be 20 years or longer. Many production test sets in my lab use old PCs with old OS versions. These test sets use standard GPIB communication with standard instruments like power supplies, DMMs, etc. So there is no need to support old custom hardware with old drivers. The old PCs cannot use new tools like TortoiseSVN or newer versions of LabVIEW or TestStand. They also have a lot of trouble with networking. Some do not even have USB ports so you must use 3.5" floppies.

 

My question is this: should production test sets use the same standard PCs that are used in the office, and updated every three years, or is it better to let the system stay static forever? In the short term, you save time migrating the old software to a new PC or OS. In the long term you create a support nightmare with multiple versions of ancient OS. Is there a rule of thumb as to which way to go?

 


Actually, I think I'd blend the two ideas.  Keep it as static as possible for reliability and consistency, but when things like OS or hardware end of life threaten peace and harmony, it's a prime time to update everything that needs to be updated.  It will be no picnic because you will have to play the compatibilty game between drivers, LV and OS versions.  Remember that all this stuff can (and probably will) create a lot of timing and thread processing changes, especially when going from pre-LV 7 to post-LV 7.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 6
(2,346 Views)

My initial response would be: If it's not broken, don't fix it.

 

Personally I do not see the reasoning behind automatic upgrades every three years even for office desktop systems.

 

But of course new versions of LabView are unable to run on anything older than Windows XP, so you can always use that to drive upgrades if management needs justification.

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 6
(2,344 Views)

My experience is that everything breaks, or requires upgrading, it is a matter of time. So it is really a question of do you try to proactively invest in upgrades so that repair/debugging/upgrading is easier down the road, or do you just stand pat and hope nothing bad happens. The first path is hard to justify on a pure cost/benefit basis, and the second seems to be courting disaster.

 

0 Kudos
Message 4 of 6
(2,334 Views)

My experience is that things are constantly changing anyways.  At certain steps, you really should try to do some upgrades.  But this upgrade effort should only be on one machine (leaving the rest alone) until the development is complete.  Then upgrade one machine at a time, taking care of any bugs you run into along the way.  If you have enough systems at your office, you will get a large majority of the bugs figured out by the time you go to upgrade customer systems.

 

I also have a tendency of locating really old bugs during this effort, which might be another reason to push for an upgrade.  Now, every 3 years sounds a little excessive.  But working on 10-year-old computers is a nightmare.  I would push for the upgrades every 5 years or maybe slightly longer.  It depends on how stable the OS is (XP lasted an extremely long time).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 6
(2,326 Views)

The answer is in your companies long term support plan (Sometimes called continuing engineering).  Yes, you need one.  Equipment, Parts, OS's and Networks become obsolete.  It is a fact of how the world works.  Your production process needs to account for it and take proactive steps to prvent major downtime when this nightmare happens.  (Oh if I had a nickle for every time I heard this one-  Actually, I probably DOSmiley Surprised)

 

Boss:  "Hey Maintanence Guys, Tester XYZ is reporting an error and the line is down.  Go fix it."

M-G: "Boss, It looks like after 20 years of service, Thingy x1529 from Doohickys-R-Us failed.  DRU went out of business 15 years ago. you can't buy Thingy x1529s anywhere."

Boss: "You mean It can't be fixed?  We won't be able to deliver product on time?"

Upper Managment: "Why didn't we have plan in place 15 years ago? we should have seen this comming."

 


"Should be" isn't "Is" -Jay
Message 6 of 6
(2,319 Views)