Caveat Emptor

Gerry Tyra - August 2016


One size does not fit all. The design approach put forth in this series of papers is based on an assumption of long term use with evolutionary changes occurring sporadically over a fleet. The other end of the spectrum is a small, one off, system. This paper explores the gray area between these two extremes.


Given a micro controller running a single process there may be no need for any messaging system. The other extreme is a rapidly evolving system where the time system life allows, or even requires, periodic refactoring and component updates. The objective of the KISS approach is to minimize the changes to only those subsystems directly impacted by the update, thereby reducing development and test.

The papers associated with this one assume a system of sufficient complexity to justify the messaging system capable of supporting that evolution. The objective of this paper is to examine cases where this dynamic revision is less critical or even counter indicated.

Single User:

Consider a vertically integrated system. The subsystems are designed within the group, which then integrates and operates the working system. Any changes within the system originate within the group and are implemented within the group. In theory, there is perfect communications from requirements, through design, development and integration test. Final acceptance testing is done by the operators, who started the change.

In a perfect world, this organization creates a commonality of vision and purpose. The need for change is identified early and implemented in a graceful, non-disruptive manner.

In the real world, this doesn't happen too often. Even when it does, it is a lot like herding cats. And as the tasking and authority becomes more diffuse, the faster and more contrary the “cats” become.

Point to Point:

If a system is made up of a limited number of processes that use limited point to point communications, if something causes one end of the communications link to change, the other end has to follow along. Logically, if the change is worth doing, and the other end of the pipe is a single entity, the remote entity should be changed to match.

The limitations of this logic are two fold. First, it assumes that the other end of the data link can be updated. However, if the subsystem is obsolete, there may not be anyone, or anything available, to do the work. The second consideration is the scale of the operation. Given a single UAV with a single controlling station, maintaining a coherent upgrade configuration of the air to ground data link is fairly straight forward. But if you look at an operational UAV, such as Predator or Global Hawk, there can be a significant number of control centers and some number of aircraft in the air. So, which ground stations can talk to which aircraft?

Stand Alone:

Take a single computer, which isn't connected to any network, does it require any messaging system at all? The answer is: Yes, No, Maybe and Perhaps. Given a single thread, everything is a procedure call. However, as the design becomes more complex, and more than one process is used, more sophisticated mechanisms are required to get data from one processes' memory space to another processes' memory space. Some of the mechanisms available are message queues, shared memory and looping back on the network stack (i.e., using Ethernet, but not going out on the wire). As a matter of software system design, there are a number of considerations and trade-offs to be made in such a system.

Again the long term stability of the system should be addressed. What changes can be expected, and what is their impact across the system? What is the life span of this system? Is the data flow mainly point to point, or is some data multi-cast? Get the right paradigm up front, and system evolution is easy. Apply the wrong mechanism, and software sustainment can become a nightmare.

A Word in Favor of an Alternate Approach:

A fellow architect and I have long winded discussions/debates/arguments on what is the more appropriate messaging mechanism in various environments. We don't always agree, but we usually concede some points to the other guy. While I admit to having “KISS” as my go to solution, his is to use an XML .xsd schema file to determine a messaging structure.

The argument goes that once you have the .xsd parser function available, the file can be updated at any time, including in flight, to change the interpretation of the message traffic, even though the messages may be strictly binary. The ordering of elements within the .xsd file defines the ordering of elements within the bit stream. The definition of attributes provide the type, size and scaling of the individual parameters within the message.
In such a system, a parser/translator is required to map the .xsd data element in the binary stream to the machine native data that the application expects.

The virtue of such an implementation is that once the parser/translator is written, integrated and validated for flight, it is done and changing the schema does not require a complete re-certification of the software. The order, type and resolution of parameters can be changed and the flight software is unchanged.


Granting that the parser/translator can take in the chunks of the binary message stream and make it accessible to the application, what happens if the schema defines value ranges greater than the application is capable of handling? If the message uses a 32 bit integer for a value, while the application uses only a 16 bit integer, and given the same units, the message could present a value that would overflow the application.

It is possible to mitigate this effect by using intrinsically large data type in the application, but this has a cost in memory and a possible cost in compute speed.

The other factor is that the actual message content has to stay the same, though there can be defined optional fields. Any new field can't be passed to the application, it doesn't know what to do with it. Any dropped, non-optional, field can have unexpected side effects.

And it is possible side effects that will force the schema through regression testing before it can be safely released in the field. Admittedly, the scope of testing may not be as extensive as it could be for an actual change to flight software, but it will be tested.


Just to repeat myself, there is no perfect solution. If Systems Engineering and the Architects don't peer into their crystal balls diligently enough, the project can be under designed or over designed. Either case increases the cost of the system over its useful life.

If the system is expected to be around for several generations of revision, I am in favor of using KISS, to bridge the revisions and maintain interoperability within the fleet. If bridging revisions is not considered a problem, it doesn't make sense to bring in the knots of complexity intrinsic to KISS.