Housework

Home improvement work has been consuming much time.  The basement is a total redo, so we're hiring it out, but we're trying to figure out where we can cut costs.  This has meant taking out all the bad stuff, then scrubbing and bleaching what is left.  Also, looking at the lie of the land around that house to prevent future problems with water.  So last week I built a little retaining wall around our garden on the south face of the house; a small project to be sure, but getting any one thing actually accomplished is much more difficult than I originally expected.  Also, we're going to try to do some of the non-skill stuff like painting and hanging shelves in the closet.

Also, the garden continues to surprise me in a good way.  We have four small green tomatoes on the vine on one of our tomato plants, some strawberries, and lots of yummy herbs: oregano, chives, rosemary, thyme, and basil.  Hopefully, come August, we'll have another bumper crop of tomatoes to support my BLT addiction.  

12:37 AM

From time to time I get sleepless nights. It's not really unpleasant, but my mind just races from one thing to the next until the middle of the night. Today it was racing over some wild claims about software reliability based on random testing made by some folks I know a couple of years back. At the time, I couldn't come up with why the idea seemed really far fetched, but now I think I have it.

First of all, what is software reliability? My fuzzy 1 AM definition is that it is the probability that the software will behave correctly (i.e., meet its requirements) in its intended environment. It is the last part that is the sticky wicket.

Embedded software is always dependent on the environment. You can't perform very meaningful statistics (e.g., reliability) on something without understanding the distribution of the data that you're working on. For embedded software, this is manifest on the choice of input values that describe the "environment" that the software is supposed to control. Often, people use a normal or random distribution to describe inputs, but this is specious for several reasons:

1. In a "real" system, the inputs tend to constrain each other's value. So, if P is true, then Q is likely true also. Due to errors or failures in sensors / hardware problems / general nastiness, you usually can't *always* assume this will be the case, but if you're trying to describe software reliability using random testing, then you should usually (but not always) obey a complex set of restrictions on inputs
2. The constraints on inputs change over time. This change is due to some "world model" that is not visible to the software. You may be able to approximate it (in fact, you may use the state of the software to approximate it), but this is one of the hardest things to get right when writing control software. It's one of the main reasons that control software is necessary in the first place. Matt Jaffe wrote a paper back in the late 80s where he characterized control software errors; one of the top ones on the list was a disconnect between the actual state of the process and the perceived state of the process by the software. Very little has changed in this regard since Jaffe's paper; we still don't know how to monitor the actual state of the process.
   

Unless you can be sure you've got your world model right, you know very little about the reliability of the software in that environment.

Suppose you're trying to dock the space shuttle at the ISS (this is a problem that Mats Heimdahl's group at UMN looked at a couple years back). There is a quite complex mode machine that describes the behavior of the shuttle as it approaches the ISS bounded by certain conditions on the environment. The mode controller has, if I remember correctly, something like 10^20 states (that is, 100,000,000,000,000,000,000 states), so you're not going to be able to just get lucky with random test. Furthermore, the inputs are mode-dependent, so as you approach the ISS different Boolean input variables will "trip" if you've entered the next smaller region of the state space. Additionally, the input values for distance, attitude, speed, etc. are directly related to the mode of the machine; for example, if you are very close, then you should be going very slow.

In the intended environment, the variables tend to line up like pearls on a string, and those pearls have to move in a coordinated fashion for a significant period of time. In order to test the most critical code, which executes when the shuttle is very close to the ISS, this complex input history must match just so, or the controller will abort.

If you throw this at a random search tool, it completely falls flat; it isn't able to get out of the initial mode, even after thousands upon thousands of tests. Claiming that after you've run a million random tests you some level of confidence in your software is *obviously* wrong when you consider the intended environment. In the case of the docking procedure, you won't even execute 90% of the code. Furthermore, a numeric level of reliability *outside* the intended environment is meaningless, unless you really want to try to use your ISS docking procedure to control a toaster.

Planes, Bikes, and Automobiles

I've been riding the roller coaster for the last 5 days or so, and I now I think it's time to get off. On Thursday, I found myself facing a 150 mile bike ride (the MS-150) on Saturday despite not having gotten the bike out of the garage this year. Not only that, but the weekend weather was expected to be stormy with a significant headwind. Not only that, but I had to fly out to Dayton, OH on Sunday for a business trip post the 75 mile second leg. Not only that, but we were supposed to squeeze in a visit with some friends post-ride pre-flight.

Thursday was a rough day. I made a panicky run to the local bike shop to get a tune up and some new pedals and 'trained' by riding around the block a couple of times. Friday morning I got up, packed for the ride, packed for my Dayton trip, went to work, then drove up to Duluth with Kim. Despite all odds, the bike trip didn't kill me, and I met my original sponsorship goal (thanks very much sponsors!) The weather held out and I had a great time, aside from a very sore derriere.

After finishing Sunday, I ran home, showered, swapped suitcases, and was back out the door within 30 minutes (a new record). We hung out with Dave, Becky, and Marcellus Krueger for a few hours, including a perfectly-timed and theraputic hot tub soak, then ran off to the airport for travel leg #2.

Off to scenic Dayton, OH, home of the narrowest stretch of interstate in the contiguous United States. Seriously, I felt like I had driven into the Death Star trench scene. They've been doing road construction on I-70 for at least the last three years and it seems to get worse each trip. You get your two lanes, each big enough for a Mini Cooper, with no shoulder, threaded between two 7' concrete barriers whose damage and streaks provide ample reminders of previous accidents. Add a steady stream of semis and a little rain and you have a drive that is guaranteed to keep you wide awake, even after a red-eye.

My meeting wasn't until 1:00 PM so I slept in on Monday until 8:30 - ah, the decadence! After a little bit of coding & checking in with the mother ship, I headed off to WPAFB. Despite a few wrong turns (including an embarrassing U-turn at the wrong gate after talking to a somewhat excitable gentleman from the Air Force), I reached the meeting about 20 minutes early. It went well, though I was trying to stifle yawns due to my whacked out schedule.

This morning I got up at 5:00 AM to fly back, but I have been denied. I made it through the I-70 trench and was feeling pretty good about life as I pulled close to the airport. But then...

There are many reasons that the Dayton airport sucks, but today I'll focus on three in particular:

1. There are no gas stations to fill up your rental car near the airport
2. There is no full-time ticketing agent at the Northwest counter
3. There are TWO Hertz rental care return sites approximately 2 miles apart and the first one that you are directed to by the airport signage is NOT the "airport" Hertz.

Combine 1, 2, and 3 and a balky credit card that could not be read by the self check-in kiosk and you have a recipe for disaster. After missing my flight, I have the whole day to experience the various and (I'm certain) superlative pleasures of the Dayton airport. Without an available ticketing agent, it is not even possible to rail at the injustice of the situation except to you, dear readers. Apparently there will be an agent here later, so I'm sure I'll get home though probably a little lighter in the pocket book.

Hopefully things will calm down a bit this week and I'll get a little bit better handle on life.