* ARIANE-5 Failure @ 1996-06-06 0:00 John McCabe 1996-06-07 0:00 ` Tronche Ch. le pitre ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: John McCabe @ 1996-06-06 0:00 UTC (permalink / raw) I have heard that the failure of the Ariane 5 rocket's first launch on Tuesday was caused by a software fault in the attitude control system. Does anyone know whether Ada was used on that system, and if so, who designed and built the software, and which compiler and target were used. Thanks in advance for any information you might have. Best Regards John McCabe <john@assen.demon.co.uk> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-06 0:00 ARIANE-5 Failure John McCabe @ 1996-06-07 0:00 ` Tronche Ch. le pitre 1996-06-07 0:00 ` David Weller ` (6 more replies) 1996-06-07 0:00 ` Theodore E. Dennison 1996-06-10 0:00 ` William Clodius 2 siblings, 7 replies; 47+ messages in thread From: Tronche Ch. le pitre @ 1996-06-07 0:00 UTC (permalink / raw) John McCabe wrote: > > I have heard that the failure of the Ariane 5 rocket's first launch on > Tuesday was caused by a software fault in the attitude control system. French media have presented several successive explanations but always invoking software failure. > Does anyone know whether Ada was used on that system, and if so, who > designed and built the software, and which compiler and target were > used. Sad to say, but the software is entirely written in Ada, with a few parts in assembler. It has been described by Jean-Noel Montfort and Vinh Qui Ribal, from Aerospatiale, in the 2nd Eurospace-Ada in Europe conf. (1995). Quoted from their paper, the computer boards are Motorola 68020/68881 with 512 kb of RAM, and the Alsys compiler. The software has been designed using the HOOD methodology. The launch was broadcast on TV. The greatest time (if I can say that) was just before the rocket was destroyed. After 40 seconds or so of a nice launch, it became obvious that it was on a bad trajectory. Then someone say (the operational director or a journalist, I don't know) "trajectory and all flying parameters are okay", and just then BOOOM, someone had noticed that parameters weren't OK at all and made the rocket exploded... It would have been very nice if everything had worked well, but frankly, you take a big risk when you change something on a rocket, and everything was new on this one, from the engine to the computers. Thus I'm not surprised. I don't think one has never see number 1 of any rocket succeeded in the aerospace industry history. -- +--------------------------+------------------------------------+ | | | | Christophe TRONCHE | E-mail : tronche@lri.fr | | | | | +-=-+-=-+ | Phone : 33 - 1 - 69 41 66 25 | | | Fax : 33 - 1 - 69 41 65 86 | +--------------------------+------------------------------------+ | ###### ** | | ## # Laboratoire de Recherche en Informatique | | ## # ## Batiment 490 | | ## # ## Universite de Paris-Sud | | ## #### ## 91405 ORSAY CEDEX | | ###### ## ## FRANCE | |###### ### | +---------------------------------------------------------------+ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre @ 1996-06-07 0:00 ` David Weller 1996-06-07 0:00 ` Ken Garlington 1996-06-07 0:00 ` ARIANE-5 Failure Ken Garlington ` (5 subsequent siblings) 6 siblings, 1 reply; 47+ messages in thread From: David Weller @ 1996-06-07 0:00 UTC (permalink / raw) In article <31B7A88D.446B@lri.fr>, Tronche Ch. le pitre <tronche@lri.fr> wrote: >Thus I'm not surprised. I don't think one has never see number 1 of >any rocket succeeded in the aerospace industry history. > The "Delta Clipper" has done very well so far, with no disastrous failures. Most of the software, by the way, is written in Ada (automatically generated, so it is claimed, from the MatrixX software application) -- Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch This is not your father's Ada -- lglwww.epfl.ch/Ada ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` David Weller @ 1996-06-07 0:00 ` Ken Garlington 1996-06-08 0:00 ` Samuel Mize 0 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-07 0:00 UTC (permalink / raw) David Weller wrote: > > The "Delta Clipper" has done very well so far, with no disastrous > failures. Didn't DC-X have a pad fire? -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Ken Garlington @ 1996-06-08 0:00 ` Samuel Mize 1996-06-09 0:00 ` ARIANE-5 Failure (DC-X works) Eugene W.P. Bingue 1996-06-12 0:00 ` Automatic code generation (was ARIANE-5 Failure (DC-X works)) Steve Vestal 0 siblings, 2 replies; 47+ messages in thread From: Samuel Mize @ 1996-06-08 0:00 UTC (permalink / raw) In article <31B84662.7930@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> wrote: >David Weller wrote: >> >> The "Delta Clipper" has done very well so far, with no disastrous >> failures. > >Didn't DC-X have a pad fire? As I recall from Aviation Leak, venting hydrogen built up under the "skirt" around the engines. I *think* it happened in flight, and they landed it. It may have been on the ground. The working components were intact, and I believe it was flyable, but they (sensibly) were going to check it over and replace the blown-out skin panels before flying it again. So, (1) it's a judgement call whether that was a "disastrous" failure, and (2) it wasn't a software failure anyway. But yes, they did have a fire. Samuel Mize ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-08 0:00 ` Samuel Mize @ 1996-06-09 0:00 ` Eugene W.P. Bingue 1996-06-08 0:00 ` Robert Dewar 1996-06-12 0:00 ` Automatic code generation (was ARIANE-5 Failure (DC-X works)) Steve Vestal 1 sibling, 1 reply; 47+ messages in thread From: Eugene W.P. Bingue @ 1996-06-09 0:00 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1405 bytes --] In <4pd540$rl2@Starbase.NeoSoft.COM> smize@Starbase.NeoSoft.COM (Samuel Mize) writes: > >In article <31B84662.7930@lmtas.lmco.com>, >Ken Garlington <garlingtonke@lmtas.lmco.com> wrote: >>David Weller wrote: >>> >>> The "Delta Clipper" has done very well so far, with no disastrous >>> failures. >> >>Didn't DC-X have a pad fire? > >As I recall from Aviation Leak, venting hydrogen built up under the >"skirt" around the engines. I *think* it happened in flight, and >they landed it. It may have been on the ground. > >The working components were intact, and I believe it was flyable, but >they (sensibly) were going to check it over and replace the blown-out >skin panels before flying it again. > >So, (1) it's a judgement call whether that was a "disastrous" failure, >and (2) it wasn't a software failure anyway. > >But yes, they did have a fire. > >Samuel Mize > > > What�s the point? The X in DC-X stands for experimental. Experimental vehicles have problems. The DC-X flight control software is in Ada and is all computer generated. You would not want to maintain this code by hand. The DC-X was flying in 18month from concept to the pad at white sands. This is the first craft of its type in the world. Even after a onboard explosion the flight control system remain stable and the flight controller was able to land the DC-X. That the point! The system works. Mahalo Eugene ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-09 0:00 ` ARIANE-5 Failure (DC-X works) Eugene W.P. Bingue @ 1996-06-08 0:00 ` Robert Dewar 1996-06-09 0:00 ` Samuel Mize ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-08 0:00 UTC (permalink / raw) Eugene says "vehicles have problems. The DC-X flight control software is in Ada and is all computer generated. You would not want to maintain this code by hand." Sounds bogus, ultimately the code is maintained by humans, we do not yet have robots that can write and maintain code. Sure the code may be in some other language than Ada and then generate Ada (if the Ada is not maintained, but is just used as an intermediate language, it is essentially irrelevant that it is Ada). So the question is: what language WAS the software written in? And what is the argument that this code is easier to maintain than properly written Ada? I am always running into the vague notion that someone program generators and CASE tools eliminate programming completely. All too often what is really happening is that the code is being written in some poorly designed and poorly defined and poorly maintained language. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-08 0:00 ` Robert Dewar @ 1996-06-09 0:00 ` Samuel Mize 1996-06-10 0:00 ` ARIANE-5 Failure Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar 1996-06-09 0:00 ` ARIANE-5 Failure Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Ken Garlington 2 siblings, 2 replies; 47+ messages in thread From: Samuel Mize @ 1996-06-09 0:00 UTC (permalink / raw) In article <dewar.834287759@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Eugene says > >"vehicles have problems. The DC-X flight control software is in Ada and >is all computer generated. You would not want to maintain this code by >hand." > >Sounds bogus, ultimately the code is maintained by humans, we do not yet >have robots that can write and maintain code. Sure the code may be in >some other language than Ada and then generate Ada (if the Ada is not >maintained, but is just used as an intermediate language, it is >essentially irrelevant that it is Ada). So the question is: what >language WAS the software written in? And what is the argument that >this code is easier to maintain than properly written Ada? Other posts have said the code was generated with MatrixX. I haven't used MatrixX, but others at my company have, so I'll try to describe it. MatrixX isn't a language. It's a tool that uses a graphical notation, including some standard graphical notation for math. You can think of it as a 4GL for scientific calculation. Its application area is limited, but within that area, its graphic notation is closer to what a mathematician would use, so a domain expert can work with it and validate it more easily. I'm sure a MatrixX marketeer would plotz at this definition, but it lets you see why it's easier (in this case) to maintain than properly written Ada. The maintainers aren't programmers, and they aren't maintaining the program. They're maintaining their mathematical specifications. The tool regenerates the program to match new specs. Nobody maintains (this part of) the program. >I am always running into the vague notion that someone program generators >and CASE tools eliminate programming completely. All too often what is >really happening is that the code is being written in some poorly designed >and poorly defined and poorly maintained language. No argument there. However, MatrixX seems to be a fairly solid tool for its appropriate application areas. I say this from outside observation, not from personal experience. Your mileage with it may vary; your particular car may not even start with it. But since Ada is a general language, there will always be tools that are easier for specific, limited application domains. Samuel Mize ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-09 0:00 ` Samuel Mize @ 1996-06-10 0:00 ` Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar 1 sibling, 0 replies; 47+ messages in thread From: Dale Stanbrough @ 1996-06-10 0:00 UTC (permalink / raw) Robert Dewar writes: But it would be nice to find out, anyone on this list have a REALLY AUTHORITATIVE first-hand source for the truth on this one (it is one that many people "know" the answer to, but as Jim pointed out, they disagree and can't all be right!) Robert Eachus posted this one a few years back now. Although it doesn't quote anyone, its level of detail lends an air of credibility. Maybe we should ask Mr Eachus where he got his info from... Dale ---------------------------------------------------- Subject: FORTRAN bug(was Re: C++ vs. Ada -- Is Ada loosing?) From: Robert I. Eachus, eachus@oddjob.mitre.org Date: Mon, 7 Dec 1992 23:47:34 GMT Nice to get some facts in here. As I remember it, there were two bugs involving Venus probes. One was code that assumed that an uninitialized variable always start life equal to zero. When this code was rerun after several months in space... The FORTRAN bug which resulted in the destruction of the first Venus probe was that in: DO 20 I = 1,10 the comma was replaced by a period: DO 20 I = 1.10 of course in FORTRAN (in particular FORTRAN 66) the spaces are ignored, and this was interpreted as: DO20I = 1.10 (Implicitly declaring a real variable DO20I and assigning to it.) This had not caused a problem on earlier launches as the loop was to refine the amount of correction for wind, and a single repetition was usually enough. But when a gust hit, the inaccurate calculation resulted in an oscillation, and the RSO destroyed the missile. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-09 0:00 ` Samuel Mize 1996-06-10 0:00 ` ARIANE-5 Failure Dale Stanbrough @ 1996-06-10 0:00 ` Robert Dewar 1996-06-12 0:00 ` Theodore E. Dennison ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-10 0:00 UTC (permalink / raw) Samuel says "Other posts have said the code was generated with MatrixX. I haven't used MatrixX, but others at my company have, so I'll try to describe it. MatrixX isn't a language. It's a tool that uses a graphical notation, including some standard graphical notation for math. You can think of it as a 4GL for scientific calculation." Of course it is a language, any notation is a language. Yes, it is reasonable to think of it as a 4GL for scientific calculation. What do you think the L in 4GL stands for. The people writing this *are* programmers, they are programming. There is no difference between a program and an executable specification. In fact that's all a program is -- a specification of what needs to be done with a method for automatic translation into a machine that does the task. And if the people who write the MatrixX code don't maintain it, who does? Samuel's post is a perfect companion to mine, because it shows how widespread the confusion is about the use of high level programming tools. In particular, people often thing the Ada mandate is being obeyed if the generated code from such a tool is Ada. In fact if this generated code is not maintained or looked at, there is absolutely no reason for it to be in Ada, and no particular advantage in it being in Ada. The policy of using Ada applies to the INPUT, not the OUTPUT of the programming effort, so in this particular case, if the Ada policy applies, a waiver is needed to program part of the aplication in MatrixX instead of in Ada. Assuming that MatrixX is being appropriately used, and the application really is taking advantage of the leverage that can be obtained from the use of such high level tools, and that the tool itself meets requirements for reliability and maintainability, then this is undoubtedly a clear case for a waiver. The trouble is that the assumption tends to be that the mere fact that something is written in a 4GL means that these criteria are met, when the reality is that a lot of 4GL code is low level junk written in totally inappropriate, ill-though out languages. The use of very high level languages is a very important advance in proramming technology, one that has been very slow in coming, but the notion that somehow this eliminates the need for programming of programmers is absurd and likely to lead to bad decisions. Lambert Meertens once introduced the notion of VHLANOS, "very high level abstract non-operational specifications", and pointed out that one of the ways in which programming progresses is that yesterdays VHLANOS becomes today's progrmming language. For example, in the days of machine language programing, a simple algebraic expression like (a * b) + (c * d) seems like VHLANOS, but when Fortran came along, it became programming. The rhetoric about not needing programmers or programming any more was common as Fortran was introduced -- at last we don't need to rely on programmers (where the image of programming is messing with machine language), now our scientists can do the job themselve without programming). Yes of course, the people programming in MatrixX are not Ada programmers, and are operating at a different level of abstraction, but they are still programming! To describe it otherwise is confusing and damaging. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar @ 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-15 0:00 ` Robert Dewar 1996-06-12 0:00 ` Samuel Mize 1996-06-13 0:00 ` Ken Garlington 2 siblings, 1 reply; 47+ messages in thread From: Theodore E. Dennison @ 1996-06-12 0:00 UTC (permalink / raw) Robert Dewar wrote: > generated code from such a tool is Ada. In fact if this generated code > is not maintained or looked at, there is absolutely no reason for it > to be in Ada, and no particular advantage in it being in Ada. The I can't really fault your logic in this post, with the exception of the above statement. Given the reams of well-nigh unreadable code generated by tools such as a GUI builder, I'd much prefer the generation is done into a language with safety features like array bounds checking. For me, this is reason enough to have the code generated in Ada. And no, this doesn't really dillute your overall argument much. Its just a nit. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-12 0:00 ` Theodore E. Dennison @ 1996-06-15 0:00 ` Robert Dewar 0 siblings, 0 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-15 0:00 UTC (permalink / raw) T.E.D. said "I can't really fault your logic in this post, with the exception of the above statement. Given the reams of well-nigh unreadable code generated by tools such as a GUI builder, I'd much prefer the generation is done into a language with safety features like array bounds checking. For me, this is reason enough to have the code generated in Ada. " Sure, Ted, I agree with this, there are many reasons for choosing an intermediate language (portability, redundancy of checking etc.) and it may well me that on the tecnical merits, Ada is a good choice. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar 1996-06-12 0:00 ` Theodore E. Dennison @ 1996-06-12 0:00 ` Samuel Mize 1996-06-13 0:00 ` Robert Dewar 1996-06-13 0:00 ` Ken Garlington 2 siblings, 1 reply; 47+ messages in thread From: Samuel Mize @ 1996-06-12 0:00 UTC (permalink / raw) ** I have extracted and rearranged some of Mr. Dewar's paragraphs ** ** to fit my response. ** In article <dewar.834410609@schonberg>, Robert Dewar <dewar@cs.nyu.edu> wrote: >Samuel says > >MatrixX isn't a language. > >It's a tool that uses a graphical notation, including some standard >graphical notation for math. You can think of it as a 4GL for >scientific calculation." > >Of course it is a language, any notation is a language. OK, get happy. I should have said that it isn't a general-purpose programming language. Strictly speaking, MatrixX isn't a language, it RUNS the language. >The people writing this *are* programmers, they are programming. I'll concede this point for the DC-X. It's irrelevant to my point whether we say that MatrixX generates a program from a math notation, or wheter we say that writing the math notation is programming. It's relevant to your point, which I'll address below. My point was just to describe the flavor of MatrixX. Using MatrixX is more alien to programming in a third-generation language than using Ada is to programming in Assembly. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >The use of very high level languages is a very important advance in >proramming technology, one that has been very slow in coming, but the >notion that somehow this eliminates the need for programming of >programmers is absurd and likely to lead to bad decisions. >...The rhetoric about >not needing programmers or programming any more was common as Fortran >was introduced And was equally stupid at the time. I agree with you. MatrixX does not obviate programmers or programming. In a limited domain, it can generate a program from a description of a desired result -- a description that I wouldn't consider a program, and that perhaps you would (see next point). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >The people writing this *are* programmers, they are programming. There is >no difference between a program and an executable specification. In fact >that's all a program is -- a specification of what needs to be done with >a method for automatic translation into a machine that does the task. Your definition misses a subtle distinction. I can't define it formally. I think most of us view programmers as people who tell a system HOW to do something. The MatrixX user identifies WHAT to compute, but not HOW. This distinction is a lot clearer in word-processing. Computer-based word processing was once a form of programming. Remember nroff/troff? You had statements to change margins, turn bold text on/off, etc. I don't think anyone would say that using MacWrite is programming, but you're certainly entering a specification of what needs to be done -- in this case, what needs to be printed -- and giving it to a "compiler" to translate it into a machine (program+hardware+data) that does the task. In fact, on the typical Mac, it translates this user "language" into a postscript program, to be run on the LaserWriter. You can call that programming, but it isn't a useful definition, and it isn't the way most people define programming. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >And if the people who write the MatrixX code don't maintain it, who does? The people who write the MatrixX (math specifications) maintain them. They just don't maintain the generated Ada. They regenerate it as needed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >In fact if this generated code >is not maintained or looked at, there is absolutely no reason for it >to be in Ada, and no particular advantage in it being in Ada. UNLESS your generated code will be integrated into a larger system, and the larger system is written in Ada. (As we're doing where I work.) In this case, it's easier to combine everything if it's all Ada, and the Ada can be used on several platforms without modification. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >In particular, people often thing the Ada mandate is being obeyed if the >generated code from such a tool is Ada. I don't recall anyone saying that DC-X used MatrixX due to the Mandate. I agree that such an attitude is stupid. I would never suggest using MatrixX just to stay within the Mandate. Depending on what you're doing with it, I'd argue that a code-generator requires a waiver, even if it spits out Ada If you want to start a discussion about idiotic code generator ideas, you will find me on your side. I'm thinking in particular of some of the "AI in Ada" presentations I've seen, where an expert system engine is built in Ada, then the expert system is coded in the expert system engine's source language. They claim they're doing AI work in Ada. Feh. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >The trouble is that the assumption tends to be that the mere fact that >something is written in a 4GL means that these criteria are met, when >the reality is that a lot of 4GL code is low level junk written in >totally inappropriate, ill-though out languages. I feel this is an inappropriate statement in this thread, unless you have some evidence that the use of MatrixX in the DC-X program is one of those cases. It's as if we were specifically discussing Ada, and someone said that the problem with most third-generation languages is that they don't including tasking and strong typing. Please start a new thread on this topic, so I can agree with you. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Samuel Mize ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-12 0:00 ` Samuel Mize @ 1996-06-13 0:00 ` Robert Dewar 1996-06-17 0:00 ` David Zink 0 siblings, 1 reply; 47+ messages in thread From: Robert Dewar @ 1996-06-13 0:00 UTC (permalink / raw) Samuel said "Your definition misses a subtle distinction. I can't define it formally. I think most of us view programmers as people who tell a system HOW to do something. The MatrixX user identifies WHAT to compute, but not HOW." The reason you cannot define this discinction formally is that it is a meaningless one. That was the whole point of Lambert's point about VHLANOS. One person's program is another persons abstract specification. If I write: A := B * C + D * E; that is (with minor notational differences) just a description of WHAT should be done (compute a formula and put the result in A), not HOW it should be done (i.e. I don't care about what instructions or registers are used). Sure the use of very high level languages like MatrixX raises this to a higher level of abstraction, but you still cannot make any meaningful discinction. Now there are some related issues, e.g. whether you write in a procedural style, but non-procedural languages have been around for at least 30 years (e.g. RPG!) and no one would claim that the use of a non-procedural language means that you are not programming. In Setl, if I say primes := { n in [2..100] | not exists d in [2 .. N - 1] | n mod d = 0}; that's essentially a mathematical definition of the set of primes from 2 to 100. If I look at it as an Ada programmer, it sure looks like a specification and not a program, but it is in fact an executable Setl program. I simply don't believe you can succeed in drawing any meaningful distinction between a program and an executable specification. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-13 0:00 ` Robert Dewar @ 1996-06-17 0:00 ` David Zink 1996-06-18 0:00 ` Robert Dewar 0 siblings, 1 reply; 47+ messages in thread From: David Zink @ 1996-06-17 0:00 UTC (permalink / raw) In article <dewar.834643137@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: >Samuel said > >"Your definition misses a subtle distinction. I can't define it >formally. I think most of us view programmers as people who tell a >system HOW to do something. The MatrixX user identifies WHAT to >compute, but not HOW." > >The reason you cannot define this discinction formally is that it is >a meaningless one. That was the whole point of Lambert's point about >VHLANOS. One person's program is another persons abstract specification. I agree that only micro-code or assembly language programmers tell the machine HOW to compute instead of just WHAT. However I have been wrestling with the question of how to distinguish between Pascal Programmers and Data-Entry operators. You see, the Data-Entry operator enters a bunch of symbols (programs the database) so that it will print out a specific set of values (behave in a certain way). I compare them to Pascal programmers because of your phrase 'executable specification'. Pascal compilers produce not executable code but data (P-code) which the pascal database engine massages to generate the reports I've requested. I next thought, "Ah, but the Pascal Programmers manipulates the data he enters in order to produce more desirable output." Having worked in the financial industry for some time, I quickly remembered that this was no different than Data-Entry. However it does qualify the Pascal Data-Entry crew as 'engineers', so if we label them 'Software Engineers' instead of programmers, at least we have believable nomenclature. But it still leaves me wondering what a 'Programmer' is. Obviously those mathematicians using Matrix-X are not, as anyone can see (formal distinctions being a bit of a joke when they cannot distinguish things people can easily distinguish). Your points about whether the code is delivered in ADA seem equally meaningless. Either ADA is a language in which a team of fools cannot create a dysfunctional program, or it is not. It hardly matters to me or any thinking person whether the team of fools is biological or cybernetic. The only value to programming in ADA or any other high-level language is that it allows competent programmers to significantly reduce their accidental error rate. Its value is not that it forces a wise choice of algorithms, or that it forces the program specification to bear a meaningful relation to the actual problem to be solved, though it =can= help the program specification bear a meaningful relationship to the program behavior. These last issues are the proper domain of programmers. The first is the proper domain of tools. If the mathematicians entered equations into a database and the runtime code retrieved those equations and evaluated them using validated ADA code/methods, would they be programmers or (as I suspect) data-entry operators? If, the (equation) data being constant for individual runs of the program, the data was extracted from the database and transformed into executable/compilable code, does that transform the mathematicians into programmers? In which case I've transformed an awful lot of data-entry operators into programmers over the years. I should tell them they're underpaid. Perhaps you see why I'm confused. --David PS (a few passing thoughts): If I were accepting machine generated code for a project of mine, I would want awfully iron-clad proof that the code-generator's output implemented the input. Until we eliminate documentation and specification altogether, until the program *is* its documentation and specification, I doubt that we'll have reliable programs. The main advantage of assembly language programming is that it kept incompetent programmers from ever completing a project. Unfortunately the cost was that even competent programmers were hard put to avoid subtle errors. What I'd like is a language with no subtle errors. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-17 0:00 ` David Zink @ 1996-06-18 0:00 ` Robert Dewar 0 siblings, 0 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-18 0:00 UTC (permalink / raw) David said: "But it still leaves me wondering what a 'Programmer' is. Obviously those mathematicians using Matrix-X are not, as anyone can see (formal distinctions being a bit of a joke when they cannot distinguish things people can easily distinguish)." Sorry, the mathematicians using Matrix-X are definitely programmers, just as scientists who use Fortran to encode their equations are programmers. I cannot distinguish any fundamental difference. You seem to think that programming must mean writing low level code in a procedural language. I do not consider this to be a useful distinction. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-12 0:00 ` Samuel Mize @ 1996-06-13 0:00 ` Ken Garlington 1996-06-14 0:00 ` Robert Dewar 2 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-13 0:00 UTC (permalink / raw) Robert Dewar wrote: > > The people writing this [MatrixX] *are* programmers, they are programming. There is > no difference between a program and an executable specification. In fact > that's all a program is -- a specification of what needs to be done with > a method for automatic translation into a machine that does the task. I can't find fault with the technical accuracy of your statement. However, when I say "the people who use MatrixX usually aren't programmers," I mean that they are not always acquainted with knowledge which most people would expect software engineers to know. For example, although MatrixX permits the decomposition of diagrams into modules, the average MatrixX user would probably not think too much about the long-term maintenance effects of their choice of module interfaces. Also, they usually don't consider the effects of algorithm choices on throughput or memory. Therefore, they may not be fully equipped to make decisions about the best language to use when generating code. This decision might -- and I emphasize might -- make a difference in the quality of the final product, however. > The > policy of using Ada applies to the INPUT, not the OUTPUT of the programming > effort, so in this particular case, if the Ada policy applies, a waiver is > needed to program part of the aplication in MatrixX instead of in Ada. Actually, I'm not sure I agree with this. If I deliver the output to the depot, I don't know if I need a waiver or not. When I've asked this question in the past, I've always been told that a waiver is not required. Could you cite where you think the policy excludes the output from consideration? This is pretty important, since some F-22 Ada code is auto-generated, and by your definition I would need a waiver for all these cases! > The use of very high level languages is a very important advance in > proramming technology, one that has been very slow in coming, but the > notion that somehow this eliminates the need for programming of > programmers is absurd and likely to lead to bad decisions. I certainly agree with this! However, if the 4GL decomposes into Ada code, and that Ada code is delivered, I think right now the policy assumes that no waiver is required. (Note that the policy also allows Ada to be written by people who have no business writing programs!) -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-13 0:00 ` Ken Garlington @ 1996-06-14 0:00 ` Robert Dewar 1996-06-17 0:00 ` Ken Garlington 0 siblings, 1 reply; 47+ messages in thread From: Robert Dewar @ 1996-06-14 0:00 UTC (permalink / raw) Ken asks "I don't know if I need a waiver or not. When I've asked this question in the past, I've always been told that a waiver is not required. Could you cite where you think the policy excludes the output from consideration? This is pretty important, since some F-22 Ada code is auto-generated, and by your definition I would need a waiver for all these cases!" To me, the issue is quite clear. If the Ada code is delivered and will be maintained at the Ada level, then the method used in generating it is irrelevant, and certainly the Ada policy is complied with. If what is delivered is the 4GL code, and Ada acts merely as an intermediate language which will never be looked at by a person, let alone maintained, then the program really is written in another language, and a waiver really is required (though, if a very hgh level language is being used appropriately), such a waiver is certainly reasonable (and in fact I may be wrong, but I think there is some kind of blanket permission to use high level tools of the 4GL type). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-14 0:00 ` Robert Dewar @ 1996-06-17 0:00 ` Ken Garlington 1996-06-18 0:00 ` 4GL code in a deliverable (was: ARIANE-5 Failure) Arthur Evans Jr 0 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-17 0:00 UTC (permalink / raw) Cc: McGarity, Joan Robert Dewar wrote: > > If what is delivered is the 4GL code, and Ada acts merely as an intermediate > language which will never be looked at by a person, let alone maintained, > then the program really is written in another language, and a waiver really > is required (though, if a very hgh level language is being used appropriately), > such a waiver is certainly reasonable (and in fact I may be wrong, but I think > there is some kind of blanket permission to use high level tools of the 4GL > type). The current DoD policy, as I recall, says that it is preferable to use 4GLs where Ada is not possible, although a specific waiver is still required. However, it doesn't say anything about needing a waiver to use tools that generate Ada code, including 4GL tools. There is no distiction drawn between writing (and maintaining) Ada code manually, and auto-generating Ada code (and maintaining some higher-level representation of the code). If you can find something specific in the DoDD or DoDI set that says this, I would like to know. If you're saying the Ada policy _should_ be this way, that's fine, but I find nothing that claims it _is_ this way. Certainly, the instructions I've received as a contractor do not require a waiver in these cases, even though our customer knows that we auto-generate Ada code, and use it as an intermediate language, in some cases. I've copied Joan McGarity on this question, perhaps she can give us the AJPO interpretation of Ada policy with respect to automatically-generated Ada code. -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* 4GL code in a deliverable (was: ARIANE-5 Failure) 1996-06-17 0:00 ` Ken Garlington @ 1996-06-18 0:00 ` Arthur Evans Jr 1996-06-19 0:00 ` Ken Garlington 0 siblings, 1 reply; 47+ messages in thread From: Arthur Evans Jr @ 1996-06-18 0:00 UTC (permalink / raw) In article <31C57C5B.6C63@lmtas.lmco.com>, Ken Garlington <garlingtonke@lmtas.lmco.com> wrote: > The current DoD policy, as I recall, says that it is preferable to use > 4GLs where Ada is not possible, although a specific waiver is still > required. However, it doesn't say anything about needing a waiver to > use tools that generate Ada code, including 4GL tools. There is no > distiction drawn between writing (and maintaining) Ada code manually, > and auto-generating Ada code (and maintaining some higher-level > representation of the code). If you can find something specific in > the DoDD or DoDI set that says this, I would like to know. > > If you're saying the Ada policy _should_ be this way, that's fine, but > I find nothing that claims it _is_ this way. Certainly, the > instructions I've received as a contractor do not require a waiver in > these cases, even though our customer knows that we auto-generate Ada > code, and use it as an intermediate language, in some cases. Suggested here and in previous notes in this thread is the idea that a contractor may without obtaining a waiver use a 4GL tool (such as MatrixX) that generates Ada code, and then submit that Ada code as part of its contract deliverable. While this strategy may be legal, in my opinion it circumvents the intent of the Ada mandate and should not be permitted. Why? A major motivation for the Ada design, starting more than 20 years ago, is to reduce the cost of software maintenance. One of the important motivations for the mandate is that code written in Ada with use of proper software engineering provides important ease of maintenance. There is (supposed to be) a clear trail from design to final code, and _all_ _tools_ _that_ _participate_ _in_ _that_ _trail_ are delivered with the product for use by the maintainers. It seems fair to assume that there is a clear trail from design, through system equations, through MatrixX code (or whatever we call it), to Ada, to the final product. My question, then, is this: Are both the source code for the 4GL and the 4GL product itself delivered? There are of course two possibilities: - The 4GL source is not delivered. In that case the maintainer has no recourse in modifying the code except to do so in Ada. I think we'll all agree that this code is essentially unmaintainable, in the sense that it can be modified with the same danger present in modifying aswsembler code produced by a compiler. The maintainer _must_ have access to the 4GL source code and the 4GL tool. - The 4GL code is delivered. But in that case the contractor is admitting (the truth) that the algorithm was expressed in this notation (that is, programmed in it), even though no waiver was obtained permitting use of other than Ada. Now, I fully support using a 4GL such as MatrixX where appropriate to express complex algorithms. My point is only that there must be an up-front acceptance that this is happening so that the final product is properly maintainable. To do otherwise is to compromise Ada's laudable goal of improved maintainability. If current DoD policy is inconsistent here, I suggest that the policy needs to be modified. Art Evans Arthur Evans Jr, PhD Phone: 412-963-0839 Ada Consulting FAX: 412-963-0927 461 Fairview Road Pittsburgh PA 15238-1933 evans@evans.pgh.pa.us ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: 4GL code in a deliverable (was: ARIANE-5 Failure) 1996-06-18 0:00 ` 4GL code in a deliverable (was: ARIANE-5 Failure) Arthur Evans Jr @ 1996-06-19 0:00 ` Ken Garlington 1996-06-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-19 0:00 UTC (permalink / raw) Arthur Evans Jr wrote: > > There is (supposed to be) a clear trail from design to final code, and > _all_ _tools_ _that_ _participate_ _in_ _that_ _trail_ are delivered > with the product for use by the maintainers. This would also imply that Ada code cannot be reused, without having access to all of the tools and databases used to create the code and associated documentation. Do you really believe this? Certainly, a Government agency can require that the software engineering environment, databases, and documentation, be delivered with a software application, particularly if the Government agency intends to maintain the code. To suggest that this is a consequence of current Ada policy is, to my thinking, more than a little bizarre. Ada source code can be delivered without the tools/databases (e.g. MatrixX) used to develop it, just as non-Ada source code may have to be delivered with such support. This decision should be based on the expected maintenance strategy. Similarly, the decision to use Ada may be influenced by the expected maintenance strategy. However, this doesn't mean that the deliverables are based on Ada policy! > It seems fair to assume that there is a clear trail from design, through > system equations, through MatrixX code (or whatever we call it), to Ada, > to the final product. My question, then, is this: Are both the source > code for the 4GL and the 4GL product itself delivered? MatrixX does not have textual "source code" per se. It has a database of information which is represented graphically. In some respects, it is similar to tools such as Teamwork or Statemate (although MatrixX is designed for a specific domain). > - The 4GL source is not delivered. In that case the maintainer has no > recourse in modifying the code except to do so in Ada. I think > we'll all agree that this code is essentially unmaintainable I think I'll disagree, having seen several examples of source code generated by auto-generation systems and later maintained manually with success. > - The 4GL code is delivered. But in that case the contractor is > admitting (the truth) that the algorithm was expressed in this > notation (that is, programmed in it), even though no waiver was > obtained permitting use of other than Ada. Would this "truth" also exist if the device used to generate the Ada code from the database was a human being, rather than a machine? It seems to me the consequence of this interpretation of Ada policy is that all requirements and design artifacts must be generated without the use of tools, else an Ada waiver is required! Fortunately, Ada waiver policy is interpreted more rationally, at least by my customer... -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: 4GL code in a deliverable (was: ARIANE-5 Failure) 1996-06-19 0:00 ` Ken Garlington @ 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Ken Garlington 1996-06-24 0:00 ` Ken Garlington 0 siblings, 2 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-20 0:00 UTC (permalink / raw) Ken said " Would this "truth" also exist if the device used to generate the Ada code from the database was a human being, rather than a machine? It seems to me the consequence of this interpretation of Ada policy is that all requirements and design artifacts must be generated without the use of tools, else an Ada waiver is required!" nonsense, no one is saying that! What is being said is that the critical point is what level the code will be maintained at. If the code is to be maintained at the Ada source level, then it matters not a whit how it was developed, by humans, clever tools, or friendly martians. If on the other hand, the maintenance is to be done on the "original" source code (which may of course be in the form of a database and not a text in the normal sense -- that makes no difference), then indeed it is important to be sure that this source code is written in an appropritae language, which is properly supported, preferably standardized, and preferably avoids the danger of single sourced tools. Ken, do you really disagree with this? If so, I am surprised, and would appreciate you making the source of your disagreement clear! ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: 4GL code in a deliverable (was: ARIANE-5 Failure) 1996-06-20 0:00 ` Robert Dewar @ 1996-06-24 0:00 ` Ken Garlington 1996-06-24 0:00 ` Ken Garlington 1 sibling, 0 replies; 47+ messages in thread From: Ken Garlington @ 1996-06-24 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Ken said > > " > Would this "truth" also exist if the device used to generate the Ada code > from the database was a human being, rather than a machine? It seems to > me the consequence of this interpretation of Ada policy is that all requirements > and design artifacts must be generated without the use of tools, else an > Ada waiver is required!" > > nonsense, no one is saying that! What is being said is that the critical > point is what level the code will be maintained at. If the code is to be > maintained at the Ada source level, then it matters not a whit how it > was developed, by humans, clever tools, or friendly martians. > > If on the other hand, the maintenance is to be done on the "original" source > code (which may of course be in the form of a database and not a text in the > normal sense -- that makes no difference), then indeed it is important to > be sure that this source code is written in an appropritae language, which > is properly supported, preferably standardized, and preferably avoids > the danger of single sourced tools. > > Ken, do you really disagree with this? If so, I am surprised, and would > appreciate you making the source of your disagreement clear! I do not disagree that this makes sense, and that in general (never mind the 4GL issue), that a contracting agency should ask for both the implementation of the software, and also the data/documentation/tools associated with that software, if the contracting agency intends to provide post-deployment support (directly or through a third party). Such a request should be written into the contract, and in fact, such requirements are part of many programs. However, you raised a much narrower issue. If a code generator is used to generate Ada source code (specifically, a code generator whose inputs are a graphical representation of the algorithms and interfaces a la MatrixX), does such an approach violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of creating an application, then it's an Ada application, independent of the process used to maintain that application. The only change introduced in 5000.2 is that, if the Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ required. If someone can quote something from 5000.2, 3405.1, or a service policy that states conditions under which a software application is built from "only" Ada source code as part of the process, but still requires an Ada waiver, I would be interested in seeing this analysis. You might argue that words should be added to these directives, but in their current form, I think they bear out my position. As to whether they _should_ have words about requiring Ada waivers for code generators, I'm ambivalent. As I said before, I agree that a system maintained at a "4GL" level should continue to be maintained at that level. (I also think that requirements databases should continue to be maintained during maintenance, for that matter). However, requiring extra paperwork to use innovative approaches to reduce the cost of generating Ada source code seems counter-productive, particularly since (a) the maintenance site may choose to maintain the software differently from the developing site, and (b) even automatically-generating Ada code can still accrue many of the benefits of the Ada policy, such as a common implementation notation, fewer tools, etc. Note that this discussion points out a well-known (at least, I _thought_ it was a well-known) flaw in the Ada policy as written. Just requiring software to be written in Ada does not, by itself, cause fundamental improvements in depot costs. Other issues, such as the number of different tools required, the number of documentation and data formats/conventions used, etc. also have large effects. Ada policy may indirectly improve some of these other factors, but it has to be coupled with other initiatives (e.g. electronic data exchange standards) to provide large-scale returns. -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: 4GL code in a deliverable (was: ARIANE-5 Failure) 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Ken Garlington @ 1996-06-24 0:00 ` Ken Garlington 1 sibling, 0 replies; 47+ messages in thread From: Ken Garlington @ 1996-06-24 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Ken said > > " > Would this "truth" also exist if the device used to generate the Ada code > from the database was a human being, rather than a machine? It seems to > me the consequence of this interpretation of Ada policy is that all requirements > and design artifacts must be generated without the use of tools, else an > Ada waiver is required!" > > nonsense, no one is saying that! What is being said is that the critical > point is what level the code will be maintained at. If the code is to be > maintained at the Ada source level, then it matters not a whit how it > was developed, by humans, clever tools, or friendly martians. > > If on the other hand, the maintenance is to be done on the "original" source > code (which may of course be in the form of a database and not a text in the > normal sense -- that makes no difference), then indeed it is important to > be sure that this source code is written in an appropritae language, which > is properly supported, preferably standardized, and preferably avoids > the danger of single sourced tools. > > Ken, do you really disagree with this? If so, I am surprised, and would > appreciate you making the source of your disagreement clear! I do not disagree that this makes sense, and that in general (never mind the 4GL issue), that a contracting agency should ask for both the implementation of the software, and also the data/documentation/tools associated with that software, if the contracting agency intends to provide post-deployment support (directly or through a third party). Such a request should be written into the contract, and in fact, such requirements are part of many programs. However, you raised a much narrower issue. If a code generator is used to generate Ada source code (specifically, a code generator whose inputs are a graphical representation of the algorithms and interfaces a la MatrixX), does such an approach violate the DoD Ada policy, and therefore require a _waiver_? My reading of DoD 5000.2-R and DoDD 3405.1 indicates that if Ada source code is used in the process of creating an application, then it's an Ada application, independent of the process used to maintain that application. The only change introduced in 5000.2 is that, if the Government has _no_ interest in what maintenance process is chosen, then Ada is _not_ required. If someone can quote something from 5000.2, 3405.1, or a service policy that states conditions under which a software application is built from "only" Ada source code as part of the process, but still requires an Ada waiver, I would be interested in seeing this analysis. You might argue that words should be added to these directives, but in their current form, I think they bear out my position. As to whether they _should_ have words about requiring Ada waivers for code generators, I'm ambivalent. As I said before, I agree that a system maintained at a "4GL" level should continue to be maintained at that level. (I also think that requirements databases should continue to be maintained during maintenance, for that matter). However, requiring extra paperwork to use innovative approaches to reduce the cost of generating Ada source code seems counter-productive, particularly since (a) the maintenance site may choose to maintain the software differently from the developing site, and (b) even automatically-generating Ada code can still accrue many of the benefits of the Ada policy, such as a common implementation notation, fewer tools, etc. Note that this discussion points out a well-known (at least, I _thought_ it was a well-known) flaw in the Ada policy as written. Just requiring software to be written in Ada does not, by itself, cause fundamental improvements in depot costs. Other issues, such as the number of different tools required, the number of documentation and data formats/conventions used, etc. also have large effects. Ada policy may indirectly improve some of these other factors, but it has to be coupled with other initiatives (e.g. electronic data exchange standards) to provide large-scale returns. -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-08 0:00 ` Robert Dewar 1996-06-09 0:00 ` Samuel Mize @ 1996-06-09 0:00 ` Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Ken Garlington 2 siblings, 0 replies; 47+ messages in thread From: Dale Stanbrough @ 1996-06-09 0:00 UTC (permalink / raw) Robert Dewar writes: "Sounds bogus, ultimately the code is maintained by humans, we do not yet have robots that can write and maintain code. Sure the code may be in some other language than Ada and then generate Ada (if the Ada is not maintained, but is just used as an intermediate language, it is essentially irrelevant that it is Ada). So the question is: what language WAS the software written in? And what is the argument that this code is easier to maintain than properly written Ada?" I'm not sure this really answers Robert's questions. Nonetheless, here they are...a few postings from previous years. I think I may have displaced David Weller as the ultimate posting hoarder! :-). Dale ------------------------------------------------------ From: berman@umbc.edu (Mike Berman) Newsgroups: comp.lang.ada Subject: DC-X use of Ada Date: 15 Sep 1993 17:45:40 -0400 Organization: University of Maryland, Baltimore County Campus In its September 13 "Filter Center", Aviation Week and Space Technology mentions that McDonnell Douglas developed software for guidance and control of the DC-X Single-Stage-to_Orbit (SSTO) launch vehicle using the MATRIXx toolset from Integrated Systems, Inc. Use of the tool saved an estimated 50% of normal development costs and "produced very reliable code". The article mentions that there are more than 30,000 lines of Ada code, but does not say how much was hand crafted vs. tool generated. A recent posting summarized the successful first flight of the DC-X test vehicle. An Ada success story? Could be... -- Mike Berman University of Maryland, Baltimore County Fastrak Training, Inc. berman@umbc.edu (301)924-0050 The views represented in the above post are my own. --------------------------------------------------------------------------- Also posted... (and note info on the "explosion" later on). Dale --------------------------------------------------------------------------- Newsgroups: comp.lang.ada Subject: DC-X Test Flight Date: 8 Sep 1993 13:10:45 -0500 Organization: Washington University in Saint Louis, MO Summary: DC-X, whose software is in Ada, flew successfully in late August Several months ago, Jerry Pournelle started his User's Column in Byte with a description of the DC-X and its software. Jerry added that he spoke with the lead of the software development team and found that, for the first time in the team's experience, software came in on time and schedule. The software for DC-X (Douglas Clipper - Experimental) was written in Ada using MatrixX. More information on DC-X can be found in the August 30 issue of Time, page 47. Thought this group might be interested. -- Rick Conn The following is from the posting to sci.space.news on 8/28/93. |> DC-X Post-Flight Condition |> |> The worst thing that happened to DC-X during this first flight was that one |> side of the fiberglass nose cone was scorched. It will have to be replaced, |> no big deal as there are several spares. This probably happened right after |> engine start, when the cloud of vented hydrogen around the vehicle ignited. |> |> This looked scary, but is a routine part of operating DC-X, albeit one |> that turned out to be a bit more spectacular than planned. Liquid hydrogen |> is run through the engines to precool them before startup, then vented to the |> air, producing the vapor clouds visible before engine start in the flight test |> video footage. When the engines start, unless there's a strong breeze the |> hydrogen concentration neaby is high enough to ignite, producing a half-second |> fireball around the bottom of the vehicle. |> |> This is how DC-X lost its McDonnell-Douglas and SDIO decals and had its white |> factory paint job turned to mottled gray during the test stand engine |> firings back in May and June. Everything below the nose cone is designed to |> stand the heat, and of course in any spaceworthy descendant of DC-X the nose |> cone would not be made from fiberglass, since it would have to stand up to |> far worse heat during reentry. |> |> Outside of that, DC-X's base suffered some minor dings from bits of concrete |> sent flying around by the rocket blast during landing. Nothing unexpected; |> the base was designed to stand a fair amount of this. ------------------------------------------------------------------------------ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-08 0:00 ` Robert Dewar 1996-06-09 0:00 ` Samuel Mize 1996-06-09 0:00 ` ARIANE-5 Failure Dale Stanbrough @ 1996-06-10 0:00 ` Ken Garlington 1996-06-14 0:00 ` Robert Dewar 2 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-10 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Eugene says > > "vehicles have problems. The DC-X flight control software is in Ada and > is all computer generated. You would not want to maintain this code by > hand." > > Sounds bogus, ultimately the code is maintained by humans, we do not yet > have robots that can write and maintain code. Sure the code may be in > some other language than Ada and then generate Ada (if the Ada is not > maintained, but is just used as an intermediate language, it is > essentially irrelevant that it is Ada). So the question is: what > language WAS the software written in? And what is the argument that > this code is easier to maintain than properly written Ada? Based on various reports, MatrixX was used to develop the DC-X flight control laws using standard control law notation, and then the System Build module was used to generate Ada code for the control laws. MatrixX has had the ability to generate Ada and C code for some time. The main reason this code could be considered easier to maintain is that, usually, control law engineers have limited experience coding software. So, being able to "program" with control law notation makes it easier for them. Also, by eliminating the manual translation of the control laws to code, there would presumably be fewer errors in the final product. I don't know if it is fair to say that generating code in Ada vs. C is "irrelevant" in this context, since you will still get the benefits of strong typing, etc. when the code is compiled. On the other hand, assuming that MatrixX eliminates some of these errors during the control law design, perhaps this extra support is less important. I've noticed that a lot of flight control system (and engine control system) developers are going to this approach of auto-generating code from the control law design. Some generate FORTRAN, some C, and some Ada. It would be interesting to find out if there are any inherent advantages in auto- generating in one language vs. the others. Anyway, with respect to the Ariane 5, I'm not ready to say that this was a software failure yet. If it is, it will be interesting to see if the language choice was a factor in the failure. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Ken Garlington @ 1996-06-14 0:00 ` Robert Dewar 1996-06-17 0:00 ` Ken Garlington 0 siblings, 1 reply; 47+ messages in thread From: Robert Dewar @ 1996-06-14 0:00 UTC (permalink / raw) Ken Garlington said "I don't know if it is fair to say that generating code in Ada vs. C is "irrelevant" in this context, since you will still get the benefits of strong typing, etc. when the code is compiled. On the other hand, assuming that MatrixX eliminates some of these errors during the control law design," Surely MatrixX cannot generate type incorrect code -- I can't see that this comment is relevant. When generating code, many of the features that are critical for normal programming become irrelevant or at any rate much less important. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure (DC-X works) 1996-06-14 0:00 ` Robert Dewar @ 1996-06-17 0:00 ` Ken Garlington 1996-06-19 0:00 ` 4THGL code Warren Taylor 0 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-17 0:00 UTC (permalink / raw) Robert Dewar wrote: > > Surely MatrixX cannot generate type incorrect code... You have more confidence than I do in MatrixX! However, I was thinking more in terms of trapping invalid values at execution time. Certainly, a user can generate a control law diagram that generates out-of-bounds results under certain conditions. If this software is used to drive a system simulation, then the Ada might fail in an obvious manner (and so the error would be detected), while some other language might fail in a subtle way -- or not at all, for the particular initial conditions. -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* 4THGL code 1996-06-17 0:00 ` Ken Garlington @ 1996-06-19 0:00 ` Warren Taylor 0 siblings, 0 replies; 47+ messages in thread From: Warren Taylor @ 1996-06-19 0:00 UTC (permalink / raw) As a subcontractor to Boeing on ISS (aka ISSA aka SSF), we (Orbital Sciences) have been mandated by Boeing to use the MatrixX (ISI) system for all of our deliverable software, and have been working with the system for the last 5 or 6 years. In our case, the generated ADA code is not the deliverable, and in fact we don't even CM it. The MatrixX diagrams, along with some human coded Ada and a very small amount of assembler (IPL and boot code) are the "source" code for this system. As far as I know, all space station software from all subcontractors is to be developed under this environment. As far as the choice of intermediate language goes, I can only relate that MatrixX does sometimes produce buggy Ada code, which is usually caught by the compiler. I vote for Ada as the intermediate language for this reason. All of our I/O and self test code with hardware interfaces was coded in Ada, including interrupt handlers. By the way, the system is very far along in testing at this point, and no "show stoppers" have developed in any part of the system. Warren Taylor Senior Principal Engineer, OSC ^ permalink raw reply [flat|nested] 47+ messages in thread
* Automatic code generation (was ARIANE-5 Failure (DC-X works)) 1996-06-08 0:00 ` Samuel Mize 1996-06-09 0:00 ` ARIANE-5 Failure (DC-X works) Eugene W.P. Bingue @ 1996-06-12 0:00 ` Steve Vestal 1 sibling, 0 replies; 47+ messages in thread From: Steve Vestal @ 1996-06-12 0:00 UTC (permalink / raw) MATRIXx is one of a number of toolsets that allow feed-back control engineers to specify both control algorithms and models of physical systems in what some call a domain-specific language (MATLAB, BEACON, ACSL, and our own ControlH are other examples). Such languages are used to model plants (e.g. aircraft) as well as specify control algorithms. The tools typically support simulation and mathematical analysis as well as automatic generation of code. I think computer scientists would catalog them as data flow languages, although they have a precise semantics based on dynamical systems theory (the meaning of a specification is a system of differential or difference equations, at least until the control engineer starts throwing in discrete event or procedural constructs :-) There are several reasons why we think the nature of the code produced by such tools is a consideration, and we favor generation of well-structured code where there is good traceability between specification and code (a principle we try to follow in our tools): - Some bugs first manifest themselves at the "object" code level. For example, on several occasions I have been given a specification that was debugged in simulation (using C code generation), flipped the translator switch to generate Ada code for a real-time target, and discovered the algorithm was dividing by zero (something C seems to allow and Ada seems to think objectionable). It is helpful to be able to read the generated code and trace bugs found at that level back to the originating constructs in the control specification. - Safety-critical software requires various certification steps, typically including unit testing that achieves full path coverage (according to a particular definition of path) on the target hardware. It is helpful if the generated code is broken into units as that term is used by the software testers, and it is helpful if localized changes in the control specification cause only a few units to be re-generated and re-unit-tested. - There are other kinds of domain-specific languages and generators used by other kinds of engineers for other purposes, e.g. generators of display management code. A complex system (such as an avionics system) consists of many kinds of functions, only some of which are candidates for automatic generation from feed-back control specifications. In general, automatically generated code produced by various tools will need to be integrated with each other, with hand-written modules, and with modules re-engineered/re-used from previous systems. (Software and (computer) systems analysis and integration is a problem area in its own right, we have another language and toolset for that task called MetaH.) We generate both Ada and C. Unconstrained arrays were certainly a convenience when generating code from a language where matrices are a fundamental data type. Discriminant records were also a convenience. Our web pages contain some more information, although not about Ada issues specifically: http://www.htc.honeywell.com/projects/dssa Steve Vestal Mail: Honeywell Technology Center, 3660 Technology Drive, Minneapolis MN 55418 Phone: (612) 951-7049 Fax: 7438 Email: vestal_steve@htc.honeywell.com ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre 1996-06-07 0:00 ` David Weller @ 1996-06-07 0:00 ` Ken Garlington 1996-06-07 0:00 ` Robert Dewar 1996-06-07 0:00 ` John McCabe 1996-06-07 0:00 ` Bert Peers ` (4 subsequent siblings) 6 siblings, 2 replies; 47+ messages in thread From: Ken Garlington @ 1996-06-07 0:00 UTC (permalink / raw) Tronche Ch. le pitre wrote: > > John McCabe wrote: > > > > I have heard that the failure of the Ariane 5 rocket's first launch on > > Tuesday was caused by a software fault in the attitude control system. > > French media have presented several successive explanations but always > invoking software failure. Aerospace Daily said that the current explanation was an erroneous command from the flight control computers to the nozzles, driving them all hard over. Such a command could be due to software, or to interface electronics failure, or possibly noise on the wire connecting the two. I wouldn't be ready to blame the software just yet. Of course, assuming that the root cause is traced to the software, what of it? Using Ada certainly doesn't ensure proper operation of a software system! -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` ARIANE-5 Failure Ken Garlington @ 1996-06-07 0:00 ` Robert Dewar 1996-06-07 0:00 ` John McCabe 1 sibling, 0 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-07 0:00 UTC (permalink / raw) Ken said "Of course, assuming that the root cause is traced to the software, what of it? Using Ada certainly doesn't ensure proper operation of a software system! " Certainly not, on the other hand, it will be interesting to know more details. You can certainly ask whether a language could have helped when you now consider the exact cause of the problem narrowed down to source code. For instance, I think the Fortran language design bears at least a piece of responsibility for the Venus probe bug. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` ARIANE-5 Failure Ken Garlington 1996-06-07 0:00 ` Robert Dewar @ 1996-06-07 0:00 ` John McCabe 1 sibling, 0 replies; 47+ messages in thread From: John McCabe @ 1996-06-07 0:00 UTC (permalink / raw) Ken Garlington <garlingtonke@lmtas.lmco.com> wrote: >Of course, assuming that the root cause is traced to the software, what of >it? Using Ada certainly doesn't ensure proper operation of a software system! You're quite right and I didn't intend to imply anything by my original message. According to ESA/CNES press release 20.96, "Preliminary analysis of the telemetry data confirms that the propulsion stages (solid boosters and cryogenic main stage) functioned correctly. The direction of inquiry is tending towards the launcher's "electrical and software system"" I find it strange that they have mentioned "software" system rather than "computer" system. They seem to have pointed the finger already. It'll be interesting to see what the outcome is. It could so easily just have been a sensor fault but I would have thought there would have been adequate sensors to overcome/reduce the possibility of single point failures. My main interest in this matter is due to the fact that I work for the UK part of the company that built the attitude control system and we are actually using some of the equipment that was developed on the Ariane 5 programme in the project I am currently working on. Best Regards John McCabe <john@assen.demon.co.uk> ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre 1996-06-07 0:00 ` David Weller 1996-06-07 0:00 ` ARIANE-5 Failure Ken Garlington @ 1996-06-07 0:00 ` Bert Peers 1996-06-08 0:00 ` Jim Kingdon ` (3 subsequent siblings) 6 siblings, 0 replies; 47+ messages in thread From: Bert Peers @ 1996-06-07 0:00 UTC (permalink / raw) >Sad to say, but the software is entirely written in Ada, Particularly unfortunate since the moment I saw the news about the software cause on TV I immediately cheered "Should have used Ada !!!" ! :( Cya, Bert -=<www.cs.kuleuven.ac.be/~peers>=- [ You know you're in CGI too long when... you think "ota" is Japanese for "story" ] OPGELET: Deze Email negeert de nieuwe spelling. (Mogelijks ook de oude). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre ` (2 preceding siblings ...) 1996-06-07 0:00 ` Bert Peers @ 1996-06-08 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Jim Kingdon ` (2 subsequent siblings) 6 siblings, 0 replies; 47+ messages in thread From: Jim Kingdon @ 1996-06-08 0:00 UTC (permalink / raw) > > I have heard that the failure of the Ariane 5 rocket's first launch on > > Tuesday was caused by a software fault in the attitude control system. There is a variety of information on this at http://www.flatoday.com/today/ and http://www.esrin.esa.it/. The 6 Jun press release says they are loking at software, but as nearly as I could tell there are also other causes which are being considered. So if anyone wants to post solid information, great, but IMHO, there isn't much point in speculating. > I don't think one has never see number 1 of any rocket succeeded in > the aerospace industry history. Check out Jonathan's space report #289 at http://hea-www.harvard.edu/QEDT/jcm/space/jsr/jsr.html. He has a list of the first flights of new (not upgraded) first stages. Maybe half of them have succeeded (whether the upper stages, if any, succeeded also he doesn't list). ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre ` (3 preceding siblings ...) 1996-06-08 0:00 ` Jim Kingdon @ 1996-06-09 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Jim Kingdon 1996-06-10 0:00 ` William Clodius 6 siblings, 0 replies; 47+ messages in thread From: Jim Kingdon @ 1996-06-09 0:00 UTC (permalink / raw) > Didn't DC-X have a pad fire? I'm not sure I should keep answering space questions on *comp.lang.ada*, but the latest details on DC-XA, including the (minor, May 18, 1996) fire which you mention, can be found at http://cc.usu.edu/~slfn6/dcxa/. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre ` (4 preceding siblings ...) 1996-06-09 0:00 ` Jim Kingdon @ 1996-06-09 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Robert Dewar 1996-06-10 0:00 ` William Clodius 6 siblings, 1 reply; 47+ messages in thread From: Jim Kingdon @ 1996-06-09 0:00 UTC (permalink / raw) > For instance, I think the Fortran language design bears at least a piece > of responsibility for the Venus probe bug. You mean the one which gets blamed on DO I=1.20 (where DO I=1,20 is meant)? Do you happen to have a reference for this? My (very vague) recollection is that some people have said this story is true and others have said it apocryphal, and I don't think I've seen anything authoritative either way. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-09 0:00 ` Jim Kingdon @ 1996-06-09 0:00 ` Robert Dewar 1996-06-10 0:00 ` Keith Thompson 1996-06-10 0:00 ` Dewi Daniels 0 siblings, 2 replies; 47+ messages in thread From: Robert Dewar @ 1996-06-09 0:00 UTC (permalink / raw) Jim asked: "Do you happen to have a reference for this? My (very vague) recollection is that some people have said this story is true and others have said it apocryphal, and I don't think I've seen anything authoritative either way." Nope, I don't know if it is true or apocryphal. It is widely enough known to use as a good example anyway, even if it is not true :-) But it would be nice to find out, anyone on this list have a REALLY AUTHORITATIVE first-hand source for the truth on this one (it is one that many people "know" the answer to, but as Jim pointed out, they disagree and can't all be right!) ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-09 0:00 ` Robert Dewar @ 1996-06-10 0:00 ` Keith Thompson 1996-06-10 0:00 ` Dewi Daniels 1 sibling, 0 replies; 47+ messages in thread From: Keith Thompson @ 1996-06-10 0:00 UTC (permalink / raw) In <dewar.834362765@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes: [...] > But it would be nice to find out, anyone on this list have a REALLY > AUTHORITATIVE first-hand source for the truth on this one (it is one > that many people "know" the answer to, but as Jim pointed out, they > disagree and can't all be right!) Perhaps this isn't "REALLY AUTHORITATIVE", but it seems to be within two or three steps of being first-hand knowledge. According to Paul Ceruzzi's book "Beyond the Limits -- Flight Enters the Computer Age", the loss of the Mariner I Venus probe was due not to a Fortran error, but to a missing bar in a hand-written equation. For details, see RISKS Digest 8.75, available at <http://catless.ncl.ac.uk/Risks/8.75.html>. -- Keith Thompson (The_Other_Keith) kst@thomsoft.com <*> TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718 This sig uses the word "Exon" in violation of the Communications Decency Act. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-09 0:00 ` Robert Dewar 1996-06-10 0:00 ` Keith Thompson @ 1996-06-10 0:00 ` Dewi Daniels 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-13 0:00 ` Jan Kok 1 sibling, 2 replies; 47+ messages in thread From: Dewi Daniels @ 1996-06-10 0:00 UTC (permalink / raw) dewar@cs.nyu.edu (Robert Dewar) wrote: >Jim asked: > >"Do you happen to have a reference for this? My (very vague) >recollection is that some people have said this story is true and >others have said it apocryphal, and I don't think I've seen anything >authoritative either way." > >Nope, I don't know if it is true or apocryphal. It is widely enough known >to use as a good example anyway, even if it is not true :-) > >But it would be nice to find out, anyone on this list have a REALLY >AUTHORITATIVE first-hand source for the truth on this one (it is one >that many people "know" the answer to, but as Jim pointed out, they >disagree and can't all be right!) > From the alt.folklore.computers FAQ at http://www.best.com/~wilson/faq: III.1 - I heard that one of the NASA space probes went off course and had to be destroyed because of a typo in a FORTRAN DO loop. Is there any truth to this rumor? This answer by Mark Brader . Quoted items in it have been reformatted but not abridged. As revealed by past discussion in comp.risks (Risks Digest) as well as alt.folklore.computers and occasionally other newsgroups, this turns out to be a confusion of two separate events. The space probe that the DO-loop story has been wrongly attached to is Mariner I (or 1), which was intended for Venus (not Mars). Several incorrect or partially correct versions of what really happened were posted in comp.risks; the best of these cited a NASA publication called "Far Travelers" by Oran W. Nicks, but still did not have the whole story. Then in issue 8.75 we found out what really happened... | Date: Sat, 27 May 1989 15:34:33 PDT | From: Peter Neumann | Subject: Mariner I -- no holds BARred | | Paul Ceruzzi has written a truly outstanding book for the new show | that opened two weeks ago at the Smithsonian National Air and Space | Museum. The exhibit and the book are both entitled "Beyond the Limits | -- Flight Enters the Computer Age". Both are superb. Go for it (them). | | Paul has dug into several cases treated previously in RISKS and in | issues of the ACM Software Engineering Notes, and has been able to | resolve several mysteries. In particular he considers the case of | Mariner I, about which various inaccurate stories have been told. | Intended to be the first US spacecraft to visit another planet, it was | destroyed by a range officer on 22 July 1962 when it behaved | erratically four minutes after launch. The alleged missing `hyphen' | was really a missing `bar'. I quote from Paul's book, pp. 202-203: | | # During the launch the Atlas booster rocket was guided with the help | # of two radar systems. One, the Rate System, measured the velocity of | # the rocket as it ascended through the atmosphere. The other, the | # Track System, measured its distance and angle from a tracking | # antenna near the launch site. At the Cape a guidance computer | # processed these signals and sent control signals back to the | # tracking system, which in turn sent signals to the rocket. Its | # primary function was to ensure a proper separation from the Atlas | # booster and ignition of the Agena upper stage, which was to carry | # the Mariner Spacecraft to Venus. | # | # Timing for the two radar systems was separated by a difference of | # forty-three milliseconds. To compensate, the computer was instructed | # to add forty-three milliseconds to the data from the Rate System | # during the launch. This action, which set both systems to the same | # sampling time base, required smoothed, or averaged, track data, | # obtained by an earlier computation, not the raw velocity data | # relayed directly from the track radar. The symbol for this smoothed | # data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n], | # where R stands for the radius, the dot for the first derivative | # (i.e., the velocity), the bar for smoothed data, and n for the | # increment. | # | # The bar was left out of the hand-written guidance equations. [A | # footnote cites interviews with John Norton and General Jack Albert.] | # Then during launch the on-board Rate System hardware failed. That in | # itself should not have jeopardized the mission, as the Track System | # radar was working and could have handled the ascent. But because of | # the missing bar in the guidance equations, the computer was | # processing the track data incorrectly. [Paul's EndNote amplifies: | # The Mariner I failure was thus a {\it combination} of a hardware | # failure and the software bug. The same flawed program had been used | # in several earlier Ranger launches with no ill effects.] The result | # was erroneous information that velocity was fluctuating in an | # erratic and unpredictable manner, for which the computer tried to | # compensate by sending correction signals back to the rocket. In fact | # the rocket was ascending smoothly and needed no such correction. The | # result was {\it genuine} instead of phantom erratic behavior, which | # led the range safety officer to destroy the missile, and with it the | # Mariner spacecraft. Mariner I, its systems functioning normally, | # plunged into the Atlantic. The DO-loop incident did happen at NASA, and at about the same time. As told by Fred Webb in alt.folklore.computers in 1990: | I worked at Nasa during the summer of 1963. The group I was working | in was doing preliminary work on the Mission Control Center computer | systems and programs. My office mate had the job of testing out an | orbit computation program which had been used during the Mercury | flights. Running some test data with known answers through it, he was | getting answers that were close, but not accurate enough. So, he | started looking for numerical problems in the algorithm, checking to | make sure his tests data was really correct, etc. | | After a couple of weeks with no results, he came across a DO | statement, in the form: | DO 10 I=1.10 | This statement was interpreted by the compiler (correctly) as: | DO10I = 1.10 | The programmer had clearly intended: | DO 10 I = 1, 10 | | After changing the `.' to a `,' the program results were correct to | the desired accuracy. Apparently, the program's answers had been | "good enough" for the sub-orbital Mercury flights, so no one suspected | a bug until they tried to get greater accuracy, in anticipation of | later orbital and moon flights. As far as I know, this particular bug | was never blamed for any actual failure of a space flight, but the | other details here seem close enough that I'm sure this incident is the | source of the DO story. Project Mercury's sub-orbital flights were in 1961, and its orbital flights began in 1962. I forwarded the above to comp.risks, slightly abridged, and it appeared there in issue 9.54. The erroneous claim that the DO-loop bug was the bug that killed Mariner I apparently originated with, and certainly was propagated by, the book "Software Reliability: Principles and Practices" by G(lenford) J. Myers (John Wiley & Sons, 1976). I haven't read it myself; I've seen the page numbers 7 and 275 attributed to the assertion. I expect both are right. This book also describes the bug as a "billion-dollar error", which is too large by a factor of about 50. In some earlier postings it was suggested that Myers be located and asked about his sources (the book gives none), but nobody successfully did this; his employer at the time of publication didn't have his current address. My guess is that he simply made an error or more likely accepted someone else's wrong recollection, and didn't feel it necessary to go to original sources to verify what was only an illustrative point anyway. -- Dewi Daniels Guildford, England ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-10 0:00 ` Dewi Daniels @ 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-12 0:00 ` Ken Garlington 1996-06-13 0:00 ` Jan Kok 1 sibling, 1 reply; 47+ messages in thread From: Theodore E. Dennison @ 1996-06-12 0:00 UTC (permalink / raw) Dewi Daniels wrote: > From the alt.folklore.computers FAQ at > http://www.best.com/~wilson/faq: > > Then in issue 8.75 we found out what really happened... > > | erratically four minutes after launch. The alleged missing `hyphen' > | was really a missing `bar'. I quote from Paul's book, pp. 202-203: > | > | # relayed directly from the track radar. The symbol for this smoothed > | # data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n], > | # where R stands for the radius, the dot for the first derivative > | # (i.e., the velocity), the bar for smoothed data, and n for the > | # increment. Still, if thy had named their variables Radius.Velocity_Smoothed_N and Radius.Velocity_N (their language probably didn't even allow this), the odds of this error being discovered by someone before the failure would have been MUCH greater. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-12 0:00 ` Theodore E. Dennison @ 1996-06-12 0:00 ` Ken Garlington 1996-06-13 0:00 ` Theodore E. Dennison 0 siblings, 1 reply; 47+ messages in thread From: Ken Garlington @ 1996-06-12 0:00 UTC (permalink / raw) Theodore E. Dennison wrote: > > Still, if thy had named their variables Radius.Velocity_Smoothed_N and > Radius.Velocity_N (their language probably didn't even allow this), the > odds of this error being discovered by someone before the failure would > have been MUCH greater. Well, this notation would have to have been used in the requirements to be meaningful, and I don't think most systems engineers want to write math equations in Ada! There was a study a few years back by a Dr. Avezziani [sp] attempting to show the worth of N-version programming. He had several teams use a high-quality software development process to build a subset of a flight control system. There was only one common-mode error found. Each team had been given a photocopy of the control law diagrams to implement. There was a number, something like 5.122, on one of the gains. However, the smudged photocopy made it look like 5,122. Each team used the constant 5,122 in their code. (I'm not sure how this proved the use of N-version programming, but that's another issue). It's amazing how tiny changes in dense notations add up to big errors. Maybe the real lesson learned is to use better equation editors, and avoid the Xerox machine! > > -- > T.E.D. > | Work - mailto:dennison@escmail.orl.mmc.com | > | Home - mailto:dennison@iag.net | > | URL - http://www.iag.net/~dennison | -- LMTAS - "Our Brand Means Quality" ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-12 0:00 ` Ken Garlington @ 1996-06-13 0:00 ` Theodore E. Dennison 0 siblings, 0 replies; 47+ messages in thread From: Theodore E. Dennison @ 1996-06-13 0:00 UTC (permalink / raw) Ken Garlington wrote: > > Theodore E. Dennison wrote: > > > > Still, if thy had named their variables Radius.Velocity_Smoothed_N and > > Radius.Velocity_N (their language probably didn't even allow this), the > > odds of this error being discovered by someone before the failure would > > have been MUCH greater. > > Well, this notation would have to have been used in the requirements to be > meaningful, and I don't think most systems engineers want to write > math equations in Ada! Well, the general idea was that someone "in the know" would look at the code, perhaps at a walkthough, and notice the error. Given my general experience with walkthoughs, I'll have to admit that I'm treading in la-la land here... -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-10 0:00 ` Dewi Daniels 1996-06-12 0:00 ` Theodore E. Dennison @ 1996-06-13 0:00 ` Jan Kok 1 sibling, 0 replies; 47+ messages in thread From: Jan Kok @ 1996-06-13 0:00 UTC (permalink / raw) In article <31bc75ed.1932371@news.cableol.net> dewi@mail.cableol.net (Dewi Daniels) writes: ... >The erroneous claim that the DO-loop bug was the bug that killed >Mariner I apparently originated with, and certainly was >propagated by, the book "Software Reliability: Principles and >Practices" by G(lenford) J. Myers (John Wiley & Sons, 1976). I >haven't read it myself; I've seen the page numbers 7 and 275 >attributed to the assertion. I expect both are right. This book also >describes the bug as a "billion-dollar error", which is too large by a >factor of about 50. Even in these modern times books can still be retrieved from old-fashioned libraries. I looked up Myers. The reference and the page numbers are correct. Myers actually speaks about destination Venus (not important as the legend has that it did not arrive). I cannot find a reference that supports Myers' story. -- --Jan Kok E-mail: Jan.Kok@cwi.nl | =#===-=========##= Address: CWI (dpt. NW) | -- ,___@ P.O. Box 94079 / 1090 GB Amsterdam | -- __/\ URL: http://www.cwi.nl/~jankok | ' /_ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-07 0:00 ` Tronche Ch. le pitre ` (5 preceding siblings ...) 1996-06-09 0:00 ` Jim Kingdon @ 1996-06-10 0:00 ` William Clodius 6 siblings, 0 replies; 47+ messages in thread From: William Clodius @ 1996-06-10 0:00 UTC (permalink / raw) The association of the Venus probe failure with Fortran has long been identified as an urban myth. The Venus probe software that failed was not written in Fortran and the softare failure had nothing to do with misreading a statement of the form DO 10 I=1. 10 as is commonly reported. The Venus probe failure was caused by a typographical error that caused the instantaneous velocity to be used in the guidance system (rather than the required running average velocity) resulting in an instability in the system. The language used in the software allowed the use of special typographical symbols, and the person who entered the code failed to notice that the quantity should be entered with a "bar" above it, which indicated that it was an average quantity. On the other hand a (non-fatal) software failure in the Mercury flight system was identified with the misreading of a statement of the form DO 10 I=1. 10 as the assignment DO10I = 1.10 For short orbits this error had no observed effects, but on longer orbits a consistent error in the reentry position was discovered to be due to this error. -- William B. Clodius Phone: (505)-665-9370 Los Alamos National Laboratory Email: wclodius@lanl.gov Los Alamos, NM 87545 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-06 0:00 ARIANE-5 Failure John McCabe 1996-06-07 0:00 ` Tronche Ch. le pitre @ 1996-06-07 0:00 ` Theodore E. Dennison 1996-06-10 0:00 ` William Clodius 2 siblings, 0 replies; 47+ messages in thread From: Theodore E. Dennison @ 1996-06-07 0:00 UTC (permalink / raw) John McCabe wrote: > > I have heard that the failure of the Ariane 5 rocket's first launch on > Tuesday was caused by a software fault in the attitude control system. > > Does anyone know whether Ada was used on that system, and if so, who > designed and built the software, and which compiler and target were > used. I was wondering the same thing. They said that the crash was caused by the rocket recieving an "false computer command", which caused it to make a hard left at full thrust (a BAD thing). They don't know the source of the command yet, other than it happened somewhere on-board the rocket. So its a bit early to try and blame any individual component, much less the compiler used for the software on any individual component. Here's the full story as I read it: False computer command blamed in Ariane V failure A spurious computer command sent the first Ariane V booster heeling over sideways only 37 seconds into its inaugural flight, wrecking what had been shaping up to be a textbook flight and throwing Europe's civil and commercial space program into uncertainty over the long-term. But loss of the $500 million vehicle Tuesday should not impact the lucrative commercial launch program managed by Arianespace in the near term. The European launch services consortium has enough Ariane IV boosters in stock or on order to keep up its pace through 1998, and could order more of the veteran launch vehicles if necessary. European space officials told reporters at the Ariane V launch complex in Kourou, French Guiana, yesterday that the main task of the inquiry board probing the failure will be to learn the source of the command, which sent all three of the huge rocket's nozzles swiveling as far to the side as they would go. The abrupt pitchover sheared off the vehicle's upper stage and short- version fairing with the European Space Agency's four Cluster scientific satellites inside, triggering an automatic on-board self-destruct command that was quickly followed with a command-destruct signal from controllers on the ground. The flight that was to have placed the Cluster satellites in elliptical orbits as far as 125,000 kilometers from Earth ended at an altitude of about four kilometers (DAILY, June 5). Jean-Marie Luton, head of the European Space Agency, said in Kourou that the inquiry board will be established by the end of this week, with orders to issue at least an interim report by July 15. Although even before the launch failure European press reports were questioning the high cost of the program - 20% over budget at $8 billion to date - Luton said ESA member nations remained committed to the program after the explosion. Daniel Mugnier, launch operations director for the French Space Agency (CNES), which manages the Ariane V program for ESA, told reporters in Kourou that the false signal from the On-Board Computer caused hydraulic nozzle actuators for the twin solid rocket boosters that provide 95% of the rocket's power on ascent to hit their hard stops, flipping the vehicle on its side. The nozzle on the Vulcain main engine also swivelled, Mugnier said, even though it normally is activated only if the solid booster nozzles are unable to make a course correction. Pre-flight testing found no problems The source of the false command was unclear based on preliminary analysis of telemetry tapes, Mugnier said. Both the primary and backup on- board inertial reference systems were producing the same readings, he said, allaying suspicion that they were the source of the error. Guidance software and hardware all checked out on the ground, and Luton said the inquiry board will try to determine why the testing did not detect the fatal problem. ESA had planned a second Ariane V qualification flight in October or November, but that schedule will slip until the cause of the failure is pinpointed and fixed. Although the primary payload on that flight is ESA's Atmospheric Reentry Demonstrator, Arianespace is trying to market 3.5 tons in unused geostationary transfer payload capability at a $20-$25 million discount, according to Doug Heydon, president of Arianespace Inc., the U.S. subsidiary of the European consortium. Heydon said the payload for the third Ariane V flight, originally targeted for March 1997, is also unclear. PanAmSat, the original customer, was already looking for a different launcher for scheduling reasons, he said, while officials in Kourou said there is a remote chance ESA will want to dedicate the third flight qualification rather than commercial purposes. Arianespace will continue to offer a free reflight to early Ariane V customers in the event of another launch failure, Heydon said. Charles Bigot, the Arianespace chairman, said from Kourou that the consortium will have enough Ariane IVs to maintain its launch rate of 17.5 satellites a year through 1998, and could continue beyond that with another Ariane IV order. That decision is at least a year in the future, and will depend on the outcome of the inquiry board investigation and future Ariane V developments, he said. Copyright 1996 The McGraw-Hill Companies, Inc. -- T.E.D. | Work - mailto:dennison@escmail.orl.mmc.com | | Home - mailto:dennison@iag.net | | URL - http://www.iag.net/~dennison | ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: ARIANE-5 Failure 1996-06-06 0:00 ARIANE-5 Failure John McCabe 1996-06-07 0:00 ` Tronche Ch. le pitre 1996-06-07 0:00 ` Theodore E. Dennison @ 1996-06-10 0:00 ` William Clodius 2 siblings, 0 replies; 47+ messages in thread From: William Clodius @ 1996-06-10 0:00 UTC (permalink / raw) Here's a posting of a posting that I consider more authorative. ----------------------- Begin Included Message ------------------------- From: turner@lanl.gov (John A. Turner) Date: 28 Feb 1995 23:31:39 GMT Organization: Los Alamos National Laboratory In article <1995Feb27.143252.2189@driftwood.cray.com> jjd@cray.com (Jeff Drummond) writes: > The oft-repeated myth of the Venus probe lost due to a missing Fortran > comma been debunked in alt.folklore.computers and elsewhere. Here's something Dan Pop posted back in September (yeah, I'm an e-mail packrat). I hope he won't mind me re-posting it (maybe it'll save him the trouble)... ----------------------- Begin Included Message ------------------------- Newsgroups: comp.lang.fortran From: danpop@cernapo.cern.ch (Dan Pop) Subject: Re: Urban myth? Organization: CERN European Lab for Particle Physics Date: Mon, 19 Sep 1994 10:56:50 GMT In <kemidb.779968115@aau> kemidb@aau.dk (Dieter Britz) writes: >Over the years, I have several times seen reference to this piece of code: > > DO 10 I = 1.10 > ... >10 CONTINUE > >It is said that this error (which the compiler, of course, interprets as >the assignment statement DO10I=1.10) was made in a space program program, >and led to a rocket crash. Is this factual, or is this an urban myth in >the computer world? >From the alt.folklore.computers FAQ: III.1 - I heard that one of the NASA space probes went off course and had to be destroyed because of a typo in a FORTRAN DO loop. Is there any truth to this rumor? As revealed by past discussion in comp.risks (Risks Digest) as well as alt.folklore.computers and occasionally other newsgroups, this turns out to be a confusion of two separate events. The space probe that the DO-loop story has been wrongly attached to is Mariner I (or 1), which was intended for Venus (not Mars). Several incorrect or partially correct versions of what really happened were posted in comp.risks; the best of these cited a NASA publication called "Far Travelers" by Oran W. Nicks, but still did not have the whole story. Then in issue 8.75 we found out what really happened... | Date: Sat, 27 May 1989 15:34:33 PDT | From: Peter Neumann <neumann@csl.sri.com> | Subject: Mariner I -- no holds BARred | | Paul Ceruzzi has written a truly outstanding book for the new show | that opened two weeks ago at the Smithsonian National Air and Space | Museum. The exhibit and the book are both entitled "Beyond the Limits | -- Flight Enters the Computer Age". Both are superb. Go for it (them). | | Paul has dug into several cases treated previously in RISKS and in | issues of the ACM Software Engineering Notes, and has been able to | resolve several mysteries. In particular he considers the case of | Mariner I, about which various inaccurate stories have been told. | Intended to be the first US spacecraft to visit another planet, it was | destroyed by a range officer on 22 July 1962 when it behaved | erratically four minutes after launch. The alleged missing `hyphen' | was really a missing `bar'. I quote from Paul's book, pp. 202-203: | | # During the launch the Atlas booster rocket was guided with the help | # of two radar systems. One, the Rate System, measured the velocity of | # the rocket as it ascended through the atmosphere. The other, the | # Track System, measured its distance and angle from a tracking | # antenna near the launch site. At the Cape a guidance computer | # processed these signals and sent control signals back to the | # tracking system, which in turn sent signals to the rocket. Its | # primary function was to ensure a proper separation from the Atlas | # booster and ignition of the Agena upper stage, which was to carry | # the Mariner Spacecraft to Venus. | # | # Timing for the two radar systems was separated by a difference of | # forty-three milliseconds. To compensate, the computer was instructed | # to add forty-three milliseconds to the data from the Rate System | # during the launch. This action, which set both systems to the same | # sampling time base, required smoothed, or averaged, track data, | # obtained by an earlier computation, not the raw velocity data | # relayed directly from the track radar. The symbol for this smoothed | # data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n], | # where R stands for the radius, the dot for the first derivative | # (i.e., the velocity), the bar for smoothed data, and n for the | # increment. | # | # The bar was left out of the hand-written guidance equations. [A | # footnote cites interviews with John Norton and General Jack Albert.] | # Then during launch the on-board Rate System hardware failed. That in | # itself should not have jeopardized the mission, as the Track System | # radar was working and could have handled the ascent. But because of | # the missing bar in the guidance equations, the computer was | # processing the track data incorrectly. [Paul's EndNote amplifies: | # The Mariner I failure was thus a {\it combination} of a hardware | # failure and the software bug. The same flawed program had been used | # in several earlier Ranger launches with no ill effects.] The result | # was erroneous information that velocity was fluctuating in an | # erratic and unpredictable manner, for which the computer tried to | # compensate by sending correction signals back to the rocket. In fact | # the rocket was ascending smoothly and needed no such correction. The | # result was {\it genuine} instead of phantom erratic behavior, which | # led the range safety officer to destroy the missile, and with it the | # Mariner spacecraft. Mariner I, its systems functioning normally, | # plunged into the Atlantic. The DO-loop incident did happen at NASA, and at about the same time. As told by Fred Webb in alt.folklore.computers in 1990: | I worked at Nasa during the summer of 1963. The group I was working | in was doing preliminary work on the Mission Control Center computer | systems and programs. My office mate had the job of testing out an | orbit computation program which had been used during the Mercury | flights. Running some test data with known answers through it, he was | getting answers that were close, but not accurate enough. So, he | started looking for numerical problems in the algorithm, checking to | make sure his tests data was really correct, etc. | | After a couple of weeks with no results, he came across a DO | statement, in the form: | DO 10 I=1.10 | This statement was interpreted by the compiler (correctly) as: | DO10I = 1.10 | The programmer had clearly intended: | DO 10 I = 1, 10 | | After changing the `.' to a `,' the program results were correct to | the desired accuracy. Apparently, the program's answers had been | "good enough" for the sub-orbital Mercury flights, so no one suspected | a bug until they tried to get greater accuracy, in anticipation of | later orbital and moon flights. As far as I know, this particular bug | was never blamed for any actual failure of a space flight, but the | other details here seem close enough that I'm sure this incident is the | source of the DO story. Project Mercury's sub-orbital flights were in 1961, and its orbital flights began in 1962. I forwarded the above to comp.risks, slightly abridged, and it appeared there in issue 9.54. The erroneous claim that the DO-loop bug was the bug that killed Mariner I apparently originated with, and certainly was propagated by, the book "Software Reliability: Principles and Practices" by G(lenford) J. Myers (John Wiley & Sons, 1976). I haven't read it myself; I've seen the page numbers 7 and 275 attributed to the assertion. I expect both are right. This book also describes the bug as a "billion-dollar error", which is too large by a factor of about 50. In some earlier postings it was suggested that Myers be located and asked about his sources (the book gives none), but nobody successfully did this; his employer at the time of publication didn't have his current address. My guess is that he simply made an error or more likely accepted someone else's wrong recollection, and didn't feel it necessary to go to original sources to verify what was only an illustrative point anyway. This answer by Mark Brader <msb@sq.com>. Quoted items in it have been reformatted but not abridged. -- Dan Pop CERN, CN Division Email: danpop@cernapo.cern.ch Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland ----------------------- Begin Included Message ------------------------- +---------------------------------------------------------------+ | John A. Turner | | Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 | | Group: X-6 (Radiation Transport) | | Location: TA-3, Bldg. 43, Rm. D263 | | Phone: 505-665-1303 e-mail: turner@lanl.gov | +---------------------------------------------------------------+ ----------------------- Begin Included Message ------------------------- -- William B. Clodius Phone: (505)-665-9370 Los Alamos National Laboratory Email: wclodius@lanl.gov Los Alamos, NM 87545 ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~1996-06-24 0:00 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-06-06 0:00 ARIANE-5 Failure John McCabe 1996-06-07 0:00 ` Tronche Ch. le pitre 1996-06-07 0:00 ` David Weller 1996-06-07 0:00 ` Ken Garlington 1996-06-08 0:00 ` Samuel Mize 1996-06-09 0:00 ` ARIANE-5 Failure (DC-X works) Eugene W.P. Bingue 1996-06-08 0:00 ` Robert Dewar 1996-06-09 0:00 ` Samuel Mize 1996-06-10 0:00 ` ARIANE-5 Failure Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Robert Dewar 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-15 0:00 ` Robert Dewar 1996-06-12 0:00 ` Samuel Mize 1996-06-13 0:00 ` Robert Dewar 1996-06-17 0:00 ` David Zink 1996-06-18 0:00 ` Robert Dewar 1996-06-13 0:00 ` Ken Garlington 1996-06-14 0:00 ` Robert Dewar 1996-06-17 0:00 ` Ken Garlington 1996-06-18 0:00 ` 4GL code in a deliverable (was: ARIANE-5 Failure) Arthur Evans Jr 1996-06-19 0:00 ` Ken Garlington 1996-06-20 0:00 ` Robert Dewar 1996-06-24 0:00 ` Ken Garlington 1996-06-24 0:00 ` Ken Garlington 1996-06-09 0:00 ` ARIANE-5 Failure Dale Stanbrough 1996-06-10 0:00 ` ARIANE-5 Failure (DC-X works) Ken Garlington 1996-06-14 0:00 ` Robert Dewar 1996-06-17 0:00 ` Ken Garlington 1996-06-19 0:00 ` 4THGL code Warren Taylor 1996-06-12 0:00 ` Automatic code generation (was ARIANE-5 Failure (DC-X works)) Steve Vestal 1996-06-07 0:00 ` ARIANE-5 Failure Ken Garlington 1996-06-07 0:00 ` Robert Dewar 1996-06-07 0:00 ` John McCabe 1996-06-07 0:00 ` Bert Peers 1996-06-08 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Jim Kingdon 1996-06-09 0:00 ` Robert Dewar 1996-06-10 0:00 ` Keith Thompson 1996-06-10 0:00 ` Dewi Daniels 1996-06-12 0:00 ` Theodore E. Dennison 1996-06-12 0:00 ` Ken Garlington 1996-06-13 0:00 ` Theodore E. Dennison 1996-06-13 0:00 ` Jan Kok 1996-06-10 0:00 ` William Clodius 1996-06-07 0:00 ` Theodore E. Dennison 1996-06-10 0:00 ` William Clodius
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox