Joint Strike Fighter Systems: Software
Software Defense equipment has fundamentally changed from the 1970s and 80s. Most defense systems’ added value is no longer in the hardware but overwhelmingly in the software. Given the growing complexity of software, cost and schedule overruns escalated and, with them, the cost not only to develop but also to maintain the software during the life of the system. A common rule of thumb holds that maintenance of the software will require about 40 percent of the cost to develop it, assuming the addition of no major new capabilities. Furthermore, although estimating the added value of software versus hardware in the JSF program lies beyond the scope of this article, a plausible guess is that it cannot be lower than the F/A-18 at over 50 percent software and likely is in the 80–90 percent range or higher, depending on the value of the reused code modules from previous programs and the cost of writing DO-178x-certified code.
Once the United States made the policy decision that it would not share the source code (not even at the modules level) with the largest partner and biggest contributor to the program (the United Kingdom), it became clear that such a policy effectively locks out partners from all but a very small amount of the added value in the entire program, no matter how many industrial benefits the DOD may claim for the partners. The question then becomes, how can one leverage benefits from such a model imposed by the DOD? Britain initially sought to have source-code access to the JSF software as befitting the sole level I partner of the program. The United States, however, refused the request. Ultimately, Britain applied considerable pressure up to and including a threat to pull out of the JSF program and obtained an agreement in 2006. According to President G. W. Bush and Prime Minister Tony Blair, “Both governments agree that the UK will have the ability to successfully operate, upgrade, employ and maintain the Joint Strike Fighter such that the UK retains operational sovereignty over the aircraft.”
The specifics and details remain classified, but it is believed that the United States in fact did not transfer the source code but gave the United Kingdom priority and assurance that its needs would be met by timely American-engineered upgrades. Why is control of the software so important? Technologically, functionality has steadily migrated from hardware to software ever since creation of the first vacuum tube electronic device. Added value has steadily moved away from making physical things to designing software that made the devices more useful. During World War II, a major Allied innovation was the invention of the proximity fuse, a miniaturized radar transceiver that triggered the explosion of an artillery shell near a target, enabling the use of airbursts of shrapnel against difficult-to-hit targets such as aircraft. This progress continued the use of hard-wired electronics until the recognition that in the 1973 Arab-Israeli war, such electronics enabled the jamming of Israeli systems and led to the development of reprogrammable radar and electronics.
The F/A-18 was the first aircraft of its kind to be equipped with a programmable radar having a one-kilobyte hard drive on board. This radar allowed dynamic reconfiguration of the F/A-18 in flight, switching from air-to-air combat mode to ground-attack mode, making the aircraft the world’s first truly multirole fighter. It was also the first major defense program in which the cost of developing the software exceeded the development budget for the hardware. Since that time, on every major program, software costs have exceeded those for hardware. The importance of software in increasing the capabilities and lethality of military systems is now central. For instance, software lines of code (SLOC) for all F/A-18 variants are as follows: A/B model was 943,000 (943K), C/D (2,130K), Night Attack (3,054K), C/D XN-8 (6,629K), C/D SMUG/RUG (14,268K), and E/F (17,101K).
As “smartness” of weapons increased, productivity improved. During the first Gulf War, although the tonnage of “smart” bombs was relatively small, they demonstrated to the world that a few precision targeted bombs could accomplish what formerly required large fleets of bomber aircraft carrying “dumb” bombs. This brings up the issue of productivity or lethality of the JSF versus that of the alternatives. As the largest contributor, the United Kingdom solved the problem by leveraging a technology that it historically controlled into STOVL technology, ensuring that not only the manufacturing of the physical parts but also the software developed for that portion of the JSF stayed in the United Kingdom. Norway, on the other hand, lobbied the United States successfully for a commitment to integrate the Norwegian-made Joint Strike Missile (JSM) into the F-35, which will likely have many customers—including the US Navy. Norway estimated that the JSM will probably result in $3.3 billion to $4.2 billion in revenues. In a similar fashion, Israel, one of America’s closest allies, got a commitment from the United States for “plug and play” compatibility for a range of Israeli-made electronic warfare and other systems. All of these models did not require the United States to compromise on its insistence on sole control of the F-35 source code.
At present, it remains unknown whether Canada, as a part of the Canadian JSF program, has crafted or is crafting a complementary program to develop and field a JSF-compatible product that fits with particular Canadian needs and that potentially has an export market to all JSF customers, including the DOD. Given the size and scope of Canada’s commitment to the JSF program and that country’s long-standing status as a reliable ally, it is within the realm of possibility to ask the United States for at least a deal comparable to Norway’s and Israel’s.