Pentagon Report Faults F-35
aviationweek.com
aviationweek.com
http://www.vanityfair.com/politics/2013/09/joint-strike-figh...
Some of the highlights include:
-DoD skimped on requirements and instead relied on the contractor to fill in the gaps. This led to the plane being designed without protection from lightning strikes which means it can't currently fly in bad weather
-The plane was supposed to have 70 percent parts commonality between variants. It is now 25 percent
-The plane couldn't do supersonic flight because Lockheed Martin didn't test the stealth coatings at the higher temperatures generated in supersonic flight
-The DoD let Lockheed Martin skip a lot of real world testing in favor of computer modeling
In short, the marines screwed this plane up for everybody but themselves. If even they are not happy with the result then the F-35 project is an utter flop.
http://www.youtube.com/watch?v=1XkJXSoTTb4
50 years ago plane looks more capable as VTOL than F-35. Modern powerful engines allow to drive the fans from the compressor shaft - as F-35 shows - and that would fix the main geometry issue with jet engine placement in XV-5A where fans were driven from jet exhaust.
View the 'wheel of shame', as it's known in aeronautical engineering circles:
Still, the V-22 was a vastly more successful program than the JSF will be. At the very least the military got an aircraft that can perform missions no other aircraft can, thereby giving the services capabilities they've never had before. I don't think that will be the case for the JSF when it is all said and done.
edit: Made a mistake, Navy doesn't have V-22's yet
Edited to fix a word.
A while ago I read a long and fascinating article tracing this back to Guadalcanal in WWII, when the Marines couldn't get the air support they needed. Apparently this history is firmly cemented in the corps collective memory and is a large part of why they insist on this.
A truly excellent article for everyone interested in fighter jets, military procurement, government contracts, national security, whether the US could win a war with China, or just really good yarns about really stupid decisions.
(I closed my Facebook account a few years ago, so all I know about this is what you said.)
If you've got 50 percent or less of the software capabilities in a system with 8 million lines of code, and it's supposed to be deployed in 18 months you're in deep shit. Yet, the program's backers blithely proclaim they're going to make their dates, ignoring the fact that the program is years overdue and 70% over budget.
Not only has an enormous amount of good money been thrown after bad, the military has staked the future of air power on this one aircraft so no one wants to admit that it should be cancelled.
Obviously Navy, Marines, and Airforce all want different features, and requirement to the chassis renders it extremely frail (they had to cut a lot of weight for VTOL capability).
So considering that, it actually might be good idea to stop completely, fire all top airforce/navy/marine brass involved and restart as 3 separate projects from scratch, albeit using all the technology already developed.
Morale is already super low and it is hard to see bright future for something so overpriced, over budget, over engineered (in a bad way), and over politicized.
Morton Thiokol is a solid rocket company in the northwestern U.S. The Shuttle launched from the southwest U.S. The solid rockets, with tubes of propellant inside, had to be cut into sections to make the long journey. The joints were heavy (very bad for rockets), and a leaky joint destroyed the Challenger.
The horrible Air Force requirements made refurbishing very expensive and slow. Everything had been stripped of so much weight that it was too fragile and needed detailed inspection and repairs for each launch.
Morton Thiokol was crammed into the program to get Shuttle votes from their state's senators. The catch is that the crammin-crap-in process doomed the program. But if Morton Thiokol had threatened to cancel the program unless it was reinvented, they could have come out as a real rocket company supporting a fleet that launched every month. Honestly, the innovations SpaceX is coming out with could and should have been done by the Shuttle program, instead of the idiot business "leaders" chaining themselves to the worst possible ideas
* Linear aerospike engine
* Conformal carbon-composite LH2 tanks
* Integrated metallic TPS
* Subcontractors in 38 states and 122 congressional districts
The shuttle was a similarly foregone conclusion with a lot more money behind it. You're absolutely right that one of SpaceX's primary innovations, thus far, has simply been to not let politics get anywhere near the engineering process.
The SLS, built on Shuttle parts minus the spaceplane, launches first prototype in 2017. To what end, few can say.
If the military goes forward with the JSF, they are going to be stuck with a fundamentally poor platform for at least 20 to 30 years. This thing is wildly over budget, and will be wildy more expensive to operate than projected. This plane is supposed to be the backbone of US air power for decades.
If you scrap this program and start over, maybe it'll take 7-10 years to come up with 3 new aircraft for the 3 different roles. You sacrifice a decade to get something that will be far better for decades.
The military basically did exactly that when the F-111 program got off the rails in basically the same manner. It was supposed to be a fighter bomber for the Air Force and fleet air defense aircraft for the Navy but the Navy version ended up being too heavy and poor performing so they scrapped it, and ended up developing the F-14.
Honestly I would scrap the Marine Corps variant altogether. The USMC never goes where the Navy is not going to be so they could rely on close air support from the Naval variant. Sure a VSTOL aircraft could take off from a field somewhere but that capability simply doesn't provide enough benefit to offset the cost.
They are "pot committed" and can't kill the project. They made it kill proof...
Well, at least it's not also tasked with managing health insurance accounts.
On the F-35 side, there was this huge robot that looked like a flat toolbox. It moved the airframe part from one station to the next. Just amazing. The whole assembly line looks like something out of a movie.
I was told that the F-35 had a lot of C++ code, and that is the reason it was not meeting deadlines. It was an interesting bit of gossip to hear, but I'm not entirely sure how that would come into play. I'm also not sure if C++ has been used before in this type of application. Given how ingrained Ada, C, and Fortran are in the industry.
Fortran doesn't fly; that is, (almost)[1] no real-time code is written in Fortran. It is still used for simulations, but is steadily being replaced my Matlab since the latter integrates better with various engineering workflows.
C is definitely still the winner for the embedded code, but is losing to C++ as time goes on. Java is also making inroads for implementing the interfaces on operator consoles.
[1] I know of at least one program that deployed signal processing algorithms in a semi-operational state in Fortran.
Only very small parts of software can be proven, especially for things like flight control, where the parameter space is huge, and exhaustive search or manual formal proofs are impossible. Not even speaking of the fact that the spec against which one could build a proof is never error-free to begin with.
In my opinion, this last part is the art, figuring out what to do when you tread a new path. A good engineer will find the critical parts, but that relies on as much intuition as process. A really good engineer will find the meta-mistakes in the process.
The decision to "swing it" can be an engineering decision. If I am doing something I did before, and all the parts fit, I can swing it, and forego a tedious process. I have to balance the risk of implementation delays and bugs vs. spending time on simulation and paperwork.
It's also perfectly possible to do everything by the book and still fail, if the process is a bad fit, or you run out of time because you're all caught up in following procedure instead of taking common sense shortcuts.
So either swinging it or doing it by the book can be engineering or idiocy, depending entirely on the situation, and, in retrospect, the outcome.
The JSF software organization uses static analyzers heavily. They are using theorem provers.
"The current software generated too many nuisance warnings and resulted in poor sensor performance. Further work on software had been slowed by testing required to validate earlier fixes, the report said."
"It said Lockheed had delivered F-35 jets with 50 percent or less of the software capabilities required by its production contracts with the Pentagon."
> But how much work the software does is not what makes it remarkable. What makes it remarkable is how well the software works. This software never crashes. It never needs to be re-booted. This software is bug-free. It is perfect, as perfect as human beings have achieved. Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors.
If that 10 billion is accurate (I can believe 10GB of binaries, but 10 billion lines seems too much to me, even including support software), maybe the project is too ambitious.
For example, the onboarding meeting I had with their HR folks was roughly 90% about retirement benefits and health care plans, neither of which I was eligible for as a temporary part-timer. This still cost NIH two hours of my time even so. And it took them weeks to get me the right codes so I could actually log my hours in their system the way I was supposed to, on a project that was supposed to last two months in total.
And in all of this, they provided not one shred of added value to the project that I could detect. Were it not for whatever bureaucratic rule required them as a middleman, I could have conceivably raised my rates 50%, cost the actual customer less, and been more productive without them.
Comparing feature bullet points is a pointless exercise. Neither of us being an actual expert on this stuff (I assume), it's most reasonable to take the pros at their word. Doubly so when they're being critical rather than cheer-leading.