121–129 of 129 posts
Earlier quoted context omitted.
> I thought that 'lowest bidder wins' was an American phenomenon? Why should it be?
Because Europe cares about people not money, like in Greece.
Earlier quoted context omitted.
I wrote (non-critical) software for the A400M. I don't think that standards like DO-178B necessarily lead to higher quality code; my experience was that 80-90% of time was spent doing documentation, testing, and in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software...
in general, trying to prove that the software was going to work right, leaving the engineers with very little time to write the actual software... Sure sounds like the way it should be to me. Maybe it needs to be made easier to prove your software is correct, but to me it seems like for systems like airplanes, code that cannot be proven correct is worthless. Considering most programmers are said to produce 6 lines of…
Earlier quoted context omitted.
Planes with four engines are certainly not designed to fly with 3 of 4 engines out...
Indeed, planes are not designed to be flown in that configuration normally, but they are certainly capable of single-engine flight in emergency situations (where the alternative would be "flying like a ton of bricks"). Exhibit A: http://en.wikipedia.org/wiki/British_Airways_Flight_9
Earlier quoted context omitted.
Indeed, planes are not designed to be flown in that configuration normally, but they are certainly capable of single-engine flight in emergency situations (where the alternative would be "flying like a ton of bricks"). Exhibit A: http://en.wikipedia.org/wiki/British_Airways_Flight_9
No, actually "capable of flying" means capable of performing all flight maneuvers required for safe flight and landing, including takeoff, go-around and approach/landing. BA Flight 9 failed all four engines, normally not survivable - but managed to restart all four engines by windmilling. So they recovered in time for landing.
I am not surprised at all. There are a lot of contractors involved in the development of the software for the A400M, and they are basically competing for price and employing undergraduates making below €18K/year, which they replace every few months due to burnouts and bad working conditions. Projects get continuously delayed, and key people barely stay more than a couple of years.
I am not surprised at all. There are a lot of contractors involved in the development of the software for the A400M, and they are basically competing for price and employing undergraduates making below €18K/year, which they replace every few months due to burnouts and bad working conditions. Projects get continuously delayed, and key people barely stay more than a couple of years.
Earlier quoted context omitted.
Indeed, planes are not designed to be flown in that configuration normally, but they are certainly capable of single-engine flight in emergency situations (where the alternative would be "flying like a ton of bricks"). Exhibit A: http://en.wikipedia.org/wiki/British_Airways_Flight_9
No, actually "capable of flying" means capable of performing all flight maneuvers required for safe flight and landing, including takeoff, go-around and approach/landing. BA Flight 9 failed all four engines, normally not survivable - but managed to restart all four engines by windmilling. So they recovered in time for landing.
Earlier quoted context omitted.
The target catastrophic failure rate there is 1 in a billion hours, which doesn't seem all that high to me... there are over 100000 flights a day[1], and the average length of one is well over an hour, so in one day all the aircraft in the world have accumulated a total of over 2.4 million hours in operation. If each flight was only an hour long, that's 417 days to 1 billion total hours, and if the failure rate reall…
How does 100k flights a day equal 2.4 millions hours of operation if each flight was on average 1 hour?
Earlier quoted context omitted.
I also work in aerospace software. Following DO178 certainly does not guarantee that there will be no software bugs. The point of DO178 is to follow a process that will _minimize_ the number of bugs by having adequate peer review processes throughout the requirement definition, coding, integration phases, in addition to the testing you mention above. Testing DO178 only tests that the code follows the requirements. If…
That is certainly one source for error. There are many. Another is that testing does not give you exhaustive coverage of the state space just because each branch of the code is visited. The standard does mention "formal verification/methods/proof" but to my knowledge it's rarely been used extensively.