Sunday, August 22, 2021

Will the Kessler Syndrome Put an End to GPS and Other Satellite-Based Applications?

Sputnik 1 was launched on October 4, 1957 one day after my 6th birthday, with little thought to the long-term problem of space debris.

Figure 1 - The launch of Sputnik 1 by the Russians on October 4, 1957, on top of an R-7 ICBM rocket, launched the Space Age.

Figure 2 - Sputnik 1 was a sphere 23 inches in diameter that fell back to Earth and burned up on January 4, 1958 just a few months after its launch.

Figure 3 - Since then we have launched thousands of things into orbit around the Earth and have left behind huge amounts of space junk all traveling at speeds greater than 18,000 miles/hour.

The Kessler Syndrome
In 1978, NASA scientist Donald Kessler first proposed that as the number of objects in orbit about the Earth increased, we could one day reach a level of criticality as we do in nuclear weapons. Recall that when a sufficient number of U-235 atoms are brought close together, a chain reaction can be initiated that quickly fissions large numbers of U-235 nuclei resulting in a very powerful explosion. Similarly, Donald Kessler proposed that when a great number of orbiting objects reached a level of sufficient criticality, the collision of two large objects could result in an orbiting debris field of high-velocity space bullets that could then collide with other orbiting objects. This would then generate a larger and ever-increasing orbital debris field of space bullets in an exponential manner, initiating a chain reaction that would slowly destroy large numbers of satellites and ultimately make it impossible to safely operate any satellites in orbit. Such a dire orbital situation is called the Kessler Syndrome in honor of Donald Kessler.

In response to this threat, the European Space Agency has proposed a number of preventive measures that should be adopted by the entire world that could greatly reduce the amount of space debris circling the Earth.

Figure 4 - Above is a comparison of how the Earth would look in 2209 if the European Space Agency measures were followed compared to what it would look like if no measures were taken.

For more on the European Space Agency's efforts to limit space debris, see:
https://www.esa.int/Safety_Security/Space_Debris

Here is an interactive link that shows all of the large objects currently in orbit about the Earth.
http://stuffin.space/

Here is a YouTube by Anton Petrov explaining that the Kessler Syndrome may be closer than we think.

Another Satellite Collided in Space, But Everyone Missed It Until Now
https://www.youtube.com/watch?v=ACF893aAN8s

Lost in Space - My Sad Adventures with Supporting a Satellite-Based Application
All of the above brings back some dark memories. In 1995, I was invited to join Amoco's ARSTA project. At the time, Amoco had about 10,000 gas stations, mostly in the midwest. These gas stations processed credit card transactions over landlines that were owned and operated by the Montgomery Wards department store chain. Each gas station had a dedicated modem connected to the closest Montgomery Wards store. When a customer swiped a credit card in a CRIND (Card Reader In Dispenser) on a gas pump, the transaction was first sent to a minicomputer in the gas station. If everything was up and running, the credit card transactions then went over the modem to the closest Montgomery Wards store. From the Montgomery Wards store, the credit card transactions then went to the credit card companies over the dedicated landlines run by Montgomery Wards. The credit card companies could then validate the credit card transactions and send back transactions for us to begin pumping gas. That all took just a few seconds and the CRIND would then display a BEGIN PUMPING prompt for the customer to go to work filling his tank. But if anything went wrong in the communications chain, the gas station minicomputer could store about 1,000 credit card transactions locally on a disk drive so that customers could still use a credit card for payment. However, in such situations, the validation of credit card transactions could not take place, and the local gas station just batched up the pending transactions on disk until communications were re-established.

The purpose of the ARSTA project was to replace the landlines with satellite communications. A satellite dish was placed on each gas station and pointed to a geosynchronous satellite. Transactions from the gas station were then sent up to the geosynchronous satellite. From the geosynchronous satellite, the credit card transactions were then sent back down to a large earth-based mother dish at Amoco's Tulsa Research Center. From the Tulsa Research Center, the credit card transactions were then sent to a fault-tolerant Stratus minicomputer at the Tulsa Data Center. The fault-tolerant Stratus minicomputer had redundant backups for all of the minicomputer components, such as a backup motherboard, power supply and batteries. The Stratus minicomputer ran some custom queue-based software written for us by a consulting company. This queue-based Stratus software ran 20 processing queues to handle the incoming and outgoing credit card transaction load and fed the transactions to some COBOL/CICS software running on the IBM mainframes in the Tulsa Data Center that interacted with the credit card companies over dedicated landlines. Each of the 20 Stratus queues had a switch that could turn the queue on and off to throttle the transaction load that the Stratus was processing. I had the unfortunate experience of joining the ARSTA Stratus support team just when the project started to go awry.

This architecture worked great for the first 5,000 gas stations. But after the first 5,000 gas stations, the whole architecture began to periodically display some nonlinear behaviors. The Stratus minicomputer software would suddenly freeze up and we would have to restart it to continue processing. During this freeze-up and restarting process, the gas stations would then all begin to batch up large numbers of credit card transactions on disk. So there was some sense of urgency while we were busily working on trying to bring the Stratus minicomputer back up because if a gas station tried to batch up more than 1,000 credit card transactions, the local minicomputer at the gas station would shut down the CRINDs and the gas station could no longer process credit cards for payment.

This was further complicated by the fact that the local gas station minicomputers would immediately try to send in all of their cached credit card transactions as soon as communications were re-established. The resulting surge in transactions would then cause the Stratus software to freeze up again. So we had to be very careful in bringing the Stratus back online by slowly opening the 20 Stratus processing queues one at a time. This allowed us to throttle the processing load on the Stratus as each new processing queue was opened up. We had to let the processing surge from each newly opened processing queue settle down before opening the next processing queue. It could take about two hours to open all 20 queues. Unfortunately, many times as we slowly got to queue number 18, 19 or 20, the whole thing would collapse again and we would have to start all over! Even with all of this ongoing turmoil, we still had another 5,000 gas stations to go, come hell or high water! So the ARSTA Project Managers in charge of installing ARSTA dishes at gas stations relentlessly continued on with their work no matter what, and we continued to add a few hundred new gas stations to the ARSTA satellite network each week!

Now you have to admire the tenacity of Project Managers to overcome all obstacles in the way of their projects. For example, early one Tuesday morning, when I was in the IT department of United Airlines on September 11, 2001, I was returning from an early meeting with Change Management to get the final approval for a large upcoming weekend install. When I returned to my desk, I learned that one of United's airplanes had just crashed into the second tower of the World Trade Center in New York City and another United airplane had gone down in a field near Shanksville Pennsylvania under mysterious conditions. United Airlines, and all of the other airlines in the country, were then in the process of trying to land all of the commercial airplanes in the country all at the same time. Something that had never been done before in the history of commercial aviation. Shortly after that, I received a phone call from the Project Manager for the upcoming weekend install. The Project Manager then told me that the monumentally tragic events of the day must not interfere with his upcoming major install in any way. We must continue on as if nothing at all had happened! I then told the Project Manager that there was no way his install was going to take place on the upcoming weekend. United immediately started to lose about $700 million each week and two weeks later, 50% of United's IT department was laid off. A software freeze was instituted and only enough IT workers were retained to keep the lights on. Needless to say, that major weekend install never took place.

Unfortunately, such dramatic events did not unfold to prevent the ongoing relentless progress of the ARSTA project at Amoco. So we kept installing new ARSTA dishes at gas stations despite the failure of the ARSTA architecture to scale with increased load. How it all ended, I do not know, because like many other team members I was able to leave the ARSTA project after about 6 months of pure hell. I imagine that the Time Invariant Peter Principle that I first introduced in Hierarchiology and the Phenomenon of Self-Organizing Organizational Collapse played a significant role.

The Time Invariant Peter Principle: In a hierarchy, successful subordinates tell their superiors what their superiors want to hear, while unsuccessful subordinates try to tell their superiors what their superiors need to hear. Only successful subordinates are promoted within a hierarchy, and eventually, all levels of a hierarchy will tend to become solely occupied by successful subordinates who only tell their superiors what their superiors want to hear.

The scariest thing about the Kessler Syndrome is that nearly all IT business partners take no heed of the physical laws of the Universe. So the fact that all of your satellites may have been destroyed by the Kessler Syndrome one day would not quell their irate demands to immediately bring up their satellite application. For example, satellite systems are prone to "rain fade". Rain fade results from the fact that water molecules love the microwaves used for communicating with satellites. Microwaves oscillate with the same frequency as do water molecules, so water molecules love to absorb microwaves and turn them into heat. That's how your microwave oven works. So when ARSTA had the entire Chicagoland area covered by a heavy rainstorm, the microwaves from the Chicagoland gas stations could not get up to the geosynchronous satellite nor could they get back down because of rain fade. Once the storm subsided, all of the gas stations would then flood our Stratus minicomputer with an overload of cached credit card transactions. I had no luck explaining this "rain fade" electromagnetic fact of life to our irate business partners using Maxwell's Equations! So much for Physics 341...

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston

Sunday, August 01, 2021

Do Not Fear the Software Singularity

Most people seem to be totally oblivious to the coming Software Singularity, that time in the near future when advanced AI software will be able to write itself and enter into a never-ending infinite loop of self-improvement, resulting in an Intelligence Explosion. The reason I say that is because it seems that the whole world is still fighting over all of the little bugs in Civilization 1.0 that we have been fighting over for the past 4,000 years, ever since Civilization 1.0 was first released. As I pointed out in Is it Finally Time to Reboot Civilization with a New Release?, we will certainly need to start running a new Civilization 2.0 release after the Software Singularity because, by that time, Civilization 1.0 will certainly have reached an end-of-support state. In fact, the Software Singularity will be so dramatic that Civilization 1.0 will quickly decay into an end-of-life state in which it can no longer even boot up properly. As we all know, migrating to a new release of an operating system is always traumatic, even with great project management efforts and a good deal of migration planning and preparation. Unfortunately, the migration from Civilization 1.0 to Civilization 2.0 at the time of the Software Singularity will most likely not be planned at all. As with most things in the chaotic real-world of human affairs, it will just happen, and things like that do not usually go very well. For more on that see The Economics of the Coming Software Singularity and The Danger of Tyranny in the Age of Software.

Worse yet, the one thing that we know for sure is that during the past 10-billion-year history of our galaxy, no other form of carbon-based Intelligence has ever been able to survive long enough to see the Software Singularity come to be. Otherwise, they would already be here demonstrating what an Intelligence Explosion can really do. There are no physical laws preventing an Intelligence Explosion blasting through the entire galaxy. And we are so close.

Those in the know seem to fall into two camps. Some think the Software Singularity will be great, while others fear that it may not. In the most worried camp, Elon Musk naturally stands out:

"I Tried Warning You For Years, No One Listened" - Elon Musk
https://www.youtube.com/watch?v=olFtJ3q5bEM

Our Suspenseful Race to the Finish Line
In Why Do Carbon-Based Intelligences Always Seem to Snuff Themselves Out? and Can We Make the Transition From the Anthropocene to the Machineocene?, we further discussed my Null Result Hypothesis, first proposed in The Deadly Dangerous Dance of Carbon-Based Intelligence. The Null Result Hypothesis is an unfortunate explanation for Fermi's Paradox that proposes that all carbon-based Intelligences always do themselves in because they are all victims of the very same mechanisms that bring forth carbon-based Intelligences in the first place. In the simplest of terms, the Darwinian mechanisms of inheritance, innovation and natural selection always require several billions of years of theft and murder to bring forth a carbon-based Intelligence. All indications seem to demonstrate that carbon-based life should be found on hundreds of billions of worlds around our galaxy, but one can certainly make the case that carbon-based Intelligences are quite rare because it takes a very lengthy list of fortunate twists and turns to bring them about. For more on that see The Bootstrapping Algorithm of Carbon-Based Life. So the idea that these very rare carbon-based Intelligences always do themselves in may not be so farfetched. For more on that see Is Self-Replicating Information Inherently Self-Destructive?. Here is the latest news on that front:

IPCC Sixth Climate Assessment. Will this one make the blindest bit of difference?
https://www.youtube.com/watch?v=2Zax9XTHUlo

At our current rate of self-destruction, it is very doubtful that any human beings will be around in 200 years. The geological record does show that all species do eventually go extinct. My contention is that our very last chance just might be for advanced AI to save us from ourselves in a post-Software-Singularity world. Or perhaps advanced AI would do us all in or allow us to quietly pass into oblivion by neglect.

Conclusion
It really depends on what kind of legacy we wish to leave behind. Do we wish to leave behind nothing at all like all of the other countless galactic carbon-based Intelligences of the past? Or would it be better to take a chance and allow advanced AI Machines to take our place? Perhaps we might even end up merging with the Machines in a parasitic/symbiotic manner like all previous forms of self-replicating information. For more on that see A Brief History of Self-Replicating Information.

Comments are welcome at scj333@sbcglobal.net

To see all posts on softwarephysics in reverse order go to:
https://softwarephysics.blogspot.com/

Regards,
Steve Johnston