* Pilots, maintainers, and administrators at three of the five sites we visited are concerned about ALIS’s ability to deploy and function in forward locations. For example, users are concerned about the large server size and connectivity requirements, and whether the system’s infrastructure can maintain power and withstand a high-temperature environment.
* ALIS users at three of the five sites we visited are concerned that a failure in the system’s current infrastructure could degrade the system and ground the fleet. Currently, ALIS information, including data from all U.S. F-35 sites, flows from the Standard Operating Units (SOU) to a single national Central Point of Entry, and then to the lone Autonomic Logistics Operating Unit (ALOU).26 This data flow process has no back up system for continuity of operations if either of these servers were to fail.
* Maintainers and pilots at three of the five sites we visited were concerned that ALIS does not have much interoperability with legacy aircraft systems... The ability to share information between ALIS and these legacy systems is vital due to the way the services operate.
* Maintainers at four of the five sites we visited told us that the current Action Request (AR) process does not allow for the effective reporting and resolution of F-35 aircraft and ALIS issues.
* ALIS users at all five sites we visited are concerned with data accuracy issues within the system, including missing or inaccurate data and inaccessibility of raw data within ALIS.
One other highlight from the report: the total lifetime cost of the program is now estimated at 1.3 trillion dollars, or $1300000000000 if you prefer longhand (up from the 1 trillion dollar estimate of a few years ago). Other things we could've done with that money besides spending it on this useless garbage heap of a plane are left to the reader's imagination.
I've seen numbers floating at 70 billion/year for that. So that would be 18.5 years.
I've seen estimations of about 1.7 trillion for the wars since 9/11. That'd be another 24 years.
Peter Dale Scott wrote a book about something he calls "The Deep State" which at least, to me helps explain how seemingly regardless of who gets elected, such unpopular expensive programs continue without elected officials people having any discussion of legislation to stop it.
Have you ever noticed that whenever government gives a bunch of money to higher education to operate, the cost to operate those universities goes up to match whatever extra was given?
That's just not true. Higher education costs have held steady for about 30 years.
What has increased is the share of that cost that is being fronted by the student, instead of the government. You want to be mad, be mad. But at least point it in the right direction.
For example - at the 'state funded' institution I was previously employed by, only 11% of our annual funding came from the state. Compare that to the 1970's, when around 60% came from the same source.
The cost of tuition didn't increase (outside of annual inflation adjustments) overall. The cost to the student increased because the state cut back so hard on their payments. Meanwhile, students demand the same, or better services every year. You can have cheap, you can have good, but you can't have both.
The fact that people going to college in the 1970's were able to pay for college on part-time summer jobs wasn't because it was miraculously cheap. It was heavily subsidized.
The government has been dramatically scaling back direct funding of higher education which has to then be made up with higher tuition. Often times, yes, the tuition is then paid for with government-backed loans but the cost-per-student in most areas hasn't budged in 30 years.
I'd like to have meaningful public discussion befitting of the size of these financial commitments.
For instance, there's occasional debate about defunding public broadcasting, which costs 0.013% of F35 + wars. Planned Parenthood is 0.018% of this. Even the often hotly contested NASA is 0.62% of this.
A few years ago, congress was in heated budget debates - trying to knock off PBS to save a buck - but a plane that cost 48,743 times that was never brought up for discussion.
Even if you span these budgets over the 20 years of the F35 program, something like planned parenthood cost 0.4% as much.
If we can find the time to talk about X as a huge waste of tax payer dollars and have legislation to defund it, surely we can find time to talk about something that costs 25,000% more than X.
However, other than an occasional news article and grumble of discontent, nothing actually happens. It moves forward unabated. That's a problem.
DoD projects are modern Public Works projects since they tend to employ people outside big cities in manufacturing jobs that aren't supposed to be outsourced. The instant you try to criticize DoD spending as media or a politician, you are branded as anti-American and you're pushed to the fringes.
Manufacturing facilities in the US employ only a few engineers compared to forklift operators, truck drivers, machinists on an assembly line, and construction workers. Most people in the US cannot be employed in high demand fields that require more education than just a certificate and some hands-on training for a couple months under an apprenticeship kind of system.
Secondly, teaching jobs in the US are extremely hard to come by and have such poor pay that most people in manufacturing would do better in the same communities by looking for factory work.
As it stands, most of the "brilliant" people that are motivated enough simply leave these areas for bigger metro areas and the typically rural communities that make up a very large portion of the US's population and area suffer brain drain. Over generations, this flight becomes culturalized resentment for those trying to better themselves and there is strong pressure against people from leaving. Hence, one of the strongest values among rural people here is "nobody is better than anyone else" and any hint whatsoever of arrogance is extremely chastized. The irony that this is surprisingly close to what liberals fight for in the US politically never seems to register (much of politics in this country is really strange but primarily racially divided or based purely upon economic standing at this point rather than upon actual political views - most black voters are actually conservative and most poor rural whites would vote Democrat if gun control was relaxed, for example).
Anti-intellectualism is very strong in the US compared to most countries in the world and needs to be examined much more closely than other factors IMO.
These types of debates are going for few decades already.
1,3trln is joint air-force budget for next 80 years (since F-35 is intended to cover 90% of all air-force/navy/marines air tasks), includes not only 2500 highly sophisticated vehicles them-self, but maintenance, and probably training and weapons, and covers 50% of national security problems in modern world.
I think 1.3trln is moderate price for that.
That's enough money to buy every American citizen 3-4 ponies (if you ignore the effect on the pony market buying hundreds of millions of ponies would have).
The only people who prefer longhand are those who want people to evaluate the number without context and just see a big number. $130000000000 is just a big number to many people, regardless of how many zeros are in it
The only people who prefer shorthand are those who want people to evaluate the number without context and just see a small number. $1.3tn is just a small number to many people, regardless of the unit which comes after it.
> ALIS does not have redundant infrastructure: ALIS’s current design results in all F-35 data produced across the U.S. fleet to be routed to a Central Point of Entry and then to ALIS’s main operating unit with no backup system or redundancy. If either of these fail, it could take the entire F -35 fleet offline.
That sounds like a movie plot [Independence Day] (or Battlestar Galactica)!
So, the enemy jams comms or shoots down satellites, and a F-35 squadron deployed to a base on the other side of the world can't do maintenance? An aircraft carrier is attacked and its antennas are destroyed, and they can't do maintenance? The enemy breaks into or takes offline the Central Point of Entry over the Internet (oh, but it's airgapped, of course...), and the entire F-35 fleet around the world can't do maintenance? (Or can't do it at the level required to maintain combat readiness.)
If I was paranoid I'd wonder if procurement and architecture had been taken over by hostile agents.
Short of putting a remotely controlled logic bomb and/or actual explosive device on every plane, it's hard to imagine how the F-35 could possibly have been made more vulnerable and less fit for purpose.
> This makes it sound as if ALIS does maintenance. ALIS does not do the maintenance. Human beings still do the maintenance.
Well, obviously, ALIS is not a robot with mechanical arms that do the physical work (although with its name, it wouldn't be surprising if some people expected "Alice" to do just that; and the personification is creepily reminiscent of 2001: A Space Odyssey).
But from what I've read in these articles and part of that GAO report, it sounds like ALIS is part of the designed maintenance protocols. For example, Action Requests are entered into ALIS and uploaded to the contractor (!) who triages them (!) and collates data across multiple sites (noted in the GAO report are problems such as a software update preventing contractors from receiving ARs while the on-site personnel are waiting for an answer--eventually they call and ask, hey, what about those ARs? and the contractors respond, what ARs? because they didn't know they were failing). And technical manuals are accessible through ALIS instead of having to refer to paper manuals.
Of course, these are all so vague and general that it's hard for laymen to figure out what it would mean in practice. The terms used in the GAO report for expected functionality are so non-specific that it seems nearly useless to even use them.
Having said all that, the GAO report does mention (buried in the middle of a paragraph, not prominently like a major vulnerability should be) that ALIS can be used in an offline capacity:
> DOD officials told us that they recognize this issue and, for short-term losses of
connection, ALIS users are able to work offline. (page 17)
But that doesn't sound very reassuring to me. In wartime, all sorts of bad things happen, and lost connectivity and communications should be at the top of the list of expectations. If maintenance is severely degraded and aircraft can't fly sorties at the needed rate, well, in a war....
AIUI, every component of the plane has a unique identity and status. It sounded to me like this involves digital signatures and all that. So presumably, manual maintenance without the proper bookkeeping would be viewed as tampering/sabotage, and the plane would refuse to operate.
A droll reply would be, "It's a fighter, maintenance is always necessary."
But to give a real answer:
If a jet sits for 30 days without any maintenance, then it's supposed to be preserved. This means all fuel is offloaded, all lubricants drained and then refilled and then drained again (leaving a film of clean lubricant over important parts), etc. Otherwise, you have to perform an engine run to keep the aircraft nominally flyable.
Really, if you aren't flying, you are either doing maintenance to prepare to fly, fixing something, performing scheduled inspections, or performing modifications. So if the aircraft is operational, there is no such thing as a 30 day period without maintenance.
Without ALIS, you just do all of this via the old paper processes for a while.
> manual maintenance without the proper bookkeeping would be viewed as tampering/sabotage, and the plane would refuse to operate.
If that's true, it sounds like a solution is search of a requirement. IIRC, but I don't think the US military has had problems with tampering and sabotage of military jets.
That's a good question. I meant airgapped from the Internet, of course, but the "..." was meant to imply that it's the kind of thing that is easier said than done, and easily, accidentally done wrong.
Boeing writes (nearly) everything in Ada and as far as I know has never had any software problems of this scale. Most of it is in SPARK as well, a restricted subset of Ada that can be partially formally verified[1]. Frankly, not formally verifying mission-critical software where a failure can potentially threaten someone's life seems rather irresponsible.
1. Contrary to what seems popular opinion, regular Ada is not particularly strict (less so than Rust). SPARK is very, very strict about what you can compile, and if it compiles it follows the spec (which is usually easier to audit).
Speaking as someone who left a company that did radar software development in ADA (and some C). We were a subcontractor of Boeing and wrote the software for them.
We didn't formally verify the code, its way too complex, but everything was reviewed and heavily tested. And tested again. Then integrated and tested...
Ada is pretty strict and if it compiles you usually had some confidence it was going to at least run ok.
The industry was moving to C/C++ because developers know it and promises of higher productivity.
I did kinda grow to like ada. It had its warts, but it was good. It reminds me a bit of GO with its packages.
Ada Tasks also bear some semblance to goroutines. (In the sense that they share memory by communicating instead of communicating by sharing memory.)
It's definitely a nice and well-designed language IMO—with a share of annoyances[1] and flaws—but overall deserving of more attention than it gets. Lately I've gotten comfortable enough with it that I have been making a habit of reaching for Ada for side-projects where I would formerly use C. (For example, I'm writing a toy X window manager in Ada at the moment—using XCB from Ada is a little ugly at times but definitely bearable.)
1. For example, why can't a record discriminant be a range bound? Answer: standards committee didn't think people would use it. Of course, this means if you have an array of discriminated size, you can't conveniently have a type for a position in it. e.g.
type Thing_Stack (Max_Size : Positive) is record
Elements : array (Positive range 1 .. Max_Size) of Thing;
Top_Index : Positive range 0 .. Max_Size := 0; -- 0 = Empty stack
end record;
Fails to compile with "Discriminant cannot constrain scalar type". According to [2], this is because
> This restriction is left over from Ada 83 (RM83 3.7.1(6)). We considered removing this restriction in Ada 95, but ultimately decided that the implementation effort to support this modest extension would outweigh the (more?) modest benefits. Perhaps a short-sighted decision, in retrospect...
> As for why the original Ada 83 restriction existed, noone knows for sure, but it probably relates to the historical purpose of discriminants as only for controlling the "shape" of the record, rather than being seen (as in Ada 95) as more general type "parameters."
I liked the records in ada. You could control the position and size of each field (which was really usefully for dealing with in binary messages) We had a ton of constrained types.
If I remember we has assert 'size on some of the records to make sure type changes didn't cause some records to become unexpected sized in case the types that made up the record changed.
variant records were fun, but when you start trying to do much (array of variant records?) it fell down.
The string handling left a little to be desired though..
Not that alien a comparison, since Ada and Go both descend from Niklaus Wirth's languages. Ada was directly based on Pascal, whereas Go (and its precursors) is strongly influenced by Modula and Oberon, themselves successors to Pascal. Aside from some superficial syntax differences, Go looks a lot like Modula and Oberon.
The slightly sarcastic answer would be "C++, of course". There is even a code standars document that's floating around. (Edit) Link: http://www.stroustrup.com/JSF-AV-rules.pdf
That said, I don't really think the troubles come from the technology side of things.
Well, to clarify, that's the coding standard for the Air Vehicle (in other words, the airplane itself). That does not apply to ALIS (although there's nothing stopping them from using those coding guidelines if they really wish, I guess). I have no idea what ALIS is written in.
Seems like most of it is written in C++, while some parts reused from F22 is in Ada 83. This was done "due to programmer availability" according to Wikipedia (links the article cite for that claim are dead).
Learning Ada is easier than learning to write reliable software. If language experience is the barrier to ‘programmer availability’, then management is Doing It Wrong.
Indeed. I included that quote precisely because it shows such a lack of perspective. To get programmers with experience in safety critical real time programming is much harder than learning Ada, and training them to learn safety critical programming is much harder than learning any relevant programming language. But apparently the availability of C++ programmers was what they considered important.
Defense contractors won't invest in training. The programmers they hired would be mostly contract workers themselves because the MIC is deathly afraid of having actual employees that could cut into profits. Hence why they've managed to step away from ADA because those skills aren't readily available in the contractor pool.
It's not that people can't learn another language. The problem is nobody wants to be the guy looking for a job at a startup with ten years of Ada on his resume.
C and C++ for the vast majority. Some Ada. Some Fortran, but probably only in physical modules (LRUs) that are being reused (COTS or GOTS) from other projects.
The article seems to confuse ALIS with software that runs on the aircraft. ALIS is a web-based portal used by logistics and maintenance personnel to manage the logistics and maintenance for the F-35.
As the article states: “ALIS is the ground-based computer system meant to diagnose mechanical problems, order and track replacement parts, and guide maintenance crews through repairs. It also allows pilots to plan missions and later review their performance.”
Similar stuff happens in medical sometimes too. Everything is so restricted that at some point if you want to get something done you have to circumvent all security systems in a really bad hack way.
So instead of gently decreasing security when it's not possible to be totally secure... it's better to throw the baby out with the bathwater. Wonderful.
The gist of a convo with IT when I needed to work around some parameters:
"Hey IT dept. I understand the reason for our network restrictions, but we have a lot of data that we need to get to [some endpoint] using [some method]."
"Sorry, we can't relax the restrictions. You have to work within the parameters."
"But the parameters do not allow me to complete my job."
"Sorry."
I'd love to work within the parameters, but when IT won't budge, you're stuck with the least preferrable method.
That's not an IT issue, that's an organizational issue. If your boss cannot do anything including appeal to his/her boss, then you shouldn't do anything. That type of thing needs to be sorted out.
Clearly, in the case of the F-35 systems, federal law was violated doing the offsite thing. We see developers (and frankly some sysadmins) violating HIPA and this kind of stuff has to stop.
I know it's not the easiest thing to do, but the proper response is to walk to HR (with your boss alongside) and explain that you can't do your job. The improper response is to wardrive to the first open access point you can find and use that.
Exactly. One of the first things we learned in my UNDERGRAD security class is that "good" security which is unduly onerous will just make users route around it and revert to plain old bad security. The canonical example was ridiculous password requirements which just make people put their password on a post it on their monitor.
As you said, security requirements that are that onerous and too rigid to relax when necessary is just shittily designed security to begin with.
Yes, at least in medical settings, I think it's just as much about accountability and CYA than actually improving overall real-world security. If that person's action results in a leak than they can be personally sued and fined. Doesn't matter if they did it out of frustration with obstacles that made it very difficult to "get stuff done".
> Yes, at least in medical settings, I think it's just as much about accountability and CYA than actually improving overall real-world security.
I don't think your wrong, but an awful lot of system admins have ended up dealing with lawyers and courts. Your system admin having had a prior talk with the lawyers about security, HIPA, and who is liable will do wonders for their willingness to bend the rules for you.
Totally agree with all of the above - when sysadmins end up in court it isn't usually due to HIPAA itself.
According to both HIPAA and the major revisions in the American Reinvestment Act (aka Hurricane Sandy Bill), all HIPAA requires is non-cleartext data. It does not recommend or even define a cipher or crypto standard anywhere in the legislation. Legally speaking (IANAL), a zip file with password is fine according to HIPAA since it's non-cleartext.
So when those admins were in court it is usually due breach of contract (job spec says protect data, follow laws, etc.), heavy-handed tech illiterate lawyers, complete incompetence in hiring the sysadmin, or some other combination of madness - and not directly due to violation of Federal healthcare law.
The Joint Strike Fighter (JSF) is the first major DOD aircraft program to use
C++. Much of this software is either safety critical or mission critical and so
must be written in such a way as to be clear, readable, unambiguous, testable,
and maintainable. We discuss the driving requirements behind the standard and its
evolution. We give a quick overview of our standard and discuss how it differs
from later standards such as MISRA C++. We discuss lessons learned over our nine
year history of applying the standard to a large embedded software program. We
also address ambiguities in rules and difficulties with automated checking of
conformance with the standard.
Ok dumb question; if it's so damn broken why are we paying Lockheed Martin for it? Did someone not think to put a term in their contracts saying that if they can't meet basic milestones (working software) that the US Government (and the people) aren't going to pay for it?
A lot of these are "cost plus" contracts (the government pays the cost + a fixed % profit, and bonuses for meeting delivery dates). This has been railed against as wasteful compared to the private industry [1]
This is some of the thought process
(from article:)
"I've talked several times this year about the importance of having mature technology before you go into production," Thornberry said. "A lot of what happens with cost-plus situations is the technology's not mature so you don't know what it's going to cost because you haven't invented it yet. That's exactly what we're trying to get away from."
So the more excuses the companies make the more money make (the spec changed..), as long as you can get someone to sign off on it. The cynic in me notes that a lot of these companies have former military heads as presidents.
Some context is necessary here, because as engi_nerd explained, it's not as if the primary flight control system is crashing and having to be rebooted in mid-air. It's more like a separate system that's used by maintenance personnel on the ground. Of course, if the aircraft's maintenance procedures are designed around it, then deploying a whole wing of them isn't going to work very well, because high-performance aircraft are high-maintenance aircraft.
But I can't help but think of Battlestar Galactica. At what point does this software become too complicated? At what point does it become a vulnerability to be exploited by the enemy, or simply a liability reducing readiness below what's needed in wartime? I don't recall hearing stories about the F-16's or F/A-18's computers crashing and needing to be rebooted (or even the F-22's).
F-22 did have some howlers (the computers crapping out when they flew across an international dateline rings a bell) but as someone who casually follows high tech stuff including military equipment I don't remember anything on the scale of the issues they are having with the F-35.
I think a lot of it comes back to scope creep, the F-22 was designed for one branch by one branch to do one thing well, the F-35 was designed for multiple branches by multiple branches to do a bunch of things somewhat well.
Those two articles are talking about two different things.
ALIS is the logistics system for the program that has an off-jet and on-jet component. ALIS takes the role of a traditional computerized maintenance management system and expands it to include an on-aircraft prognostics and health monitoring component. The idea is to have the jet tell you what's wrong with itself.
The article you linked to is about the F-35's mission systems software, which is really a software suite that encompasses all the computers on the aircraft itself. The MS software load provides all the stuff necessary to make the jet's hardware do what it needs to do to fight.
For years, the F-35 project has been calling ALIS absolutely critical. Now, they seem to be saying that the F-35 can fly without it and that ALIS only keeps the cost of ownership down.
I suspect that the real answer to that question is either classified or closely held amongst a core group.
Sorry, I meant the F-35 software that ensure that the plane will actually stays in the air is fine, with no real bugs left. The ALIS software, that helps ground crew, maintenance and mission planing, I assume, is still buggy, so you wouldn't want to use it in a war time scenario?
I'm not sure I'm making a ton of sense. It's just really interesting, I'm in Denmark and our government are about to pick which fighter plane will replace our old F-16s, and the F-35 is the favorite right now. This is despite experts saying it's a bad plane. What I understood from your comment is that it will fly just fine, but bugs in the ALIS software would make it harder to operate than anticipated.
My understanding is ALIS was part of the 'pork' side of the F-35. It has relatively simple requirements and was simply used to extract as much money as possible from the government. That said, they have tried to make it essential as possible.
Given the low bars of success that seem to have been mentioned in this article, I'd wager there's still a lot wrong with the code.
I'm not wholly sure '15 hours uptime' on a computer system is all that confidence-inducing, regardless of whether or not the plane can be reset after however few hours of flight-time it's able to muster.
15 hours of uptime is outstanding when it comes to the avionics that aren't actually keeping the aircraft in the sky. Most legacy fighter avionics required restarts every few hours.
I'm just curious because I find it hard to believe that avionics in combat aircraft are or were so unreliable that they would have to be restarted every few hours. That would not work for e.g. bombers on long missions, fighters on CAP, etc. I can just imagine a pilot thinking, "Okay, we're about to cross the FLOT and I've got 20 minutes until the next avionics reboot. I'd better go ahead and reboot it now before we run into trouble..."
TFA is about the "Autonomic Logistics Information System" (ALIS) system used to automatically order replacements parts and schedule service, NOT the plane itself.
It's grounding the plane because they can't schedule maintenance and order parts correctly now that they're moving to this new system, not because the plane itself is buggy. The planes have been flying (mostly bug free) for over 10 years now.
A lot of people here are using this to scapegoat C++, but although the plane is written in C++, I don't think the ALIS is...
"The planes have been flying (mostly bug free) for over 10 years now."
Considering first flight was in December of 2006 there's no possible way it could have been flying for a decade as of today. Also that was the maiden flight, not a take-delivery-first-production-flight, but the first flight ever.
As for bug free, I'd beg to differ:
* On 18 January 2013, the F-35B was grounded after the failure of a fueldraulic line in the propulsion system on 16 January.
* On 5 June 2015, the U. S. Air Education and Training Command Accident Investigation Board reported that catastrophic engine failure had led to the destruction of an Air Force F-35A assigned to the 58th Fighter Squadron at Eglin Air Force Base, Florida, on 23 June 2014.
* On 23 June 2014, an F-35A preparing to take off on a training flight at Eglin Air Force Base experienced a fire in the engine area. The pilot escaped unharmed. The accident caused all training to be halted on 25 June, and all flights halted on 3 July. During the incident investigation, engine parts from the burned aircraft were discovered on the runway, indicating it was a substantial engine failure.
And a report issued in 2013 stated these amongst other major problems:
* Current aircraft software is inadequate for even basic pilot training.
* Ejection seat may fail, causing pilot fatality.
* Several pilot-vehicle interface issues, including lack of feedback on touchscreen controls.
* The radar performs poorly, or not at all.
* Engine replacement takes an average of 52 hours, instead of the two hours specified.
* Maintenance tools do not work.
"Bug free" I guess if those are acceptable criteria for a government defense platform that has racked up over a trillion in cost and has yet to perform much, if any, real-world value.
You're nitpicking, leaving out information, and trying to change the topic.
I said "over 10 years" because the first "official" flight was probably not the first flight ever. Change it to "over 9 years". Whatever. Practically the same thing.
The next sentence in the Wikipedia article you quoted says the grounding from 18 January 2013 was lifted 28 February 2013. Likewise the June 2014 grounding was lifted shortly after.
Regardless, I said "mostly bug free,", not "entirely bug free". Most aircraft get grounded at some point due to issues or accidents that are discovered after they've been flying a while, so it's really not very exceptional, and hardly means the entire project is a failure.
Do any of your nitpicks change the fact that that the article posted here isn't about the C++ software on the plane, but is about the non-C++ software running ground systems?
I don't have any opinion on whether the plane is a waste of money or a failure or not, but the headline is misleading, and people are missing the real point of the article.
Don't bother. Threads like this just become mindless ragefests from people with political axes to grind and sites like vice know how to exploit these feelings for ad impressions. Liberal doves also want anything to attack new weapon systems spending. Its an ugly scene altogether and accurate information and commentary about military programs are lacking.
I've lived through a few major weapons systems changes and its all the same. Heck, anyone who has ever worked on a large project knows this stuff is fairly common. A lot of people don't want this thing in the air, especially Russia, China, Iran, and North Korea. Its a very capable weapons system and fills a much needed role.
Its crazy a lazily sourced article like this could make it to the front page of HN. It reads like my grandmother wrote it, "THE AIRPLANE IS RUN BY A COMPUTER! TECHNOLOGY IS SCARY!" To compete on this level, automation and complexity are required. Its silly to think we are going to back to how planes were designed 50 years ago.
> Liberal doves also want anything to attack new weapon systems spending
I generally agree with your points, but not this one. I've seen no partisan bias in the criticism, and John McCain is the biggest critic of this program, which is being pushed by the Obama administration. In fact, IME most of the criticism comes from the temper-tantrum-of-the-week branch of the GOP.
Also, Democrats have become hawkish; almost everyone says they are for a strong military including Clinton and Obama. There aren't many of those knee-jerk doves left - can you name a prominent one?
I also think threads like this suffer a bit from the overall population that comes here. By this site's very nature, the posters and commenters don't tend to be people with military aviation and/or flight testing experience.
1) The F-35 has VASTLY more software and several software systems that the F-16 and F-22 didn't have.
2) The F-22 software was largely written in Ada, a sane language that's great for real-time systems that cannot fail. Apparently the F-35 software is mostly written in... C++. Writing fault-tolerant real-time C++ is like walking on a tightrope while gripping a gun with the safety off. You can do it, but it's not particularly pleasant.
3) Apparently the team was considerably expanded/replaced between the F-22 and F-35.
What the heck are we doing with these airplane projects? We build stuff we don't need, that doesn't work, and is waaay more expensive than we thought, and the starting cost point was extremely expensive to begin with.
> the F-22 was also over budget and under-delivered on expectations. So much that the Pentagon canceled the remaining production run after 195 aircraft
It was canceled because it was expensive and no longer needed, because the mission it was designed for - fighting a peer enemy - no longer existed. That was 2009, when the U.S.'s primary military concern was fighting two simultaneous wars against enemies who didn't own one airplane or air defense system. Any plane could do the job; we didn't need F-22s. Also, our prior generation planes were still the best in the world.
Seven years later, Russia and China have engaged in massive military military buildups, including significantly improving their air combat capabilties, and aggressive behavior. The peer enemy mission is back at the top of the list (and some are now talking about re-starting F-22 production).
According to that Wikipedia article:
"Defense Secretary Robert Gates had production halted at 187 F-22s (at a cost of $67 billion) to direct funds for ongoing irregular warfare operations in Iraq and Afghanistan."
Gates is also on record as saying that the F-22 was cancelled on a cost per aircraft basis. Which is a bit of a circular argument, because the cost per aircraft would dramatically decrease if the originally planned number had been built.
I don't really understand how the computer systems of the F-15 and F-14 which were written in 1970's and probably in assembly seemed flawless yet with todays tech we can't even do this?
> I don't really understand how the computer systems of the F-15 and F-14 which were written in 1970's and probably in assembly seemed flawless yet with todays tech we can't even do this?
Programming languages haven't evolved much since the 70's, yet the number of lines of code we have to write to fly a 5th generation fighter jet has probably followed the same curve as the number of transistors inside it. And scaling a CPU turned out to be easier than scaling a program. Imagine the difference in complexity between the earliest computers controlling car engines, and what the computers inside a new Tesla are doing.
The same with jets. Modern jets can barely stay airborne without a lot of computer power.
True, but can you even imagine being a software dev in 1970? Where TDD, unit testing, or testing even in general isn't even a thing thought of? It just seems so foreign.
Even now, someone in college and spend all of their free time reading blogs and books for best practice development and can generally fit in pretty good with any development group once graduated. I don't think people had those luxuries in the 70's.
> I don't really understand how the computer systems of the F-15 and F-14 ... seemed flawless
Who said they were flawless? Most major new platforms, including many prior fighter planes, had similar teething problems. Novel, huge, highly-complex, mission- (and life- and national-security-) critical systems are going to have a lot of them.
Also, modern systems have orders of magnitude more software, due to orders of magnitude more computer capability.
As a whole the F-35 is one of those big disappointments that was the direct result of each service branch having a say in requirements of the aircraft. There are more than a few documentaries and articles outlining this in fantastic detail.
I was an employee at Lockheed during the time of when the "JSF" vendors were competing for the contract. While I wasn't directly involved in any F-35 programs (I was on the MS2 side supporting NATO programs, particularly ASOC / SCCAN - that's another story in itself...) I was friends with a few programmers responsible for the main flight systems of the early aircraft (I'm unsure if that system was ultimately used in the production version or not) and the attitude seemed to be that the aircraft would never make it to operational use anyway. I was a, relatively, new and naive employee (first employment after college) and it struck me as odd that the plane was a joke internally to the company, at least those "building" pieces of it and it makes me wonder today if the lackadaisical attitude was ripe across all facets of the program. If so it makes sense today of all the failures the program has endured. The aircraft has always underperformed and been overbudget.
Ultimately the tax payers foot the bill for a next-gen aircraft that continually gets beat by task-specific variants that are decades older unfortunately. I used to joke around with people about how the $1000 toilet wasn't far off once I learned about how every program's goal was to be cost plus and then milk scope creep to the Nth degree.
The programs I was involved with were selling commodity Sun + Cisco + some overpriced serial to Ethernet bridges (http://spt.sunhillo.com/products.php) tied to some archaic war/peacetime ATC software. It was absolutely astounding what those packages cost and what was actually delivered.
I saw some were asking what language for some of these systems and if it were along the lines of what I was exposed to it was a mix of anything and everything. Most critical systems were written in ADA, as suggested, but I saw Java (think awesome Java in the early 2000's), TCL, shell scripts and the like as major components to these systems. In fact I remember a dev having problems getting working out reading serial data from a GPS receiver to set proper system time - so he just bundled ntpd in the build as his own work.
Working there was an eye opening experience for both good, and bad reasons. The stereotypical jokes were, unfortunately, true to an extent and I couldn't continue to justify pretending I was working on cool, unspeakable things that were shrouded in James Bond'esque mystique.
Ultimately I was proud walking in day one and couldn't get out of there fast enough. The people were great, but the management and true colors of the company were centered on, IMO, calculated enrichment of select groups of people. It was never about the best product - it seemed it was about who was next in line to get fed.
I didn't downvote you, but some things jump out at me.
The suggestion we sell them to Saudi Arabia is orthogonal to the subject of the article (technical problems). Your post and the article do not, from a naive perspective, have a connection.
My guess is that you think the F-35 project is not a worthwhile investment for the US defense system, but that it cost a lot of money to make, and so we should get some money out of it. Further, since Saudi Arabia has a lot of oil money and wants weapons, we should sell them this plane (which it seems you think is a failure) - even though Saudi Arabia is nominally an ally and it isn't obvious its a good idea to sell an ally weapons we consider bad investments.
My previous paragraph is a just a stab at the thinking that might inform your post - I'm probably totally wrong. Whatever the motivating factors, there's a lot you don't say - either because you don't think it's necessary or you don't want to talk about those background assertions. Obviously, we all believe the people here understand (at least some of) the context, but my guess is that people found your post to not be forthcoming enough.
The software has apparently been written in C++, it all sounds like a bit of a farce. EDIT: to clarify the above comment, the context is the use of C++ and mainstream tools for 8 million lines of safety critical code.
You can write safe C++ (although it's hard). You can write extremely buggy haskell or ada. Are you really that much of a language bigot you can't see past the damn language to provide any interesting conversation?
Speaking from experience, it's a hell of a lot easier to write buggy C++ than buggy Haskell or Ada (both of which can in some cases be formally verified to follow the spec).
C++ is unsafe by default and you have to write lots extra checks to make sure your code is bulletproof. Ada is safe by default and you have to be verbose to do powerful-but-dangerous things with pointers.
While yes, you can write secure and fault-tolerant code in any language and insecure and buggy code in any language, the sheer amount of C and C++ software that has been demonstrated to be insecure and very buggy in recent years raises some questions about whether that's the tool we want to use.
Languages are tools. C is a $5 wrench with a blade for a handle. Ada is a pocketknife where you can pull out the wrench or blade if you need it. Both of them can do the same things, but with one you have to be very, very careful to not cut yourself.
> C++ is unsafe by default and you have to write lots extra checks to make sure your code is bulletproof
No you don't, just use RAII and you cover almost all the safety issues. Put all memory allocations, file openings, mutex locking and other resource acquisition in constructors and the matching cleanup in deconstructors and it becomes very safe. Now, not only is memory cleaned up and exception safe, but several classes of file handling and multi-threading issues are categorically fixed. There are a few other rules to enhance this to the point of preposterous safety, but with just this technique I see fewer memory leaks than I do with some garbage collected languages.
The big safety issues occur when people take the unplanned style of treating C++ as if it were C with Classes. Something that exacerbates this is a plethora of bad training material (mostly old from before C++03) and even university classes that use manual memory allocations outside a constructor (naked new statments), exceptions and manual memory releasing in exception unsafe ways.
I am sure Ada can be used incorrectly, now imagine if in an old standard not all Ada compilers supported the same language features. Imagine the subset of common features was dangerous as hell. Imagine creating a memory structure like a linked list because only some compilers provided one prewritten and some are implementations were missing core language features. However, all the compilers ship with dangerous tools to build it wrong. This was C++ in 1995, and many people who learned it then never unlearned their mistakes.
C++03 laid down a bunch of technical fixes and a minimum benchmark for decent compilers. It could have been used safely with what I described above, but much of the developer community was change averse. Now with C++11 we are changing and really cool things are happening because the developers are treating it like a different language.
I mean, if you stick with the stack and avoid pointer manipulations C++ can be pretty damned safe. Still, there's a reason Ada is typically used for things like flight control systems....
That sounds like they were looking to scrape the bottom of the barrel. If programmer salary played a key role for such a critical piece of software, they have bigger problems.
From what I understand from this thread, it's worse than that:
The problem wasn't programmer salary, it was that their budget was so big that they wanted to hire extra people and could not find enough Ada programmers. Yup. It got written in C++ because they wanted to spend more money and there are more experienced C++ developers than Ada developers.
No, not least because it's garbage collected. It may be useful for writing a DSL in which to write real-time software though: http://ivorylang.org/tower-overview.html
Your comment would be stronger and you'd make the exact same point if you removed the entire last sentence. That level of aggression has no place here.
This is a government development project. Do you really think they're getting the C++11 features that make writing C++ half-pleasant? It's more likely that some PM tried to define a "sane subset of C++", with templates explicitly banned. Now they can't use STL containers or unique_ptr, and they're basically writing C with classes.
NASA basically uses the approach you patronize so easily. And while I'm not arguing that it's practical to take this approach, defensive coding techniques allow reliable code to be written in environments that wouldn't be considered safe today... like the Apollo Guidance Computer. So yea, I don't consider it useful to finger C++ when there were clearly many poor decisions made at all levels of the engineering stack.
The Apollo Guidance computer wasn't anywhere near the scale and complexity of the F35 software. I'm also fairly certain the Apollo mission did not pick their technologies based on "programmer availability".
I wish the source for "programmer availability" hadn't evaporated into the ether, because I'd love to see it.
I wonder if it meant "The guys who know Ada are all furiously writing F-22 software" -- parenthetical aside, the F-22 was in flight testing and development during the same years that the F-35 project was getting underway, so there would have been high demand for people experienced with developing mission critical flight software -- "and therefore we have to go with the guys we can spare, who mostly know C++ or Java or something". Or did they mean "No one coming out of school knows Ada anymore so let's go with a more widely known language"?
C++ is not a safe language. Ada has many more safety features. What is very interesting to me and perhaps others is why C++ was chosen, despite being (IMHO) unsuitable for such applications. I am not a language bigot because I would use the right tool for the job. What would you use?
I would probably use Ada as well. However, calling out C++ is like blaming the gun for an accidental suicide. Yea, the gun may have been faulty, but why was it in that position in the first place? Terrible management with way too much funding.
It was probably largely written by Ada programmers transitioning to C++, along with people with prior C++ experience but with no/little experience writing mission critical software.
I'll be an asshole. Defense contractors hire Electrical Engineers straight out of college and throw them at programming tasks. They hire Computer Scientists straight out of college and throw them at testing tasks. Of the two, the CS graduates (still woefully underexperienced) should be doing the programming, but not the design work. Instead you have EEs with 0-3 programming courses under their belt doing it. You end up with software like what I saw in my defense contractor days, where fucking BUBBLE SORT was used on an embedded system to sort 100 items. Not that long, really, but in the worst case it's 5050 iterations of a loop. These same "programmers" insist on minimizing function calls because the overhead of function calls is clearly where the hotspots are.
EDIT: But yeah, the major issue (regardless of their preference for engineers over computer scientists) is a general lack of experience in the people they hire [for the domain].
* Pilots, maintainers, and administrators at three of the five sites we visited are concerned about ALIS’s ability to deploy and function in forward locations. For example, users are concerned about the large server size and connectivity requirements, and whether the system’s infrastructure can maintain power and withstand a high-temperature environment.
* ALIS users at three of the five sites we visited are concerned that a failure in the system’s current infrastructure could degrade the system and ground the fleet. Currently, ALIS information, including data from all U.S. F-35 sites, flows from the Standard Operating Units (SOU) to a single national Central Point of Entry, and then to the lone Autonomic Logistics Operating Unit (ALOU).26 This data flow process has no back up system for continuity of operations if either of these servers were to fail.
* Maintainers and pilots at three of the five sites we visited were concerned that ALIS does not have much interoperability with legacy aircraft systems... The ability to share information between ALIS and these legacy systems is vital due to the way the services operate.
* Maintainers at four of the five sites we visited told us that the current Action Request (AR) process does not allow for the effective reporting and resolution of F-35 aircraft and ALIS issues.
* ALIS users at all five sites we visited are concerned with data accuracy issues within the system, including missing or inaccurate data and inaccessibility of raw data within ALIS.
http://www.gao.gov/assets/680/676576.pdf
Description of ALIS risks starts on page 15.