{"id":176,"date":"2009-07-28T21:32:35","date_gmt":"2009-07-29T04:32:35","guid":{"rendered":"http:\/\/35.225.155.113\/blog\/index.php\/2009\/07\/28\/mission_critical\/"},"modified":"2019-10-13T13:10:32","modified_gmt":"2019-10-13T20:10:32","slug":"mission-critical","status":"publish","type":"post","link":"https:\/\/www.weinstein.org\/blog\/index.php\/2009\/07\/mission-critical.html","title":{"rendered":"Mission Critical"},"content":{"rendered":"

Over the past week plenty of commentary
\nhas been made, including my own<\/a>, in relation to the 40th
\nanniversary of the historic flight of Apollo 11<\/a>. One comment on
\nTwitter by alexr<\/a>
\nhowever caught my specific attention, “SW
\nengineers should take this moment to consider if they’d trust their
\ncode to have gotten the LM onto the lunar surface safely.”<\/p>\n

Indeed a sobering thought at first
\nglance. In this day and age it is quite common to run into a program
\nwritten by one or more software engineers that seems unstable or
\nerror-prone. What if all those engineers had to deal with the rigors
\nof getting their code “flight ready” where billions of dollars
\nand at least 2 men’s lives at risk?<\/p>\n

But on second thought I think this
\ncomment does more harm than good. It seems to imply that either;
\nthe challenges of writing critically important, life-and-death
\nsoftware only occurs once in a blue moon1<\/sup><\/a>
\nor that the good-old-days of elite superman programmers who wrote
\nerror-free programs are long since gone, replaced by thousands of
\nmediocre programmers writing millions of bug-infested computer code.<\/p>\n

Instances of life-or-death situations
\nbeing directed by computers (hardware and software) might not be an
\neveryday occurrence for a programmer, or even a once in a career
\noccurrence. But it does still occur. I recall the Professor who
\ntaught my Assembly Language<\/a> class in college mentioning his work on a
\nproject for Motorola on a car fuel-injection<\/a> system. The engine had
\nhabit of shutting down when entering the presence of electrical
\ninterference.<\/p>\n

Just imagine driving down a highway at
\n55 mph only to have your car shutdown while passing by some
\nhigh-tension power lines….. Now consider the added complexity of
\ntoday’s hybrid engines<\/a>.<\/p>\n

And while not every programming
\nchallenge is “life-and-death”, plenty of software code in today’s world is “mission critical” with millions, if not
\nbillions, of dollars at stake.2<\/sup><\/a><\/p>\n

In any case the coding of the Lunar Module<\/a>‘s
\nsoftware was hardly error-free. In fact in regards to the Apollo 11
\nmoon landing two specific instances occurred with the Eagle’s
\nGuidance Computer<\/a> during the critical decent to the moon’s surface.
\n

\nAt 102:38:30 Neil Armstrong calls out<\/a> a program alarm, “1202”. Ten seconds later,
\nArmstrong is asking for feedback from Houston on the error
\ncode.3<\/sup><\/a>
\nHouston gives the astronauts a “go” to continue their decent.
\nBut less than 5 minutes later, with 2000 feet separating the LM from
\nthe surface the ship’s computer issues a “1201”.<\/p>\n

\n
\n

\n

102:42:13<\/b> Armstrong<\/i>: (on-board): Okay. 3000 at 70. <\/p>\n

\n102:42:17<\/b> Aldrin<\/i>: Roger. Understand. Go for landing. 3000 feet.<\/p>\n

\n

102:42:19<\/b> Duke<\/i>: Copy.\n<\/p>\n

\n

102:42:19<\/b> Aldrin<\/i>: Program Alarm. (Pause) 1201\n<\/p>\n

\n

102:42:24<\/b> Armstrong<\/i>: 1201. (Pause) (On-board) Okay, 2000 at 50.\n<\/p>\n

\n

102:42:25<\/b> Duke<\/i>: Roger. 1201 alarm. (Pause) We’re Go. Same type. We’re Go.<\/p>\n

\n<\/blockquote>\n<\/div>\n

Second round of system issues.<\/i><\/center><\/p>\n

What was a 1201 and 1202 type error<\/a>?
\nOnly that the Apollo Guidance Computer was indicating that it was
\noverloaded with data inputs, couldn’t keep up and was resetting
\nitself.<\/p>\n

Yeap, that’s right, the guidance
\ncomputer for the LM rebooted, at least twice, during one of the most critical phases of the mission because
\nit ran out of memory.<\/p>\n

The problem? An error in one of the
\ncrew’s check lists had them turn on the rendezvous radar during the
\nlanding phase. Of course the LM crew was hardly trying to rendezvous
\nwith the Command Module<\/a> during their decent, but the repeated calls
\nto the computer to process imaginary rendezvous radar data filled up
\nthe limited writable computer memory4<\/sup><\/a>
\nthe on-board system had, causing the system to repeatedly restart.<\/p>\n

Now I suppose somebody will argue that
\nthe computer was hardly to blame. It was a user-generated error
\nturning on the rendezvous radar (or a documentation error) not a
\ncomputer programmer error. Moreover the program was designed to
\nreset itself if it got overloaded on purpose.5<\/sup><\/a><\/p>\n

But, that’s just it. No programmer, not
\nmatter how good, can take into account every possible error or
\nmisuse, whether created by the programmer or the user.6<\/sup><\/a> Would you have
\nconsidered at first that an over-head power line might scramble your
\ncar’s fuel injection system?<\/p>\n

This is where the programming concept
\nof fault-tolerant<\/a> programming comes into play. The idea is pretty
\nbasic; enable the system to continue operating properly in the event
\nof an error. Just as the Apollo spacecraft (and Saturn V<\/a>
\nlauncher) had mechanical backups to keep the physical system running
\nin case of failure the guidance program (and properly designed
\nprograms of today) manage the error and keep it from causing
\ncatastrophic results.<\/p>\n

Thus the statement should not be, engineers consider if you’d trust your code to get the LM to
\nand from the moon safely. Instead it is, do you consider your
\nsoftware fault-tolerant enough to get one to the moon and back
\nsafely?<\/p>\n

\n

Interesting side note there is a community programming effort that has created a software emulator<\/a> of the Apollo hardware and software, Virtual AGC and AGS<\/a>.
\n  <\/p>\n

\n
\n

1<\/a> Pardon
\nthe pun.<\/p>\n<\/div>\n

\n

2<\/a> And by indirect implication the lives of the employees, customers, stockholders,
\net al.<\/p>\n

\n<\/div>\n

\n

3<\/a> Sounds
\neerily familiar for any modern day computer user; the computer reports some
\ncryptic error code and the next step is to go searching for
\nadditional information on what’s gone wrong.<\/p>\n<\/div>\n

\n

4<\/a> Now
\na days we classify memory as Read-Only Memory (ROM) or Random Access
\nMemory (RAM) and talk about Gigabytes<\/a> (109<\/sup>) of RAM for a laptop (or even a
\nsmartphone). The Apollo Guidance Computer? About 64 Kilobytes<\/a> (103<\/sup>) of ROM
\nand only 2 Kilobytes of writable RAM.<\/p>\n<\/div>\n

\n

5<\/a> The idea was to clear the fault and reestablish import tasks, i.e.
\nclear out the waiting calls for calculating unnecessary rendezvous
\ntelemetry and reestablish jobs for processing landing telemetry.<\/p>\n<\/div>\n

\n

6<\/a> And just in case you wish to insist that the programmers of yesteryear were superman, well turns out one uncorrected bug<\/a> could have crashed the LM by trying to flying the craft first “under” the surface then back “over” the surface and then “onto” the surface for a safe landing.<\/p>\n

\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Over the past week plenty of commentary has been made, including my own, in relation to the 40th anniversary of the historic flight of Apollo 11. One comment on Twitter by alexr however caught my specific attention, “SW engineers should take this moment to consider if they’d trust their code to have gotten the LM […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[92,117,118],"tags":[202,201,196,199,200,203,78,190,7,43,106,146],"_links":{"self":[{"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/176"}],"collection":[{"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=176"}],"version-history":[{"count":3,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/176\/revisions"}],"predecessor-version":[{"id":735,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/posts\/176\/revisions\/735"}],"wp:attachment":[{"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=176"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=176"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.weinstein.org\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=176"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}