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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1eff3a9508d6cba X-Google-Attributes: gid103376,public From: rracine@draper.com (Roger Racine) Subject: Re: Space Station S/W in Ada -- No Tasking? Date: 1998/05/08 Message-ID: X-Deja-AN: 351496280 Sender: nntp@news.draper.com (NNTP Master) References: <354dadfd.2883074@news.mindspring.com> Organization: Draper Laboratory Newsgroups: comp.lang.ada Date: 1998-05-08T00:00:00+00:00 List-Id: In article gwinn@ma.ultranet.com (Joe Gwinn) writes: >In article , >eachus@spectre.mitre.org (Robert I. Eachus) wrote: >> In article <354dadfd.2883074@news.mindspring.com> >munck@Mill-Creek-Systems.com (Robert Munck) writes: >> >> > "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." >> >> While the rest of the discussion on this sounds correct, I think >> that what was being implicitly rejected here is the way that the Space >> Shuttle computers do voting. In the Space Shuttle, voting is based on >> whether three different computer systems come up with about the same >> answer at about the same time. If no two agree, the results of a >> fourth are arbitrarily accepted. (Is that both right and concise?) >> Since the computers do not get their data synchronously, the actual >> data values, and the control inputs computed from them, will be >> slightly different. >This is my understanding as well. Three of the computers are identical, >IBM 4pi units if I recall, while the fourth unit is hardwired analog, the >theory being to protect against common-mode hardware failures. This is really getting off the subject of Ada, but it is difficult to allow misconceptions to propagate. There are 5 main computers (IBM 4pi AP-101s) on the Shuttle. Four work together during critical flight phases (ascent and entry). This is the Primary Avionics SubSystem (PASS). They each get data from the same sensors, and they each send data to the same effectors. The effectors have a means to throw away data from a computer if the value disagrees with the data from the others. The 4 computers simply send a synchronization message to each other periodically. If a computer fails to send the message at the appropriate time (with a little leeway), they tell the crew, but keep going. The crew can turn the power off a computer if they decide to. There is more to the syncronization, but that is the concise version. The software on all 4 of these computers is identical, and contains a priority-based pre-emptive executive. The 5th computer is the Backup Flight System (also an AP-101). It can only take control if a crew member presses a button (this has not happened to date, except during simulations). It has software developed "independently". The quotes are there because the algorithms within the guidance, navigation and control software are the same for both systems, so there could be common errors. The operating system on this computer is a cyclic executive (i.e. not priority-based pre-emptive tasking). The Shuttle is completely digital, by the way. There is no analog backup. The 5 computers get their data from the same types of sensors, and use the same effectors. >However, there is one added issue to be addressed: common-mode failure in >the software. A classic solution is N-version programming, where two or >three completely independent and isolated teams develop the software for >the digital computers. The theory of this is that the teams, being >isolated, will not make the same mistakes, so they can cross-check each >other, both during system integration, and operationally. >It's a pretty good theory, but falls down if for instance the control law >requirements are not correct. The Swedes lost a prototype fighter >aircraft at the Paris Air Show to just such a problem a few years ago. >Fortunately, nobody was hurt, although the airplane was destroyed. >My recollection is that NASA used two teams, so two of three computers >will contain the same software. As I mentioned above, 4 of the 5 have the same software; the 5th was developed by a different team (in fact, different companies). >Anyway, one cannot expect the outputs of these slightly different programs >to match to the bit, nor is it important in practice that they be that >close, so the voting unit compares the absolute value of the algebraic >difference to a threshold. I would guess that the tolerance is no more >than a few percent of full scale. The voting of outputs is done at the actuators, not by the computers. >> In the ISS, where voting is required, two out of three computers >> will have to agree, but based on identical data, and bit for bit >> compares. The Space Shuttle approach does provide more reliability >> where the algorithms are not known to be stable, but is a maintenance >> nightmare. (All computers getting the same overflow is no help, and >> the SS flight guidance software does go through about 20 different >> flight regimes during landing. At the boundary between some of those >> modes, the flight control algorithms are known to be unstable. So >> that approach is not only appropriate to the shuttle, it seems to be >> necessary.) >One could wonder if ISS will really use bit comparison, because they too >may wish to have multiple versions, for exactly the same reasons. The ISS software is not considered to be of the same criticality as the Space Shuttle software, since problems can not happen nearly as fast (one gets extremely bored watching a simulation of the Space Station maneuvering). There is no backup software. Roger Racine