“Could have been worse” is probably a good four-word summary of the latest Joint Strike Fighter report by the director of operational test and evaluation, Michael Gilmore. If you paid attention to Gilmore’s congressional testimony on June 19 (too few people did), or to our coverage, there is little shocking news.
On the other hand, if you were confidently expecting the program to make the scheduled initial operational capability dates announced last May (too many people were), the report is a cold shower, making a strong case that those dates may be missed by a year or more.
Gilmore’s team is most specific on the first planned IOC, for the Marine Corps. The current objective date is July 2015 (objective) and December 2015 (threshold). The report predicts that the necessary software, Block 2B, will not complete developmental testing until November 2015 or be released to the fleet until July 2016, 13 months late. Since an operational utility evaluation (originally set for May 2015) will then be needed before IOC, the aircraft would not be operational with the Marines until late 2016 or early 2017.
The report also gives new detail on the strong linkage between Block 2B and Blocks 3i and 3F. Block 3i supports the US Air Force IOC (objective August 2016, December 2016) and basically re-hosts Block 2B’s capabilities on a the new Technology Refresh 2 integrated processor, which is installed on Lot 6 and later F-35s. Block 3F provides full operational capability (that is, compliant with the key performance parameters established when the program started) for Navy IOC, with an objective of August 2018 and a threshold of February 2019. It is also the supported configuration for most international operators.
Most Block 3i/3F testing cannot start until Block 2B developmental testing is completed, which (according to the official schedule) is due to happen in October. “All program plans and schedules [for 3i/3F] depend on this happening so that the development laboratories and test venues can be converted and devoted to testing the Block 3 hardware,” the report says, but predicts that the switch will start more than a year late.
A complication is that the Lot 6 aircraft with the new processor start to roll off the production line in the middle of this year, but cannot be accepted without certified Block 3i software. To avoid the problems associated with a pile-up of grounded jets at Fort Worth, the program office is modifying three mission systems test aircraft (one of each variant) with TR-2 processors to test an early increment of 3i. However, these aircraft will then be unavailable to support Block 2B development.
Gilmore’s predictions about testing schedules are more specific than those he advanced in June, when he first noted that the then-new IOC dates were at risk. The report is based on the actual growth rate – in testing needed to accomplish specific tasks – between January and October 2013. It separates testing of the helmet-mounted display system from other things that needed more testing than predicted – “regression testing” of seven different software loads and issues with the radar and electro-optical targeting system, among others. If that historical growth rate of 40 percent is maintained, the predicted delay will occur, the report says.
Other problems noted in the report:
One reason for delays in Block 2B was that the first training standard package for use by the US Air Force at Nellis AFB and the Marines at MCAS Yuma, Block 2AS3, was rejected by flight test teams as being unsuitable for night and instrument flying, and the program “had to make adjustments to Block 2B” while another 2A version was developed.
The first attempt to load Block 3i on an F-35C, in October, failed.
So far, the highly touted Distributed Aperture System (comprising six infra-red cameras covering an entire sphere around the aircraft, and intended to track aircraft and missiles while delivering imagery to the helmet) has failed in its most basic function as a missile warning system, being unable to tell missiles from decoy flares.
The program is still dealing with poor target track quality from the EOTS and radar, which is causing problems with demonstrating simulated weapon engagements.
Development of “enhanced diagnostics (model-based reasoning)” for the Autonomous Logistics Information System (Alis) has been cancelled for the rest of the system development and demonstration phase, because the current diagnostic system has, so far, “failed to meet basic functional requirements, including fault detection, fault isolation and false alarm rates.” (These are otherwise known as “what diagnostic systems do.”)
The reliability of the training fleet is well behind predicted levels.
Despite these and other issues, software is still the critical issue for this program, and the corrective actions taken since 2010 (including added flight test time, new laboratories and more engineers) do not seem to have resulted in a stable and predictable schedule.
The report does not go into root causes, but I believe that (ultimately) there are two big issues that will be identified.
One of these is that sensor fusion – taking targets from radar, electro-optical, passive electronic and other sensors, together with datalink information and databases, and fusing them into a single set of targets – is extremely difficult. Every program that does this has had problems, and the transition from ground-based laboratories, through a flying test bed, to real-world operations seldom goes smoothly. Unlike software-intensive ground-based computer systems, the initial inputs are unstable and unpredictable analog signals, and airborne sensor-fusion systems can’t be tested on hundreds of PCs running 24/7.
The other issue is that the F-35 system is highly integrated, with its higher functions concentrated in the integrated core processor banks in the forward fuselage. This was an architecture inherited in 1995 from the F-22, because, at the time, a shared-processor approach appeared to be the only way to provide enough horsepower for sensor fusion in a fighter aircraft. But it may mean that regression testing – that is, making sure that a change in software has not impacted another function – becomes more extensive and complicated. The need to do more regression testing than predicted has been a recurring factor in F-35 delays.
As for fixes: Is the Block 2B configuration holding the entire program up? In some ways it is clearly doing so (by hogging laboratories that are needed for 3/3i). Its military value is strictly limited: It allows the Marines to field one squadron of aircraft with a limited operational capability (they are not compatible with the Rover video datalink, near-essential for close air support, and do not have a gun or AIM-9 provisions) a year before 3i would be available. On the other hand, an early operational capability could be a valuable way of surfacing unexpected snags.
In the long run, however, what will be most important is for the program to fully understand and manage the writing and testing of software for the F-35 platform, because development does not stop with Block 3. If cost overruns, delays and the consequent deferment of new capabilities from one block to the next are not contained, there is little chance that the fighter’s sustainment will be affordable.
:
