From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII X-Google-Thread: 103376,a1eff3a9508d6cba X-Google-Attributes: gid103376,public From: "William D. Ghrist" Subject: Re: Space Station S/W in Ada -- No Tasking? Date: 1998/05/06 Message-ID: <3550C804.45CA@pgh.net> X-Deja-AN: 351002667 Content-Transfer-Encoding: 8bit References: <354dadfd.2883074@news.mindspring.com> Mime-Version: 1.0 Reply-To: ghristwd@pgh.net Content-Type: text/plain; charset=iso-8859-1 Organization: Westinghouse NPD; but these are My own Humble Opinions Newsgroups: comp.lang.ada Date: 1998-05-06T00:00:00+00:00 List-Id: 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