- You are here:
- Home >
- "I'm not dead yet!"
"I'm not dead yet!"
I should have known better. I make one minor reference in a Blog to a Monty Python script and what do I get? Allegations that every one of my blogs will have Python/Dr Who/Stargate references in, that’s what. Well perhaps this one will, perhaps not.
As I’m approaching Middle Age from the wrong side, I thought I’d take a trip down Memory Lane and talk about obsolescence. That’s component obsolescence by the way, not me.
As I’ve hinted in past blogs, I’m an old g**. I was doing my apprenticeship when TTL first came on the scene (not even that new-fangled LS stuff) and I’ve been designing ever since. I was working in the Defence sector for a lot of that time and we were typically being asked to do designs for equipment having a 25-year in-service date. That’s where the problems begin. Getting a component vendor to guarantee continued supply over that sort of period is about as easy as finding a Double Glazing company who’ll still be in business by the time your guarantee runs out. The typical way round this obsolescence problem was to have huge stocks of components stockpiled as lifetime all-time-buys just in case any one of the components in the BOM popped 6 years downstream. Hardly the most cost-effective way to do things….
In a number of cases, the better way to approach an obsolescence problem in existing equipment is to look at duplicating the functionality that the obsolete part provided and design a form, fit and function replacement. That may mean that you need to do a level of design proving, but you do have your replacement strategy.
The next logical step on from that as a fix and one that I’ve encouraged for (many, many) years is Design for Obsolescence . Simply put, the designer accepts that specific components aren’t going to be around for life and, as long as the budget and reliability requirements allow, designs accordingly .
That’s it for now. Next week, 'How To Recognise Different Trees From Quite A Long Way Away’
By Ray
