ASTi Logo

Telestra FAQ

How is ASTi planning for obsolescence issues and long-term support on major programs?

Provision for 25 Year Support Spares Inventory

Most major programs request a guarantee of support between 15 and 25 years. So what does that mean? A requirement to support the system for 25 years is an eternity in terms of technology. The reality is that this represents something like 5 technological life-cycles.

Is it reasonable to expect support today for a COTS system that was fielded in 1985? Clearly the only way that one could truly contemplate replacement or repair for an Intel 286 motherboard and five inch floppy drive today, would be if either ASTi or the customer had put a substantial inventory of equipment aside to guarantee the availability of parts.

So, let's start with a sparing projection for such a situation. View the MTBF's for the Telestra system Line Replaceable Units (LRU)

Alternatively a good rule-of-thumb to follow: for large programs with many installations and a combination of distributed and centralized spares-holding, our recommendation usually comes to 10-15% of the system cost. (The higher figure represents a greater level of assurance and protection against some mass extinction event like a power surge, which would consume several decades worth of spares in a single incident.) So is it reasonable to just do the MTBF maths for your particular system and spare accordingly for a 25 year life-cycle?

This is a complex subjective evaluation:

  • If you anticipate being able to cannibalize equipment being rotated out of service as the program contracts, then the lower spares holding predicted entirely by the MTBF might be reasonable.
  • On the other hand, if it is a successful program, perhaps all the trainers might remain in service.

Given the low cost of spares, if the program really is serious about supporting the existing configuration for more than 20 years, then it clearly justifies erring on the high side in terms of sparing costs in order to keep a multi-million dollar trainer operational.

However, the reality is that this NEVER happens. And that is because in the real world, if a program is successful enough to still be operational then 5-10 years later it will undergo a mid-life technology refresh. So rather than sparing for two and a half decades, including the possibility of a "Black Swan" event, the issue becomes constructing a support program to ensure that obsolescence of the communications system does not become a driving force in establishing the date for such a mid-life update.

A Mid-life Technology Refresh

As you are aware, ASTi continues to have a great on-going track-record of supporting our earlier generations of equipment through careful selection of critical components and an aggressive approach to end-of-life purchases. So the more practical objective then is to find a reasonable spares holding, sufficient to prevent the necessity of performing another upgrade within a reasonable period. Something like 10 years would be reasonable, because as we've seen above, laying in spares and holding them sufficiently to guarantee supportability for 25 years is almost certainly a waste of money.

When we contemplate any kind of refresh of the communications system we have to consider the two major components: Telestra and Audio Distribution.

Telestra

The Telestra is a fairly standard industrial grade PC running Linux. This is important because it means that, unlike Windows, there are no potential license violation issues in porting the software to a later PC platform. In addition, we already provide our development environment as a fully virtualized 'machine' (VM) allowing nearly any OS to host and run our VM. The virtualized environment mimics all the IO interfaces required by the application. Assuming the current trend supporting virtualization continues (and it is hard to see how this would not), it is perfectly reasonable to assume that a PC computing platform in 10 years time will be fully capable of running a VM of the ASTi Telestra server software - this concept would protect against the necessity to update the running simulation model to the "latest" software version. While there may be other reasons to update (desired functionality needed), virtualizing the Telestra server, would allow the "as-is" model to run without modification - the only concern would perhaps be to confirm the intrinsic system performance in terms of latencies. However it would not be unreasonable to assume to that a PC in 10 years hence will provide "blazing" performance figures and therefore negate any such concern.

Audio Distribution

There are currently no plans to replace the current ACE Communication Units (ACU2 and ACE-RIU) as an audio distribution mechanism but looking forward a decade or more means that such an evolution must be taken into account. However, with over 7,000 total systems fielded ASTi can state that it is our intent that ACENet will continue to be a supported protocol for future evolutions of the Telestra until such time that it becomes irrelevant to our customer base. Therefore the customer would always have the option to upgrade the Telestra platform while retaining the legacy ACU audio distribution.

It should also be remembered that since the ACENet devices are ASTi-sourced design, manufactured by ourselves, we continuously monitor our bill of materials for any 'end-of-life' issues. Should we be faced with a key component becoming obsolete, not only would we build and stock significant quantities of this item, we would alert our customer base and determine whether their remaining spares holding was adequate or should be supplemented with an additional 'end-of-life' buy. Old DACS DSP customers can attest to the fact that this kind of reassurance is not just empty rhetoric, since we managed to support the manufacture of DSP cards for almost ten years after the key chip became obsolete.