Re: Space Station S/W in Ada -- No Tasking?

["William D. Ghrist" <ghristwd@pgh.net>]

Roger Racine wrote:
> 
> In article <354dadfd.2883074@news.mindspring.com> munck@Mill-Creek-Systems.com (Robert Munck) writes:
> >Path: news.draper.com!nsnought.draper.com!cam-news-feed5.bbnplanet.com!cam-news-hub1.bbnplanet.com!cpk-news-hub1.bbnplanet.com!news.bbnplanet.com!feed2.news.erols.com!erols!news.mindspring.net!news.mindspring.com!not-for-mail
> >From: munck@Mill-Creek-Systems.com (Robert Munck)
> >Newsgroups: comp.lang.ada
> >Subject: Space Station S/W in Ada -- No Tasking?
> >Date: Sun, 03 May 1998 18:04:15 GMT
> >Organization: Mill Creek Systems LC
> >Lines: 30
> >Message-ID: <354dadfd.2883074@news.mindspring.com>
> >Reply-To: munck@acm.org
> >NNTP-Posting-Host: ip144.herndon6.va.pub-ip.psi.net
> >Mime-Version: 1.0
> >Content-Type: text/plain; charset=us-ascii
> >Content-Transfer-Encoding: 7bit
> >X-Server-Date: 3 May 1998 18:05:12 GMT
> >X-Newsreader: Forte Agent 1.5/32.451
> 
> >A paragraph in Popular Science notes that the software for
> >the International Space Station is being written in Ada,
> >about 3M lines worth.  However, it goes on to say:
> 
> >   "To make troubleshooting easier, the software that runs
> >   the trio of computer networks aboard the space station is
> >   written to operate in synchronous, or serial, fashion
> >   rather than the faster but more complex asynchronous."
> 
> >Does this mean that they're not using tasking, but rather the
> >old "crystal clock" architecture where you organize your
> >processing into major and minor cycles, disable interrupts, and
> >poll for events "just in time" at various places in the cycles?
> 
> >In my experience, large systems built that way tended to be
> >complete disasters: nightmares to debug ("troubleshoot!"),
> >horror shows to maintain and enhance.  They often had
> >interdependencies that were handled purely by the positions
> >of pieces of code in the cycles and the processing times of
> >the other (unrelated) functions between those positions.
> >Adding a tiny fix in one place could break code half a major
> >cycle and 1 million lines of code away from it.
> 
> >Could we possibly be using this approach for a life-critical
> >system that will run in an incompletely-understood
> >environment, be subject to extensive and rapid change, and
> >have a lifetime of decades?
> 
> >Bob Munck
> >Mill Creek Systems LC
> 
> The article is misleading; there is tasking being used for the ISS.  I was one
> of the people who convinced the Boeing management to allow it, and helped
> develop the tasking structure.
> 
> Robert Dewar pointed out the development of the CIFO constructs for tasking
> within the Alsys compiler.  This was not used.  It was going to be used within
> the Space Station Freedom program, but was not allowed to be used within the
> re-designed computers in the International Space Station software (I have
> forgotten the reason).

I�m not familiar with the term "�crystal clock� architecture" and I also
don�t know what is in the Space Station software, but I would like to
point out that using a non-tasking, non-interrupt architecture does not
necessarily result in the complex "major and minor cycles" structure
that is described.  I agree that such an approach is likely to be a
problem if you are attempting to break up the main flow of processing
with explicit polling for events at some faster rate.  What this is
really doing is attempting to emulate multi-tasking, but results in very
tight coupling of functions that should be unrelated.  There is another
approach, however -- that is to replace multi-tasking with
multi-processing.  It is typical in process control and protection
applications that most of the main applications functions of a given
processing subsystem can be done in a single loop repeating at a fixed
interval.  Functions that require faster response, such as input
filtering and serial communications, can be done by additional ("slave")
processors, which then exchange data with the main processor via
access-controlled structures in shared memory.  Different main
processing subsystems can be networked together as well, and they can
operate at different cycle times.  

We have been using this approach successfully for many years in the area
of nuclear safety systems.  The main benefits of this approach are that
it simplifies the task of software verification (the verifier doesn�t
have to analyze what might happen if the software is interrupted at any
point in the program) and simplifies the ability to analyze worst case
response times.  The main drawback is that it is more costly in terms of
hardware.  But for low volume, large scope applications where the
highest level of software integrity is required, the benefits for the
software development and verification can outweigh the additional
hardware costs.  And, when presenting the safety case for licensing, it
is simply easier to demonstrate that the exact response of the system is
clearly known for all circumstances. 

One significant example of the success of this approach is in the
Sizewell B plant in the U.K.  The entire primary protection system and
the reactor control system were implemented in this manner.  This system
has been operating quite successfully for over three years now.  There
have been no "disasters", no "nightmares to debug", no "horror shows to
maintain and enhance". 

As for nightmares to debug, some of the worst in my experience (when I
worked on non-nuclear systems) have been related to the use of
interrupts and multi-tasking operating systems.  I will concede,
however, that operating system design has advance considerably since
those days. 

Certainly, this approach is not suitable in many situations, but
properly applied, it can prevent rather than cause software
"nightmares". 

Regards,
Bill Ghrist