RE: DC-10

From: owner-skunk-works-digest@netwrx1.com (skunk-works-digest) To: skunk-works-digest@netwrx1.com Subject: skunk-works-digest V9 #76 Reply-To: skunk-works@netwrx1.com Sender: owner-skunk-works-digest@netwrx1.com Errors-To: owner-skunk-works-digest@netwrx1.com Precedence: bulk skunk-works-digest Monday, September 25 2000 Volume 09 : Number 076 Index of this digest by subject: *************************************************** RE: DC-10 RE: DC-10 YC-14 and YC-15 C-14 Development Schedules RE: Development Schedules RE: Development Schedules RE: Development Schedules RE: Development Schedules *************************************************** ---------------------------------------------------------------------- Date: Mon, 25 Sep 2000 13:12:58 -0400 From: "Weigold, Greg" Subject: RE: DC-10 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C02714.4A42EAA4 Content-Type: text/plain; charset="iso-8859-1" That's what the picture looks like, but I wasn't familiar with a version of the C-17 with top-mounted powerplants Thanks Greg - -----Original Message----- From: Erik Hoel [mailto:ehoel@esri.com] Sent: Monday, September 25, 2000 01:02 PM To: 'skunk-works@netwrx1.com' Subject: RE: DC-10 The C-14 was an early MD prototype/design study(?) of the C-17. As I recall, the turbofans (2?) were mounted on the top of the wing so as to provide more lift when the flaps were extended. Erik - -----Original Message----- From: Weigold, Greg [mailto:GregWeigold@mynd.com] Sent: Monday, September 25, 2000 9:55 AM To: 'skunk-works@netwrx1.com' Subject: RE: DC-10 Interesting stuff... Anybody know what this is? YC-14 72-1874 I don't remember hearing about a C-14...... Greg W - -----Original Message----- From: David Lednicer [ mailto:dave@amiwest.com ] Sent: Monday, September 25, 2000 12:44 PM To: Skunk Works Group Subject: DC-10 Over the weekend, I did some research on the Raytheon DC-10, based upon some info someone pointed me to. The aircraft arrived at Goodyear, AZ in October 16, 1999 ( http://www.azstarnet.com/~chisox/gyr-tot.htm ) and then was delivered to the AMARC storage area at Davis-Monthan on August 22 of this year ( http://www.codacomsystems.com/AMARC/previous/frisep012000.htm ). You can find pictures of it at: http://www.aeropacificimages.com/scan337.jpg http://home.interlink.or.jp/~shinora/fanclub/d10/d10lhe_d01.htm http://corsair.flugmodellbau.de/files/sonstige/02550.JPG A also stumbled upon info regarding the aircraft's pilot at: http://www2.olsusa.com/Users/Mkaye/builders2.html - ------_=_NextPart_001_01C02714.4A42EAA4 Content-Type: text/html; charset="iso-8859-1" RE: DC-10

That's what the picture looks like, but I wasn't familiar with a version of the C-17 with top-mounted powerplants

Thanks

Greg

-----Original Message-----
From: Erik Hoel [mailto:ehoel@esri.com]
Sent: Monday, September 25, 2000 01:02 PM
To: 'skunk-works@netwrx1.com'
Subject: RE: DC-10

The C-14 was an early MD prototype/design study(?) of the C-17. As I recall, the turbofans (2?) were mounted on the top of the wing so as to provide more lift when the flaps were extended.

Erik

-----Original Message-----
From: Weigold, Greg [mailto:GregWeigold@mynd.com]
Sent: Monday, September 25, 2000 9:55 AM
To: 'skunk-works@netwrx1.com'
Subject: RE: DC-10

Interesting stuff...

Anybody know what this is? YC-14 72-1874

I don't remember hearing about a C-14......

Greg W

-----Original Message-----
From: David Lednicer [mailto:dave@amiwest.com]
Sent: Monday, September 25, 2000 12:44 PM
To: Skunk Works Group
Subject: DC-10

Over the weekend, I did some research on the Raytheon DC-10, based upon
some info someone pointed me to. The aircraft arrived at Goodyear, AZ in
October 16, 1999 (http://www.azstarnet.com/~chisox/gyr-tot.htm) and then
was delivered to the AMARC storage area at Davis-Monthan on August 22 of
this year (http://www.codacomsystems.com/AMARC/previous/frisep012000.htm).
You can find pictures of it at:
http://www.aeropacificimages.com/scan337.jpg
http://home.interlink.or.jp/~shinora/fanclub/d10/d10lhe_d01.htm
http://corsair.flugmodellbau.de/files/sonstige/02550.JPG

A also stumbled upon info regarding the aircraft's pilot at:
http://www2.olsusa.com/Users/Mkaye/builders2.html

- ------_=_NextPart_001_01C02714.4A42EAA4-- ------------------------------ Date: Mon, 25 Sep 2000 12:22:21 -0500 From: "Peake, Bill" Subject: RE: DC-10 Actually, I believe that the YC-14 was a Boeing design and the YC-15 was the McDonnell Douglas design. There were two of each aircraft built for a fly off, which the McDonnell Douglas design won. It later became the C-17. BILL PEAKE > -----Original Message----- > From: Erik Hoel [SMTP:ehoel@esri.com] > Sent: Monday, September 25, 2000 12:02 PM > To: 'skunk-works@netwrx1.com' > Subject: RE: DC-10 > > The C-14 was an early MD prototype/design study(?) of the C-17. As I > recall, the turbofans (2?) were mounted on the top of the wing so as to > provide more lift when the flaps were extended. > > Erik > > > -----Original Message----- > From: Weigold, Greg [mailto:GregWeigold@mynd.com] > Sent: Monday, September 25, 2000 9:55 AM > To: 'skunk-works@netwrx1.com' > Subject: RE: DC-10 > > > > Interesting stuff... > > Anybody know what this is? YC-14 72-1874 > > I don't remember hearing about a C-14...... > > Greg W > > -----Original Message----- > From: David Lednicer [ ] > Sent: Monday, September 25, 2000 12:44 PM > To: Skunk Works Group > Subject: DC-10 > > > > Over the weekend, I did some research on the Raytheon DC-10, based > upon > some info someone pointed me to. The aircraft arrived at Goodyear, > AZ in > October 16, 1999 ( ) > and then > was delivered to the AMARC storage area at Davis-Monthan on August > 22 of > this year ( > ). > You can find pictures of it at: > > > > > A also stumbled upon info regarding the aircraft's pilot at: > > > > > ------------------------------ Date: Mon, 25 Sep 2000 13:48:05 -0400 From: Jim Rotramel Subject: YC-14 and YC-15 The Boeing YC-14 and McDD YC-15 were technology demonstrator transports of roughly C-130 proportions that flew during the late 1970s. The Boeing design had the engines mounted on top of the wing (a feature later copied by a Soviet transport that was produced) while the YC-15 bore a strong family resemblance to today's C-17A. Jim ------------------------------ Date: Mon, 25 Sep 2000 11:09:26 -0700 From: David Lednicer Subject: C-14 The YC-14 was the Boeing contender in the AMST competition of the early 1970s to replace the C-130. The McDonnell Douglas contender was the YC-15. The YC-14 was based upon USB (Upper Surface Blowing) and used two GE CF6s exhausting over the wing to achieve very high lift coefficients. The YC-15 had blown flaps and had four P&W JT8Ds. Both aircraft worked well, but the program was too expensive and the DoD shelved it. A lot of the YC-15 design features ended up in the C-17. There is a good AIAA case study on the YC-14 available, written by Jack Wimpress. ------------------------------ Date: Mon, 25 Sep 2000 11:12:51 -0700 From: David Lednicer Subject: Development Schedules The difference between the coding you talk about Sam and the ATF/F-22 and JSF coding is massive. The military systems involve upwards of 20 million lines of code. This code must have zero bugs and must function correctly - - always. The code involves flight controls, sensor data fusion, voice recognition, etc. Hence, it is very complex and interwoven. The zero bug certification alone takes a long time. ------------------------------ Date: Mon, 25 Sep 2000 14:35:33 -0400 From: "Weigold, Greg" Subject: RE: Development Schedules This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C0271F.D5A6CAE2 Content-Type: text/plain; charset="iso-8859-1" I work for a software company, and I can tell you that making 20 million lines of code 100% bug free is a LONG arduous task.... We have over 200 programmers who are working on systems that size, and we have NEVER achieved 100% bug free!! Of course, our stuff doesn't have AMRAAM attached to one end, and doesn't usually kill anyone.... at least not intentionally!! Greg W - -----Original Message----- From: David Lednicer [mailto:dave@amiwest.com] Sent: Monday, September 25, 2000 02:13 PM To: Skunk Works Group Subject: Development Schedules The difference between the coding you talk about Sam and the ATF/F-22 and JSF coding is massive. The military systems involve upwards of 20 million lines of code. This code must have zero bugs and must function correctly - - always. The code involves flight controls, sensor data fusion, voice recognition, etc. Hence, it is very complex and interwoven. The zero bug certification alone takes a long time. - ------_=_NextPart_001_01C0271F.D5A6CAE2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Development Schedules

I work for a software company, and I can tell you = that making 20 million lines of code 100% bug free is a LONG arduous = task.... We have over 200 programmers who are working on systems = that size, and we have NEVER achieved 100% bug free!!

Of course, our stuff doesn't have AMRAAM attached to = one end, and doesn't usually kill anyone.... at least not = intentionally!! <grin>

Greg W

-----Original Message-----
From: David Lednicer [mailto:dave@amiwest.com]
Sent: Monday, September 25, 2000 02:13 PM
To: Skunk Works Group
Subject: Development Schedules

The difference between the coding you talk about Sam = and the ATF/F-22 and
JSF coding is massive. The military systems = involve upwards of 20 million
lines of code. This code must have zero bugs = and must function correctly
- always. The code involves flight controls, = sensor data fusion, voice
recognition, etc. Hence, it is very complex = and interwoven. The zero bug
certification alone takes a long time.

- ------_=_NextPart_001_01C0271F.D5A6CAE2-- ------------------------------ Date: Mon, 25 Sep 2000 12:39:51 -0700 From: Erik Hoel Subject: RE: Development Schedules David Lednicer [mailto:dave@amiwest.com] wrote: > The difference between the coding you talk about Sam and the ATF/F-22 and > JSF coding is massive. The military systems involve upwards of 20 million > lines of code. This code must have zero bugs and must function correctly > - always. The code involves flight controls, sensor data fusion, voice > recognition, etc. Hence, it is very complex and interwoven. The zero bug > certification alone takes a long time. (I am not meaning to attack David personally in the following - he does raise some interesting issues) From my perspective, this is simply a metaphysical impossibility. Software always has bugs, as does the hardware. In order to prove that a simple ten line while statement is correct, you will spend quite a bit of time playing with fun stuff such as weakest precondition predicates and denotational semantics. I have never seen any real-world program proven correct; it is not hard though to find those wonderful ten line while loop proofs in the standard academic literature (e.g., David Gries, The Science of Programming). The same basically holds true with hardware. Mil-spec chips are tested longer and harder than standard commercial variants (heat, shock, vibration, number of test vectors, etc.), but they too will experience bugs (where exactly did that 0.2 micro spec of dust land anyway ...). It is effectively impossible to test a chip 100%. You can of course achieve a certain level of confidence, but 100% is simply not achievable (unless of course you have a nearly infinite amount of time). This was my experience working for two semiconductor manufacturers. Putting software (either buggy or unbuggy [if any such beast has ever existed]) on top of buggy hardware is makes it challenging to achieve 100% correctness... I have never worked on military systems - perhaps there are some very exotic tools that are unknown to academia and the research community at large that automate the process of proving program correctness (though I would bet my house against it). When I worked in semiconductors, we merely tested the chips significantly more (an order of magnitude or more) that their commercial cousins. What does "zero bug certification" really mean? Erik ------------------------------ Date: Mon, 25 Sep 2000 16:55:16 -0400 (EDT) From: Sam Kaltsidis Subject: RE: Development Schedules > David Lednicer [mailto:dave@amiwest.com] wrote: > > > The difference between the coding you talk about Sam and the ATF/F-22 and > > JSF coding is massive. The military systems involve upwards of 20 million > > lines of code. This code must have zero bugs and must function correctly > > - always. The code involves flight controls, sensor data fusion, voice > > recognition, etc. Hence, it is very complex and interwoven. The zero bug > > certification alone takes a long time. > > (I am not meaning to attack David personally in the following - he does > raise some interesting issues) > > >From my perspective, this is simply a metaphysical impossibility. > > Software always has bugs, as does the hardware. > > In order to prove that a simple ten line while statement is correct, you > will spend quite a bit of time playing with fun stuff such as weakest > precondition predicates and denotational semantics. I have never seen any > real-world program proven correct; it is not hard though to find those > wonderful ten line while loop proofs in the standard academic literature > (e.g., David Gries, The Science of Programming). > > The same basically holds true with hardware. Mil-spec chips are tested > longer and harder than standard commercial variants (heat, shock, vibration, > number of test vectors, etc.), but they too will experience bugs (where > exactly did that 0.2 micro spec of dust land anyway ...). It is effectively > impossible to test a chip 100%. You can of course achieve a certain level of > confidence, but 100% is simply not achievable (unless of course you have a > nearly infinite amount of time). This was my experience working for two > semiconductor manufacturers. > > Putting software (either buggy or unbuggy [if any such beast has ever > existed]) on top of buggy hardware is makes it challenging to achieve 100% > correctness... > > I have never worked on military systems - perhaps there are some very exotic > tools that are unknown to academia and the research community at large that > automate the process of proving program correctness (though I would bet my > house against it). When I worked in semiconductors, we merely tested the > chips significantly more (an order of magnitude or more) that their > commercial cousins. > > What does "zero bug certification" really mean? > > Erik I agree with Erik, I do not believe it is possible to actually prove the a very complex system will function correctly 100% of the time. Sure you may be able to come up with a mathematical proof that it will work correctly, but in real life it doesn't work that way. Here's an example: Suppose you have standard 168pin 72bit* ECC DIMMS with two bit detect and single bit correct capabilities, if three or more bits flip for whatever reason -- that will go undetected and your program will continue to run with corrupted data which could result in unpredictable behavior or a crash. This is where a mathematical proof would fail miserably. * 72bit=64bits data + 8bits ECC Here's another example: buff=(char*)malloc(sizeof(char)*((1024*1024)*MEG_REQUESTED)); this line my look innocent at first glance but what happens if the malloc fails? Many programmers wouldn't bother to check the return value of the malloc() to see if it worked and thus would write into buff anyway probably resulting in a segmentation fault and a core dump. However, it is possible to write software that will fail gracefully, in a way that will not be life-threatening. This is where software fault detection and recovery methods come into play. As always standard disclaimers apply and please do punch me in the head if I've stuck my foot in my mouth. Sam CIO - Dark Entertainment LLC http://www.darkent.com ------------------------------ Date: Mon, 25 Sep 2000 17:09:55 -0400 From: "Weigold, Greg" Subject: RE: Development Schedules This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. - ------_=_NextPart_001_01C02735.6319DF26 Content-Type: text/plain; charset="iso-8859-1" I agree with both of you..... I can write hundreds of lines of code, test the heck out of it, and put it into QA and sure as heck, they'll make it fail in someway I never thought humanly possible.... And after that's fixed, sell it to a customer. Guaranteed, they'll break it in 3 minutes!! The closest thing to 100% bug free code I've ever seen was the short program written in Assembler, some of you might recognize the infamous BR 14 And I've seen THAT fail when register 14 isn't loaded correctly! Its not the program's fault, but who knows what's really at that memory location? You have to depend on something someone else wrote and you know what that means..... Greg W - -----Original Message----- From: Sam Kaltsidis [mailto:skaltsid@mcs.kent.edu] Sent: Monday, September 25, 2000 04:55 PM To: skunk-works@netwrx1.com Subject: RE: Development Schedules > David Lednicer [mailto:dave@amiwest.com] wrote: > > > The difference between the coding you talk about Sam and the ATF/F-22 and > > JSF coding is massive. The military systems involve upwards of 20 million > > lines of code. This code must have zero bugs and must function correctly > > - always. The code involves flight controls, sensor data fusion, voice > > recognition, etc. Hence, it is very complex and interwoven. The zero bug > > certification alone takes a long time. > > (I am not meaning to attack David personally in the following - he does > raise some interesting issues) > > >From my perspective, this is simply a metaphysical impossibility. > > Software always has bugs, as does the hardware. > > In order to prove that a simple ten line while statement is correct, you > will spend quite a bit of time playing with fun stuff such as weakest > precondition predicates and denotational semantics. I have never seen any > real-world program proven correct; it is not hard though to find those > wonderful ten line while loop proofs in the standard academic literature > (e.g., David Gries, The Science of Programming). > > The same basically holds true with hardware. Mil-spec chips are tested > longer and harder than standard commercial variants (heat, shock, vibration, > number of test vectors, etc.), but they too will experience bugs (where > exactly did that 0.2 micro spec of dust land anyway ...). It is effectively > impossible to test a chip 100%. You can of course achieve a certain level of > confidence, but 100% is simply not achievable (unless of course you have a > nearly infinite amount of time). This was my experience working for two > semiconductor manufacturers. > > Putting software (either buggy or unbuggy [if any such beast has ever > existed]) on top of buggy hardware is makes it challenging to achieve 100% > correctness... > > I have never worked on military systems - perhaps there are some very exotic > tools that are unknown to academia and the research community at large that > automate the process of proving program correctness (though I would bet my > house against it). When I worked in semiconductors, we merely tested the > chips significantly more (an order of magnitude or more) that their > commercial cousins. > > What does "zero bug certification" really mean? > > Erik I agree with Erik, I do not believe it is possible to actually prove the a very complex system will function correctly 100% of the time. Sure you may be able to come up with a mathematical proof that it will work correctly, but in real life it doesn't work that way. Here's an example: Suppose you have standard 168pin 72bit* ECC DIMMS with two bit detect and single bit correct capabilities, if three or more bits flip for whatever reason -- that will go undetected and your program will continue to run with corrupted data which could result in unpredictable behavior or a crash. This is where a mathematical proof would fail miserably. * 72bit=64bits data + 8bits ECC Here's another example: buff=(char*)malloc(sizeof(char)*((1024*1024)*MEG_REQUESTED)); this line my look innocent at first glance but what happens if the malloc fails? Many programmers wouldn't bother to check the return value of the malloc() to see if it worked and thus would write into buff anyway probably resulting in a segmentation fault and a core dump. However, it is possible to write software that will fail gracefully, in a way that will not be life-threatening. This is where software fault detection and recovery methods come into play. As always standard disclaimers apply and please do punch me in the head if I've stuck my foot in my mouth. Sam CIO - Dark Entertainment LLC http://www.darkent.com - ------_=_NextPart_001_01C02735.6319DF26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Development Schedules

I agree with both of you..... I can = write hundreds of lines of code, test the heck out of it, and put it = into QA and sure as heck, they'll make it fail in someway I never = thought humanly possible.... And after that's fixed, sell = it to a customer. Guaranteed, they'll break it in 3 = minutes!!

The closest thing to 100% bug free code I've ever = seen was the short program written in Assembler, some of you might = recognize the infamous

= BR 14

And I've seen THAT fail when register 14 isn't loaded = correctly! Its not the program's fault, but who knows what's = really at that memory location? You have to depend on something = someone else wrote and you know what that means.....

Greg W

-----Original Message-----
From: Sam Kaltsidis [mailto:skaltsid@mcs.kent.edu]<= /FONT>
Sent: Monday, September 25, 2000 04:55 PM
To: skunk-works@netwrx1.com
Subject: RE: Development Schedules

> David Lednicer [mailto:dave@amiwest.com] = wrote:
>
> > The difference between the coding you talk = about Sam and the ATF/F-22 and
> > JSF coding is massive. The military = systems involve upwards of 20 million
> > lines of code. This code must have = zero bugs and must function correctly
> > - always. The code involves flight = controls, sensor data fusion, voice
> > recognition, etc. Hence, it is very = complex and interwoven. The zero bug
> > certification alone takes a long = time.
>
> (I am not meaning to attack David personally in = the following - he does
> raise some interesting issues)
>
> >From my perspective, this is simply a = metaphysical impossibility.
>
> Software always has bugs, as does the = hardware.
>
> In order to prove that a simple ten line while = statement is correct, you
> will spend quite a bit of time playing with fun = stuff such as weakest
> precondition predicates and denotational = semantics. I have never seen any
> real-world program proven correct; it is not = hard though to find those
> wonderful ten line while loop proofs in the = standard academic literature
> (e.g., David Gries, The Science of = Programming).
>
> The same basically holds true with hardware. = Mil-spec chips are tested
> longer and harder than standard commercial = variants (heat, shock, vibration,
> number of test vectors, etc.), but they too = will experience bugs (where
> exactly did that 0.2 micro spec of dust land = anyway ...). It is effectively
> impossible to test a chip 100%. You can of = course achieve a certain level of
> confidence, but 100% is simply not achievable = (unless of course you have a
> nearly infinite amount of time). This was my = experience working for two
> semiconductor manufacturers.
>
> Putting software (either buggy or unbuggy [if = any such beast has ever
> existed]) on top of buggy hardware is makes it = challenging to achieve 100%
> correctness...
>
> I have never worked on military systems - = perhaps there are some very exotic
> tools that are unknown to academia and the = research community at large that
> automate the process of proving program = correctness (though I would bet my
> house against it). When I worked in = semiconductors, we merely tested the
> chips significantly more (an order of magnitude = or more) that their
> commercial cousins.
>
> What does "zero bug certification" = really mean?
>
> Erik

I agree with Erik, I do not believe it is possible to = actually prove the a
very complex system will function correctly 100% of = the time. Sure you may be
able to come up with a mathematical proof that it = will work correctly, but in
real life it doesn't work that way.

Here's an example:

Suppose you have standard 168pin 72bit* ECC DIMMS = with two bit detect and single
bit correct capabilities, if three or more bits flip = for whatever reason -- that
will go undetected and your program will continue to = run with corrupted data
which could result in unpredictable behavior or a = crash. This is where a
mathematical proof would fail miserably.

* 72bit=3D64bits data + 8bits ECC

Here's another example:

buff=3D(char*)malloc(sizeof(char)*((1024*1024)*MEG_REQUESTED));=

this line my look innocent at first glance but what = happens if the malloc fails?

Many programmers wouldn't bother to check the return = value of the malloc() to
see if it worked and thus would write into buff = anyway probably resulting in a
segmentation fault and a core dump.

However, it is possible to write software that will = fail gracefully, in a way
that will not be life-threatening. This is where = software fault detection and
recovery methods come into play.

As always standard disclaimers apply and please do = punch me in the head if I've
stuck my foot in my mouth.

Sam

CIO - Dark Entertainment LLC
http://www.darkent.com

- ------_=_NextPart_001_01C02735.6319DF26-- ------------------------------ End of skunk-works-digest V9 #76 ******************************** To subscribe to skunk-works-digest, send the command: subscribe in the body of a message to "majordomo@netwrx1.com". If you want to subscribe something other than the account the mail is coming from, such as a local redistribution list, then append that address to the "subscribe" command; for example, to subscribe "local-skunk-works": subscribe local-skunk-works@your.domain.net To unsubscribe, send mail to the same address, with the command: unsubscribe in the body. Administrative requests, problems, and other non-list mail can be sent to georgek@netwrx1.com. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace all instances of "skunk-works-digest" in the commands above with "skunk-works". Back issues are available for viewing by a www interface located at: http://www.netwrx1.com/skunk-works/ If you have any questions or problems please contact me at: georgek@netwrx1.com Thanks, George R. Kasica Listowner