After 15 years of development and billions of dollars of investment, software glitches continue to hamper Lockheed Martin F-35 Lightning II operations and in one case, just one of six US Air Force F-35As on a mock deployment to Mountain Home AFB in Idaho were able to takeoff during an alert launch exercise.
“The Air Force attempted two alert launch procedures during the Mountain Home deployment, where multiple F-35A aircraft were preflighted and prepared for a rapid launch, but only one of the six aircraft was able to complete the alert launch sequence and successfully takeoff,” the Pentagon’s top weapons tester disclosed in written testimony to Congress on 26 April. “Problems during startup that required system or aircraft shutdowns and restarts – a symptom of immature systems and software – prevented the other alert launches from being completed.”
The deployment took place in February in preparation for the first trial deployment of the 34th Fighter Squadron of Hill AFB, Utah, which is slated to declare initial operational capability (IOC) with Block 3i aircraft sometime between August and December this year.
It is one of many examples of failed launches attributed to "immature software" that has been loaded into the 179 aircraft Lockheed has already delivered to the Pentagon and international customers since concurrent production and development began in 2007 "well before the stability of the design could be confirmed through testing".
US Air Force
In another “relatively recent” example detailed by the US Defense Department’s director of operational test and evaluation J Michael Gilmore, two of four aircraft loaded with an early version of Block 3F had to abort an attempted electronic warfare "super scenario" mission because of software stability problems experienced during startup. “Also, when the aircraft operated in a dense and realistic electromagnetic environment, the current avionics problems caused poor detection and fusion performance, which is exacerbated in multi-ship F-35 formations,” Gilmore adds.
Software issues continue to be a problem for US Marin Corps F-35Bs loaded with Block 2B software, even though those aircraft are supposedly the most stable, with a reported average of "8h between software stability events".
Gilmore says if used in combat, the F-35B would need help avoiding threats, acquiring targets and controlling weapons. The Block 2B aircraft are only equipped to carry two bombs and two air-to-air missiles internally, but are also hobbled by “fusion, electronic warfare and weapons employment” deficiencies that cause “ambiguous threat displays, limited ability to respond to threats, and a requirement for offboard sources to provide accurate coordinates for precision attack”.
Software issues also plague the latest Block 3i aircraft, which are modified with an improved processor. On 25 March, the F-35 Joint Programme Office (JPO) began flight testing the Block 3iR6.21 software version. Gilmore reports that during the first 30 flights (76 total flight hours) “no less than 27 power cycles were required to get all systems functioning between initial startup and takoff", ranging from full “cold iron” aircraft restarts to component or battery recycling.
DOD
The spike in reported software troubles comes as the F-35 programme moves away from parallel coding of multiple, concurrent software blocks to a sequential programming effort, something that F-35 programme chief Lt Gen Christopher Bogdan believes will make the incremental improvement process significantly more efficient.
Bogdan says he has been encouraged by the demonstrated stability of the newest iteration of Block 3i and he expects to make a decision by 1 May as to whether that’s the software load that the Air Force's first F-35A combat group will declare IOC with later this year.
The average time between Block 3i “stability events” currently stands at once every three or four hours compared to 8h for Block 2B, says Bogdan, but the latest Block 3i iteration that has been tested over 44 flights and 96 flight hours appears to have tripled in reliability – one failure every 15h, approximately. Bogdan praised Lockheed Martin, Northrop Grumman and BAE Systems and a DOD "red team" for working through the root-cause of these latest software issues and finding a solution. If the initial results prove accurate, Bogdan says it will become the last version of Block 3i.
"Once all the operational tests are done this week, I will make a decision if that version of 3i software is it. I’m leaning toward it being ‘it’,” Bogdan tells reporters after the Senate Armed Services Committee hearing on 26 April. “Other than safety of flight things, that’s going to be the software [the Air Force] declares IOC with. No more 2B, no more 3i and no more 3F at the same time – just concentrate on 3F. We think we’ll gain some efficienciesthere.”
US Marine Corps
Even if the software issues are fixed to a reasonable extent, there is still 60 days of “schedule risk” that could set back the Air Force’s IOC declaration with the conventional A-model. That risk relates to the long-troubled, back-end logistics and aircraft health monitoring network known as the Autonomic Logistics Information System (ALIS) that manages the flow of spare parts to aircraft at every main base and deployed location. The latest iteration of ALIS (version 2.0.2) incorporates data from the F-35 afterburning turbofan propulsion system, built by Pratt & Whitney. Incorporating this data and other ALIS fixes has proven to be extremely difficult, says Bogdan.
“All of the things that are necessary for [the USAF] to make that [IOC] decision are on track for a 1 August 2016 declaration with the exception of ALIS,” he said during the congressional hearing. “I believe ALIS is approximately 60 days behind, and therefore, I would put ALIS delivery – which is a criteria for them – at about 1 October 2016 as opposed to August.”
Source: FlightGlobal.com
