Gerry has placed various papers and software samples here. They represent a number of lessons learned in the School of Hard Knocks.
As a bit of background, I have spent a number of years wrestling with various avionics architectures. Several have started out as grand designs that devolved into chaos. These grand designs came about to cope with projected growth and change. But, in doing so, either the complexity overpowered the ability of mere mortals to maintain it, or it became so "brittle" that any change resulted in an unending series of patches.
So, I have tinkered with various approaches to managing change in a messaging system. The first "public" appearance was presented at the IEEE Software Technology Conference 2014. The paper and the supporting sample code are provided below. The emphasis of the paper was on controlled revision of the messaging system and allowing processes to communicate using different revisions either within the same system or across different systems.
This paper lead to another. The second paper expanded on the first, and addressed the over all support architecture in the which any given process exists and how it communicates with other processes. Having already stated my concerns about overtly complex structures, this paper was rooted in the idea of KISS: Keep It Simple, Stupid.
The main extension was to provide multiple serializers/deserializers to optimize the trade between CPU cycles to compress messages and the throughput available over various network segments. Along with the ser/des issues were a minimalist set of system functions to manage resource utilization.
Before digging in too deep, here are a few words on when KISS is appropriate and when it isn't:
Abstract:
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.
Moving on...
Discussions with coworkers have brought up other extensions and has helped me resolve the engineering philosophical foundation for the design. To help explain that foundation, the following white papers are provided:
Dude, Its an Airframe, not a Main Frame!
Abstract:
Over the last 30 years, there has been a trend in Computer Science that places a great deal of emphasis on the Internet and its supporting infrastructure. This has lead to a high percentage of CS majors having an intellectual framework that requires significant restructuring before they can work effectively in a Real Time Embedded environment.
Abstract:
Different people have different definitions of what constitutes a “Real-Time” computer system. A working definition is presented here, which will be the basis for all the discussion that follows.
Abstract:
People searching for greater productivity in software development, frequently people with little hands-on experience in the area they are controlling, push for improved human readability in the software and/or the messaging system. The argument presented here is that such an attempt is counter productive and, in some senses, delusional.
Abstract:
A messaging system does not exist in a vacuum, it was created in response to the needs of an environment. As that environment changes, the messaging system must change as well. But change is more than just adding new messages. Change also includes a need to extend and modify existing messages to better represent the content that the producers and consumers of that data have available and need.
Abstract:
Efficient processing of time sensitive data requires that the data be consistent and complete. Given the facilities discussed previously, consistency and completeness can be assured without allowing for optional data fields. Taking the statement further, allowing optional fields is counter productive and should be explicitly excluded.
Abstract:
When any message is transmitted, there has to be some mechanism to inform the receiver what type of message is coming in. Without some mechanism to identify the message type, the message is just digital noise. But, the mechanism used does not need to be immediately readable by a person.
To C or Not to C? That is the Question
Abstract:
C++ is a powerful language, and it is currently popular in the avionics industry. But all problems, or tools, do not yield gracefully to the C++ structures. The question is: how feasible is it to wrap the C++ classes to allow easy access to the message structure from other tools?
Abstract:
Size does matter. But relative to what? How is the code distributed through the system? What is the inter-service communications mechanism, its bandwidth and its latency? We strive for a global optimum in light of the problem at hand.
Abstract:
For a safety critical system, the Gold Standard is a triple redundancy. But the engineering reality is that nothing is perfect. This paper presents the analysis of just how reliable that a KISS system would have to be to match an arbitrarily reliable triple redundant system.
That Which Was Old Is New Again
Abstract:
There is an old saying that when all that you have is a hammer, everything looks like a nail. Adhering to the systems paradigm de jour for all projects is a lot like just having a hammer. We need to look further afield before committing to a specific approach.
Abstract:
Multi Level Security (MLS) is difficult, especially in an avionics environment. And usually, it isn't required or appropriate. However, I've identified two cases where MLS is needed and how to cope with this problem.
Abstract:
Across the other writings in this set, there has been an assumption that the messaging system described is used universally. Then I was confronted by the question: What happens if you have to interface with a legacy system? Does relative structural simplicity and evolutionary consistency of the system breakdown in a flurry of custom coding? After an examination, the answer is: No.
Process Management: Static vs. Dynamic
Abstract:
When an embedded system needs to launch multiple processes at power up, the startup mechanism can be static or dynamic, with various degrees of dynamic. Since one size does not fit all, this paper discusses the trade-offs implied by this spectrum.
Abstract:
An avionics suite can be implemented in a great number of ways, using different services, network paradigms, network topologies and messaging systems. It is presented here that, with only minor abstraction, most of the commonly used methods reduce to a few simple cases.
Here are the papers that started this discussion.
This link takes you to the HTML version of the paper presented at the IEEE Software Technology Conference 2014 on April 3rd.
The paper presents a method for using C++ templates such that multiple revisions of of a message type can exist simultaneously within a project. All data is stored in the newest version of the message. Code designed to work with older versions of the message access a copy of the revision that the application was designed to operate with. The internal mechanism of the message then accesses the actual data from the newest revision.
In the process of setting and getting data from one revision to another, types and scaling operations are performed to maintain the data in the correct type.
Software Revision Control source code
Copy this link to get a copy of the source files and Visual Studio 2010 project. The file is a little over 100 MB.
There are four directories, two MessageStack and two MsgRev. MessageStack builds a library of message types 15 through 20. MessageStackShort builds a library of only message types 15 and 16.
MsgRevShort will use message types 15 and 16, though it can use either library. MsgRev uses messages 15, 16 and 18. It requires the library from MessageStack.
Alternative Approach to Avionics Software: KISS
Alternative Approach to Avionics Software source code
As an extension of the previous paper, the paper "An Alternative Approach to Avionics Software: KISS" has been accepted by the Lockheed Martin Journal of Software Engineering. A shorter version has also been accepted by Crosstalk.
The paper touches on many of the root causes for embedded software projects to overrun both budget and schedule. It then covers a number of issues faced by embedded software engineers that are rarely taught in a Computer Science curriculum.
The paper then presents an architecture designed to support the simplest interfaces, and flexibility of implementation, while supporting both agile development and long term maintenance. It is not meant to prevent the root cause problems, after all you can not stop a pointy haired boss from reading glossy trade journals. Rather, it is intended to constrain the problem space to a manageable subset.
The .zip file that the title is linked to is an ongoing effort to implement working samples of the concepts presented in the paper. Working with KISS is intended to provide additional design insights as to why the sample code is the way that it is.
The general hardware configuration that is the target for this application is described in Mission System's Hardware the KISS Way.