Mike Deliman

What's in a Kernel?

Recently my cohorts Paul Parkinson and Doug Gaff have been making a bit of noise about changes in the software industry - evolution of software, and specialized software for military and commercial avionics,and other applications that have strict time and security requirements.  Aside from requiring strict adherence to standards, critical systems software - especially medical or flight related - have an increasing litany of certification inspections it must pass.  In the secure-systems markets the same trend is evident.  Each of these markets are starting to require time- and space- critical systems.

Let me define time and space critical. 

Time critical is pretty straight forward - anything that has to be done within deadlines, is time critical. Sometimes time-critical functions are also periodic in nature, requiring periodic service with deadlines.

Space-critical is a bit more slippery.  This is about RAM, but not just "how much".  I'm talking about space in terms of RAM that other processes are protected from, and RAM that is protected from this process, and even memory shared between processes.

There are a lot of examples of time critical periodic applications.  Any aspect of handling telemetry - course, attitude, velocity, housekeeping (checking fluid levels, etc) - has time critical periodic attributes.   It's easy to think of time-critical tasks.

Space-critical is a little more elusive to both define and decide where to use, especially in embedded and real-time applications.  The answer to time-critical is somewhere between having fast enough hardware, efficient enough software, and proper scheduling. Protecting memory areas on a process-by-process basis has excellent benefits, but those benefits usually come at a cost of slower execution.    Sure, you never want your stack to be overflowed, your text to be zero-cleared, or your exception table to be  the victim of an uninitialized data pointer, but when is the trade-off in execution speed penalties worth the  overhead of enabling such protection?  The answer has more to do with security than with protection from poorly-debugged code - the separation, multiplexing, encoding, decoding and proper sorting of information streams.  There may be situations where every function of your application must have it's own data spaces because of the nature of the data being handled.  In fact, this kind of design is becoming more common.

It seems like it would take a fantastic amount of processing power to be able to do what's described above - guarantee on-time scheduling to handle deadlines, and mix-in varying levels of RAM-security, and still provide all the services and infrastructure necessary from an O.S. to build effective applications on-top of.  Even though processors are being created now with incredible horsepower, it wouldn't seem like they could keep up with much of this kind of work.  All that partition scheduling and context swapping would bog down the best of processors if it had more than just a few partitions and contexts to handle!

...or would it?

Come on down to the Regional Devlopers Conference in Manhattan Beach (Los Angeles) on May 24th, and we'll talk about it.  :-) See you there!

Test as you... surprise!

There's an old adage in the world of flight - space flight, or otherwise.

"Test as you fly, fly as you test."

It's pretty short and sweet and straight-forward.  Don't fly what you haven't tested.  Test exactly the ways you expect to fly.

In a big, round, wonderful world, it seems "funny" when we hear about problems related to living here.  Problems like aircraft "flipping over" when they crossed the equator because they were adjusting to negative latitude - the coder hadn't thought far enough ahead to think about crossing the equator.

This is the kind of problem that should be found in test, simulation, or in a thorough validation of design and implementation.  The kind of validation that should be done with "other eyes" - not the eyes of the implementing entity.  It's far better to find these kinds of problems before you're in the air, and lives are depending on everything to be Reliable.

That's why I was surprised to read today about problems with the F22, apparently crossing the International Date Line caused the computers to shut-down.