Re: Rational Edge Design Papers

["Marc A. Criley" <mcquad3@earthlink.net>]

Al Christians wrote:
> 
> See:
> 
> http://www.therationaledge.com/content/jan_01/f_craftsci_kb.html
> 
> I've read this paper without getting a real good idea how one would
> follow the method to construct larger progams out of the simple
> components described.
> 

As I read the article I observed that its suggested approach fit well
with the software architecture of a project I previously worked on for
several years.

That project was the rearchitected Engagement Planning and Control (EPC)
subsystem of the Advanced Tomahawk Weapon Control System (ATWCS). 
(ATWCS is not the Tomahawk flight software, it's the on-ship launch
planning facility.)

In the article Buhrer identifies four types of design elements.  I won't
repeat his description (see the article), but I will describe how they
fit with the EPC software architecture.

o Data Entity - Each of the different types of ATWCS planning data were
tightly encapsulated into highly cohesive data collections, usually
implemented as Ada records.  Within the system there was always a
"master" instance of each particular data type that was always
considered Truth.

o I/O Server (external interface) - EPC interacted with externals in two
ways:  First, with peer subsystems (such as the launch hardware
controller) the interaction was via a formally controlled API, with
dedicated software monitoring the APIs and through which all external
communication was funneled--both incoming and outgoing.  Second, for
subordinate subsystems, such as the operator's GUI interface,
interaction simply occurred through sockets, but again, with dedicated
software controlling all traffic passing through those sockets.  The
idea was to have single points of control for all external interfaces,
to simpify the architecture and design, ensure a consistent approach to
external interfaces, and to aid debugging.

o Transformation server - These were the straighforward internal state
managers, route planners, etc. that provided the planning functionality.

o Data Flow Manager - A pair of Ada tasks provided this functionality. 
One of the tasks managed all updates to planning data based on the
information coming in to the system, initiated "transformations", and
saw to it their outputs were passed on.  The other task drove the
planning timeline, initiating activities at the scheduled times.  One
aspect Buhrer notes is that a Data Flow Manager's "activity" may
sometimes be "waiting for input".  The EPC software architecture was
designed such that its tasks spent the vast majority of their time
blocked while waiting for input.  The net result of this was that the
system was quiescent most of the time, consuming only a few percentage
points of CPU, despite the existence of _literally_ hundreds of
simultaneously active tasks.

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com