by Bruce Elbert
Anyone who either purchases or provides telecommunications services understands the importance of reliability – the confidence that the service will always be there when it’s needed. The popular song from 1970, The Big Yellow Taxi, sung by Joni Mitchell, tells us how we’re surprised when what we thought we had isn’t there. I’ve experienced a fiber outage due to the construction of a hotel (not pink like in the song but it did have a parking lot); it was across the street from our satellite control center. My organization planned for 100% backup fiber from AT&T, composed of two underground cables to separate switching centers. A cable cut wasn’t supposed to happen because the local telco had their inspector on the construction site with the underground drawing. Unfortunately, that plan was inaccurate and a backhoe cut a cable. Unbeknownst to the seller of this service, the alternate route actually went over the same cable! A senior technical executive with MCI (now part of Verizon) once defined this as a backhoe fade: “It’s deep, and it’s long”. Loss of communication between the control center and the Tracking, Telemetry and Control (TT&C sites left eight GEO satellites on their own for a day, until we restored service using a temporary backhaul satellite link.
Often the best time to arrange for backup and alternate paths is at project initiation. Cost will increase somewhat due to added time and material, but it will be much more to add it after the fact. Another bit of experience is that when installing new facilities, it could be attractive to keep an older facility in place as a backup. I’ve done this several times – in fact, this kind of backup might come for free.
 |
Satellite communications is the result of a systems engineering exercise in which backup and alternate routes would be part of the requirements. We can compute the reliability of service ahead of installation, based on component failure rates and how everything is connected. Redundancy is often desirable and it comes from extra internal components or externally as given above. The accuracy of classical reliability calculations can be questioned, so how do you use them? Simply stated, you can make comparisons between different arrangements based on computed reliability. Still, you have to apply your own knowledge and experience to qualify assumptions and the results. It’s like using Artificial Intelligence (AI) – ultimately, the decision on how to proceed is yours.
Systems engineering trade studies usually address three areas: performance (e.g., technical specifications), cost (on a life cycle basis), and schedule (time to project completion as well as time to money). To this we must add reliability and probably security. Rather than a three-legged stool, the systems engineer has to deal with five dimensions giving a polyhedron with five vertices and four sides – a square pyramid. That’s hard enough to visualize and even harder to get your arms around the trades.
Consider the two-dimensional graph in the previous page that simultaneously can show five dimensions – the spider diagram. You are comparing multiple ways of making the solution or system, and you need quantitative measures for each of the five areas cited above. Here is a simple example being used to compare say a three GEO satellite fleet with multiple MEO satellites for the same data requirements. All numbers are fictitious in this illustration and each of the concentric pentagons indicate higher measures (e.g., some are inverse values that need to be inverted before comparing to the others).
This spider graph helps us visualize the strengths and weaknesses of the different approaches. Assuming you have done the trades and picked a superior system that meets requirements, you still have lots of work in a normal development schedule. After this configuration is operational, we still need to be sure that the backup or alternate paths are there when needed. In my experience, the most effective way to do this is to actually use these backup means routinely during normal operation. You can split the traffic or send traffic over different paths so that all of the means are used at least daily. The fallback in case of failure is to take the unusable means off the table, or out of the network plan, as appropriate.
To make this real, let’s replay the title of this article – “You Don’t Know What You’ve Got Till It’s Gone.” I’ve been in circumstances that don’t subscribe to this concept. In one, an Asian customer employed a redundant uplink system to assure 100% reliability of the command of a satellite. The problem was that the staff never bothered to check the backup. One day, the primary failed and the uplink path to the satellite wasn’t there! Another example of the same issue is where the primary fails and but the backup works. This time, the staff left the uplink on the backup and did not bother to fix the primary. A future incident was catastrophic – again, no backup.
"...Satellite communications is the result of a systems engineering exercise in which backup and alternate routes would be part of the requirements..."
An old timer who came to us from AT&T Bell Labs had our systems engineers play what he called “what-if games”. This is where we describe how the system can work under different conditions, and what happens when elements fail or there isn’t a backup. A computer program can do a good job of examining performance under the myriad of possible component failures, but people are needed to apply common sense. The same process is followed when the system is represented by a digital twin to allow engineers to create failures scenarios and the software displays the impact. Isn’t it better to predict what failure will do rather than leave it up to chance? Don’t let the big yellow taxi roll over you. -----------------------
Bruce Elbert is the Founder and President of Application Technology Strategy LLC.(www.applicationstrategy.com) He is a satellite industry expert, communications engineer, project leader and consultant with over 50 years experience in communications and space-based systems in the public and private sectors. Areas of expertise include space segment design and operation in all orbit domains, systems architecture and engineering, ground segment systems engineering, development and operation, overall system performance improvement, and organizational development. He can be reached at: bruce@applicationstrategy.com