Keeping Planes in the Sky and Satellites in Orbit

The idea came to me the other day as I was assigning a value to a variable in Java. I asked myself, “What units are being used for this variable?” Every number you enter into a programming language has some type of units associated with it. Some units are simple: feet, pounds, inches, meters. Other units are more complex: newton seconds, miles per hour, feet per second squared.

Why are units so important? Units are important because they make important calculations correct. They are especially important when more than one person is using the same piece of data. If we didn’t know the units being used in our code, we would be lucky to find out sooner than later. Here are some examples of major disasters that occurred because of improper understanding of units: Unit Mixups.  One example from that page is the loss of the Mars Climate Orbiter.  It crashed because systems involved each assumed different units for an impulse bit which caused the unit to lose it’s course and disintegrate in the atmosphere of Mars.  Another example from the non-programming world is the Korean Air MD-11 crash.  In this example, no software was at fault, but the same problem occurred.  There was a misunderstanding about meters versus feet.  The flight crew thought they were supposed to fly to 1,500 feet instead of the instructed 1,500 meters.  They lost control and crashed.

How do programmers deal with units in object-oriented programming?  The first way they do it is through documenting variables.  For example:

int height = 300; // feet

The next way they handle units is by encapsulating the variables and exposing methods that convert between units as the value is returned. Also, they include constants that help convert between units. For example:

private int height = 300; // feet
private static final float METERS_PER_FOOT = 0.3048;
public int getHeightInFeet() {
   return height;
}
pubic float getHeightInMeters() {
   return height * METERS_PER_FOOT;
}

Both of those techniques for communicating units have worked well. But, in mission critical applications, an engineer may want more assurances. This brings us to a wild and crazy idea. Variables have had three parts to them for all these years. First, the variable has a name. Second, it has a value. Third, (added recently) it has a type. Values are stored in “primitive” types (e.g. float, int, short, char, etc…). So, a variable with a value of 5 could really mean anything. What if we gave variables a fourth component? What if they had a component for units? Whoa, you say! I don’t want more boiler plate code! Then, you probably aren’t writing code that will be used for life support on the International Space Station. Because if I was writing code for those brave astronauts, I’d want all the checks I could put in my code.

Here’s an example of how it works. I haven’t perfected a syntax, so I’m using annotations as an example:

@units=(value="feet")
private int height = 300

Now you ask, “Why would I want to program in my units?” This is the most important question! Because the compiler can perform a type of static analysis on the code to find problems where you are assigning values in the wrong units to a variable. This sounds trivial, but it’s very profound. Here’s an example with a units error in it:

@units=(value="feet")
private int height = 300
@units=(value="second")
private int speed = 300
 
@units=(value="meters/second")
public float calculateMetersPerSecond() {
   return height / speed;  // this is returning the wrong units, i hope the compiler catches this
}

When the developer tries to compile the code above, it should generate an error saying that the function is trying to return meters per second, but the variables are identified as feet per second. It shouldn’t even compile, let alone take down a satellite!

This seems pretty amazing to me! I wish there was a nicer syntax for describing the units. I’m sure someone will think of one. Identifying units each time a variable is used would provide an extra layer of protection against engineering disasters. I think this idea could save lives. What do you think?

Update 8/16/2014: These types of annotations have been implemented in Java 8.  Java 8 allows annotations to be placed on type declarations.  Also, the Checker Framework has been developed which includes annotations for static analysis of units in Java 8.  That’s good news for future development of mission critical software development.

4 thoughts on “Keeping Planes in the Sky and Satellites in Orbit”

  1. I do like the use of annotations to validate units. I can see a lot of potential there.

    On the other hand, would unit tests be an even better method? It seems that for places where the units are important, unit tests would be better able to find problems.

    Also, are you thinking that *every* integer/float/etc. would have units? There are several cases where units aren’t necessary, like loop indexes and the size of an array, so would those be flagged as warnings or ignored?

  2. Mike, thanks for the response. You’re right that these annotations should be optional. Good point!

    Unit testing would definitely be an alternative. In fact, some people argue that good unit tests allow critical applications to be written in weakly typed languages. Personally, I prefer as many checks in my code as possible.

    I think this is just another tool for developers to use to prevent bugs. It’s important to pick the right tool for the job. If you’re making a small website, this is going to be overkill. But, if you’re launching a satellite or building a plane, this might save lives and your job.

  3. If only there were some sort of international system of units that we as a society could all agree on.

  4. This is all complicated by a problem of number precision and representation on a digital machine. If floating point was perfect and storage was infinite, then it would be easier to use consistent units. Instead, programmers are often forced to choose the unit that best fits the application and the available memory.

Comments are closed.