One thing not appreciated at all at the beginning of the development of the F-20, the first digital fighter, was the difficulty of software development. To engineers who spent years developing analogue electronic devices to handle complex tasks, the prospect of building a piece of equipment that could change how and even what it did just by changing the software seemed a dream come true. At the beginning of F-20 development, one would often hear the refrain when a change was proposed "that will be easy - it's only software".
As development progressed it became apparent that software changes were easy to make, but very hard to implement. Every change brought the possibility of a new bug, or an unforeseen interaction with some other software routine. On the F-20, with the various black boxes communicating with each other in a fairly simple manner over the mux bus according to a rigid interface control document, these problems were not so great at the aircraft level. But at the level of the individual units of equipment, completing the software development, and implementing changes later on, proved to be a monster task of unprecedented difficulty. By the end of development, when a change was proposed, the refrain was "... it won't require any software changes, will it?"
This was the introduction to the digital world, which now results in aircraft development taking decades instead of years. The digital hardware would go through generations of improvements of several orders of magnitude while the software was developed. This ended up making software, original seen as a godsend, the long pole in the tent, the pacing item in aircraft development.
A lot could be said for the old analogue systems. During development flight test of the YF-17, a change in the analogue fly-by-wire flight control system would involve an engineering order looking something like this:
The necessary circuit board would be pulled from the computer, and flown overnight from Edwards to Phoenix, where a resistor array or other discrete components on the board would be removed, and different ones with the appropriate values soldered into the board.
For the digital fly-by-wire system of the F-20, changes to the flight control computer would be defined by a mathematical formula. The change could be implemented in software, but then a large amount of testing would have to be accomplished to be sure that this did not result in unforeseen problems or a bug that made the aircraft unsafe to fly.
Either system could result in unforeseen pilot-induced-oscillations, where the pilot chased lags in the control system, resulting in a vicious feedback loop that would result in the aircraft going out of control (as happened most recently with the YF-22 prototype). But software problems could remain hidden for years, only becoming apparent when the aircraft came into a never-before-encountered set of circumstances.
An example on the F-20 occurred during the two-aircraft world tour. After GG1001 crashed in Korea, GI1001 had to make the lonely trip home, alone, across the north Pacific from Hawaii to Alaska. The two aircraft had traveled around the world easterly, flying from California, to Farnborough in England, then across Europe, North Africa, and Asia. As the aircraft crossed the international date line for the first time, the inertial navigation system went haywire. The pilot had to use the compass, and once within range of Alaska, radio homing to navigate. After landing, shutdown, and restart in Alaska, the system worked fine. The problem was found to be a multiplier with the wrong sign deep in the software code. The problem would never emerge until the moment the aircraft first crossed the international dateline, going from west to east.
Back to the F-20A Tigershark Home Page
© Mark Wade, 1997 - 2006 except where otherwise noted.
Please contact us with any corrections, additions, or comments.