Kindergarten neuroses

Ellen had her first day of school today and it went well.  It's hard to explain the foolish and strange feelings that I had during her first day of school.  

My own school experiences until college were at best mixed.  There is so much hope and ego and empathy wrapped up in that school experience; it defines us for a time, and any deep scars obtained take a long time to heal, if they ever do.  I remember my first grade teacher hitting me with a wooden paddle on the knuckles (corporal punishment was o.k. in Ohio), getting beat up almost every day in 6th grade, missing a good 1/3 of 7th and 8th grade due to problems with recurring pneumonia, and just trying to straddle the great divides between Jocks, Brains, Rockers, and Theater Geeks during high school.  

It (I?) was a mess, and it took me a good deal of college and graduate school to figure out that it was o.k. and even valuable to be who I was, even if none of the traditional labels fit.  

Now I am submitting my daughter to the same grind, and I wonder if I'm doing the right thing.  On the plus side, I believe it's a considerably upgraded grinder (espresso soy latte?) here in Edina, and Ellen's kindergarten teacher seems very nice.  I hope and pray that her experience is a less rocky one, and that she can navigate the shoals of fickle popularity to find true kindred spirits and to learn a good many things along the way.

Introducing...Anne Evelyn Whalen

We have a new baby!  Anne Evelyn was born at 2:41 PM on Saturday, July 19th.  She was 7 lbs 12 oz and 20" long.  Mom and baby are both doing great and sleeping a lot.  There are several pictures of the new babe out on my web site: www.cs.umn.edu/~whalen.  

Also, we're finally getting underway with the basement remodel, which is also exciting.  Between the baby, the basement, and the tomatoes, I feel like life keeps springing up from chaos; it's all very exciting.  

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.

Uff Da

Hello all,

We have had a "how deep does the rabbit hole go?" experience in our basement. Back in February, we had some water damage due to a backed up drain. So, we bought some carpet to be installed. Taking up the old carpet, we found two layers of tile, both of which contained asbestos. So we scheduled tile removal. Since we had to have all of our stuff out of the room, I decided it was time to remove the ugly wood paneling on the wall. Behind the paneling was moldy drywall. So, we removed the paneling and the drywall, ripped out the built in bar and bench seat, and are now sitting in a 21' by 19' box that, after today, should be down to the concrete, the studs, and the insulation. The only thing left is: do we replace the insulation? It may be moldy. We're going to have someone look at it this week.

Sigh.

I originally thought this was going to be a three week thing, get the carpet replaced and spruce the downstairs up a bit. Now, I'm not sure where it will end or how much it will cost. The joys of home ownership...

Good hack

They say that football is a game of inches; if so, model checking is a game of variables. The game is, essentially, how can I reduce the state of the model & shrink its representation?

Yesterday we were slightly past the edge of what can be analyzed in a reasonable amount of time using a BDD-based model checker. After looking at it a while, I came up with an optimization that removes one variable from a Simulink subsystem in a rather arcane clock mode. This one tweak made the difference; we got rid of 5 state variables and the model went through. It was, one of those rare (small) epiphanies -- a good hack.