Abstract
Factors that influence software project management includes project size, delivery time, budgets and costs, application domain, technology to be implemented, system constraints, user requirements and available resources.
F-16 is a multirole jet fighter aircraft originally developed by General Dynamics for the United States Air Force. It is used now by Air Force of thirty countries. F-16 aircraft has computers that are fixed inside its structure. These computers provide high-tech solutions for complicated environments that pose multiple threats of modern generation of weapons.
The core strength of the computers fixed in F-16 is its software known as the Operational Flight Program (OFP). F-16 has many classified information and several versions and types of weapons for the operational flight programme. The entire F-16 system hardware is enabled by the Operational Flight Program, which consists of a series of software modules. Each Operational Flight Program software module identifies the functions of a separate weapon system or operating systems.
The aim of this study is to analyse the software capabilities of the F-16 Operational Flight Program and to update it from time to time.
[sociallocker id=”568″]
Introduction
The F-16 aircraft were designed to strengthen the combat capability of the United States Air Force. It was originally developed by General Dynamics and later further developed by Lockheed Corporation, which then became Lockheed Martin. Fighting Falcon is one of the most important fighters of the last part of the 20th century.
The development of the F-16 began with the concept of an experimental lightweight fighter. It then fostered an aircraft fighter that operated in all kinds of weather and had the capability to attack any enemy target.
The production of F-16 is carried out in five different production lines. Over 4,000 F-16 aircraft fighters have been built for the Western World and have become their largest fighter programme.
The F-16 aircraft are used in war and are mostly classified in design and development. The software technology used in the built-in computer system is the most critical, accurate and zero tolerance code. Automation of the management of the war is carried out with the F-16 aircraft operating flight programme.
The Operational Flight Program (OFP) is a computer programme for computer hardware fixed inside the F-16 aircraft. The Operational Flight Program needs to be updated and updated as and when new needs for improvement of F-16 aircraft are identified and, as a result, weapons are improved or changed.
[sociallocker id=”568″]
Methods
F-16 Operational Flight Program
The F-16 Operational Flight Program is written in the form of a module. Each module performs and performs the functions of the weapon system. The coding of the functions is done in such a way that each function describes the phases of the mission a weapon system performs.
The phases which are included in the mission are “preflight, takeoff/time to cruise, outbound cruise, SAM (surface to air missile) evasion, descent, penetration, bomb delivery, climb, air-to-air combat, inbound cruise, loiter, and approach and landing.” (Charles P. Satterthwate, 1994)
“Function types include communication (external/internal), IFF (identification friend or foe), navigation, guidance, steering, control, target acquisition/identification, stores management, weapon delivery and threat warning.” (Charles P. Satterthwate, 1994)
“The modules of the F-16 Operational Flight Program include executive; control and display; air-to-air; air-to-ground; navigation; communication; heads up display; vertical situation display; gun, missiles; overload warning and visual identification.” (Charles P. Satterthwate, 1994)
“A module type, such as controls and displays, might contain multiple modules which are prioritized according to the timing requirements of the functional calls of the OFP. The OFP is required to process real time interrupt driven schedules, which are handled by the executive modules.” (Charles P. Satterthwate, 1994)
“The modules of the OFP are made up of machine level object code. Access to this object code by OFP maintainers is through a higher order language source code which can be compiled to the object code. Examples of higher order languages used in maintaining Operational Flight Programs are Ada, COBOL, and FORTRAN
The embedded computer system has partitioned memory which is filled with some type of machine level object (binary) code. The OFP is loaded into this partitioned memory, and when enabled, empowers the whole system to perform its desired functions Each embedded computer system has an instruction set which is burned into its Read Only Memory (ROM). The instruction set allows the embedded computer maintainer access to the OFP as well as the capability to optimize the remaining partitioned memory. The level of sophistication of an embedded computer system is a function of the programming expertise of its OFP maintainers, its instruction set, its memory, its hardware, and its throughput.” (Charles P. Satterthwate, 1994)
F-16 OFP Planning, Growth and Maturity
“The changes in Operational Flight Program are required when users of the system require an altered mission; some flaw is discovered while the embedded computer system is operational; some combination of events might cause partial or total system failure, prompting a review and redesign in the effected areas of hardware, software or both.
There are several steps that needs to be followed to make any changes in an Operational Fligh Program. The task of changes can be a new block cycle or making a new version.
The first task for upgrading changes is to diagnoise and understand the required changes. The person who maintains the Operation Flight Program when understands the changes required, he analysis it and determines the areas of OFP that are needed to be modified. The Operation Flight Program is usually made up of number of serial modules each having a specialized function. Any change required in any single module might impact, effect and solicit changes in other modules as well.
The modules identified by the maintainer is then isolated by him by making its copies. The design changes are made in these copies. Once the changes are implemented it is integrated together with the unchanged modules by linking and generating a unique Operational Flight Program.
The last and the most important tasks of changes is the thorough testing of the modified version by putting it through an acceptance test procedure.
When the size of Operation Flight program is huge, the number of person maintaining the software is many. When many changes are made by separate person simultaneously then the leader of the maintainers integrate the final version by linking all the modified versions with the unchanged modules. He then tests the new operational flight program. ” (Charles P. Satterthwate, 1994)
F-16 OFP Major Components of Testing and Development
The Target Processor
The computer fixed inside the F-16 architecture is usually called the target processor and it should be accessible to the programmers who are maintining the OFP software. This helps them to build a mockup support environment which is used to test the OFP changes. The mock up support environment must “stimulate the processor input requirements and receive the processor output. Some examples of inputs are power, cooling, and peripheral interfaces (such as pilot commands and avionics suite inputs). Examples of outputs include pilot displays, as well as, command and control logic for other processors” (Charles P. Satterthwate, 1994)
The Support Environment
The maintenance of F-16 Operational Flight Program needs computer system and simulation environment that are fully dedicated for the purpose of maintenance of OFP.
“The dedicated computer system allows the maintainer to access the OFP’s object code as well as to copy and alter this code. The simulation environment allows maintainers to run the OFPs which enables them to interactively debug and test. The hardware of a dedicated computer system usually includes mainframe computers (or powerful engineering workstations), various types of printers, disk storage devices, networking, and several access terminals. Embedded computers and dedicated computers are frequently confused as being the same. These are actually quite different. The embedded computer is the target processor which is part of the weapon system. The dedicated computer is outside of the weapon system and is used to support the software run on the embedded computer system. The dedicated computer system provides system conventions which are configuration management, security procedures, and proper operation of the dedicated computer system.” (Charles P. Satterthwate, 1994)
The Simulation Environment
‘OFP must have a means of operating in real-time, that is, loading it in its target processor and exposing it to a range of conditions (or a reasonable subset of those conditions) encountered while in operation. This allows the maintainer to debug the OFP actively. The degree of complexity of the OFP environment is directly related to the complexity of the simulation environment. In the case of a typical fire control computer, a method is required to represent the full avionics suite and the dynamic environment of the fighter. An interface to all cockpit controls and switches, as well as an interface between the dedicated computer system and the simulation environment, is required. Finally, it is essential to have competent maintainers who know how to make the system work.
Simulation can range from a fully operational weapon system (the flight test is very expensive) to an all-software engineering workstation. Usually the simulation is a representative set of the LRUs (Line Replaceable Units) of the weapon system with the software emulating the cockpit and the dynamic environment.
Interaction with the simulation environment is done through inputs. Inputs include switch positioning, the preset of the dedicated computer system. Simulation utilities hosted on conditions such as altitude or airspeed, and hardware of the dedicated computer system allow the loading of OFP interrupts to name a few. The OFP is loaded into its target processor and also allows the OFP to be embedded in a computer, hosted in its simulation environment, performed dynamically or statically. These utilities also and required to respond to these inputs in the form of static enable recording, patching, debugging, freezing, and dynamic displays that can be checked against OFP initialization.” (Charles P. Satterthwate, 1994)
The Avionics Integrated Support Facility (AISF)
“The facility which houses the dedicated computer system(s) and the simulation environment(s) is the Avionics Integrated Support Facility (AISF). Another name for the AlSF is the Centralized Software Support Activity (CSSA) The AISF supports one or more embedded computer systems and the associated operation flight programs.” (Charles P. Satterthwate, 1994)
The OFP Tests
“The tests of operational flight program are related to the confidence desired of the targeted system or subsystem. Low level testing might be sufficient for minor operational adjustments such as flight-line data entry. The critical processes such as affecting life support, terrain following radar, and navigation, etc. require highly integrated and specialized testing.
These test processes often require specialized hardware, test equipment, test software patches and expertise of software language.
The acceptable level of testing requires that the crew members must be assured of the normal operating conditions of their weapon system, its fail safe capability and maximum performance capabilities.
The OFP tests are not acceptable in their first cut even when they go through Operational Test and Evaluation five or six cycles through the testing process. Much of this is related to the complex nature of OFP, poor interpretation of OFP engineering change requests and changing mission requirements midstream in OFP development (ref 6)
There are several types of OFP tests which are necessary prior to the operation of the aircraft. These tests are given as under:-
- The Acceptance Test Procedure (ATP): This test is designed to check out an OFP to a degree that it can be released with confidence to flight test and then operational test and evaluation. It is a chronological check of the OFP’s responses to inputs such as switch positioning, preset conditions such as altitude or airspeed, and hardware interrupts. The OFP is loaded into its embedded computer, hosted on its simulation environment, and required to respond to these inputs in the form of static or dynamic displays, which can be checked against expected results.
- The Baseline Acceptance Test Procedure (ATP): It is the ATP which complemented the most recent version of the OFP. An ATP should be developed concurrently with its OFP that is any additions, deletions, or modifications to the OFP should be paralleled by the ATP (ref 7)
- Unit Tests: A unit test is the lowest level of testing at the module level. As an example, if some loop mechanism exists within a module, it is checked with a clock to time it and count its iterations.
- Subsystem Tests: A subsystem test combines units to represent a functional set of an OFP. Checks for these types of subsystems include setting a value in one module, running the OFP, and inspecting values in other modules against expected values.
- Integrated Tests: Integrated testing represent several layers of OFP testing which include exercising of an OFP’s complete module set. Sub system test combines units to represent a functional set of an OFP. Checks for these types of subsystems include setting a value in one module, running the OFP, and inspecting values in other modules against expected values.
- Static Tests: Static tests are not dependent on time. Given an input, or a combination of inputs, an expected response is received. As an example, in gun mode, a gun reticle should appear on the pilot displays. When the gun mode is initiated, the gun reticle is either present or not present. If it is not present that it has failed the static test.
- Dynamic Tests: Dynamic tests are complicated and dependent on time. They require a sequence of inputs over some time interval in order to ensure proper functioning of the OFP. As an example take observation of an expected Signal-to-Noise Ratio (SNR) improvement as range decreases on a target being tracked with radar. The difficulty of this test is that it requires an OFP maintainer who can visually verify the test case. The maintainer has to know from experience what a sequence of responses should indicate. The quality of OFP testing in the dynamic cases is often limited to the experience level of OFP maintainers available for testing.
- Automated Tests: As the complexity of OFPs increases the ability to manually perform acceptance test procedures (ATPs) decreases. The automated techniques capture data for input which reduces errors and the time to run through ATP and also freeing maintainers.
- Operational Test and Evaluation: The users approve the OFP after testing and evaluating it through their own check-out procedures which can include live firing of munitions, lock-on and destruction of drones, navigational exercises, etc. Here those errors are found which are not detected in simulation environment. It is the final test of a complete weapon system being fully integrated together and may involve several different OFPs.
- Developmental Test and Evaluation: Developmental test and evaluation provides OFP maintainers with the real environment which is more dynamic environment than the Avionics Integrated Support environment. An example of this is the recording of narrow band and wide band data in an air-to-air engagement scenario which can be analyzed for specific OFP performance parameters.
OFP testing issues can be summarized as related to architecture and processes, OFP change process, support environment, OFP testing and validation, user and maintainer interaction, breadth and depth of OFP testing and analysis and interpretation of test results.
Technology inserted to improve OFP testing and validation can be summarized as simulation environments, automation techniques, software integrated diagnostics, advanced VER and VAL, reusable libraries, hyper media, human factors, instrumentation, virtual reality and re-engineering.” (Charles P. Satterthwate, 1994)
Evolution of F-16 Aircraft
- “F-16 Light Weight Fighter: As early as 1965, the USAF had begun concept formulation studies of new high-performance fighters. These included the F-X, a heavy interceptor/air-superiority fighter, and the lightweight Advanced Day Fighter (ADF). The General Dynamics Model 401-16B and the Northrop P-600 were chosen for further development on April 13, 1972, and contracts for two YF-16s and two YF-17’s were awarded. Rather than the X experimental prefix being used, the Y development prefix was used in order to indicate that a mixture of off-the-shelf and experimental technologies were being used. The YF-16 was to be powered by a single Pratt & Whitney F100 turbofan, whereas the YF-17 was to be powered by a pair of General Electric YJ101 engines.
- Avionics were simple and armament consisted of one 20-mm M61A1 rotary cannon and two AIM-9 Sidewinder missiles on the wingtips, plus stores on two external hard points underneath each wing.
- YF-16 The Birth of a Fighter: The prototype YF-16 was rolled out at Fort Worth on December 13, 1973 and was air freighted by C-5A to Edwards AFB on January 8, 1974. Its first flight was an unintended short hop around the pattern on January 21, 1974 at the hands of test pilot Phil Oestricher. Within the Air Force staff, there was a strong institutional bias against the LWF, since they perceived it to be a threat to the F-15 program. To head off some of this suspicion, the program was renamed Air Combat Fighter (ACF) by the Defense Department.
- In October of 1974, Defense Secretary James R. Schlesinger announced that that he was considering production of the winner of the ACF contest to satisfy USAF, Navy, and export requirements. Up to that time, the LWF/ACF program had been largely an academic exercise for the USAF. On January 13, 1975, Air Force Secretary John McLucas announced that the YF-16 had been selected as the winner of the ACF contest. The Air Force placed a contract for fifteen FSD (Full-Scale Development) airframes. Both single- and two-seat versions would be built, with the single-seater being designated F-16A and the two-seater F-16B
- F-16A/B Block 1: The first F-16A Block 1, made its maiden flight in August 1978, and was delivered to the USAF in that same month. It was assigned to the 388th Tactical Fighter Wing at Hill AFB, Utah. A total of 94 Block 1 aircraft rolled off the production line at the Fort Worth facility; they were all delivered to the USAF.
- F-16A/B Block 5: Pilots flying the early Block 1 F-16A’s complained that the black radome stuck out like a sore thumb during simulated air-to-air combat and made it easy for the enemy to visually acquire the F-16. On Block 5, the gray radome was introduced, which became standard for all later Fighting Falcons. The Block 5 production batch totaled 197 aircraft.
- F-16A/B Block 10: 312 Block 10 aircraft were built through 1980. The F-16s still had the blade UHF aerial and small tail. Differences with Block 5 aircraft are again internal improvements with no apparent external modifications. 24 F-16A/B Block 10 aircraft from the Air National Guard NY were briefly modified to carry the GPU-5/A 30mm gun pod. After seeing limited service in Operation Desert Storm, they were converted back to ‘normal’ Block 10
- F-16A/B Block 15: In November 1981, the Block 15 introduced MSIP Stage I changes to the F-16A/B starting with sub block 15Y and continuing through sub block 15AZ. The changes expanded the F-16s growth potential by allowing improved capabilities in the air-to-ground and BVR missions. The AN/APG-66 radar on the Block 15 Fighting Falcons was provided with an early version of a track-while-scan mode for greater air defense capability. The F-16s were also equipped with Have Quick I secure UHF radios, and internal provisions for the AIM-7 were made. Additional structural strengthening was performed to allow an extra 1000 pounds of ordnance to be carried on the under wing points. Pilot comfort was enhanced by improving the cockpit air conditioning. The production run of the Block 15, saw 983 aircraft produced over a 14 year time-span, and took place on 3 production lines.
- F-16A/B Block 15OCU: 214 aircraft from Block 15Y onwards received upgraded systems starting late-1987. Designated Block 15OCU (Operational Capability Upgrade), these aircraft are powered by the more reliable F100-PW-220 turbofan. These aircraft also have structural strengthening and are provided with the enlarged HUD that was first introduced on the F-16C/D. Also incorporated are the capability to fire the Norwegian Penguin Mk.3 anti-shipping missile (built by Kongsberg, US designation AGM-119) and the AGM-65, provisions for the AIM-120 AMRAAM, radar altimeter, expanded computer capacity, data transfer unit, wide-angle HUD, AN/APX-101 IFF, Tracor AN/ALE-40 chaff/flare dispenser and provisions for the AN/ALQ-131 ECM pod. These modifications increased the max. TO weight to 37,500lbs (17,010kg). The first Block 15OCU was delivered in January 1988, and from 1988 onwards, all Block 15’s were built to OCU specifications.
- F-16A/B Block 20: The 150 F-16A/B Block 15OCU’s for Taiwan are built to MLU standards and are designated Block 20. The Block 20 designation was reserved in the 1980’s. It was later assigned to the Taiwanese aircraft and to the MLU program initiated to bring the European F-16s to an enhanced level, comparable with the block 50 F-16s of the USAF.” (F-16 versions)
F-16 Avionics and Structure
“The early versions of the F-16 Fighting Falcon were equipped with a comprehensive avionics suite, involving aWestinghouse AN/APG-66 pulse-Doppler fire-control radar, a Singer-Kearfott SKN-2400 INS, UHV/VHF comms suite, ILS, TACAN, a Dalmo Victor AN/ALR-69 RWR, GEC Marconi Avionics HUD and a Sperry central air data computer. The F-16A/B was initially powered by the F100-PW-200 turbofan, rated at 12,240 lb.s.t. dry, 14,670 lb.s.t. full military, and 23,830 lb.s.t. with afterburning. Production F-16s have the standard ACES II ejection seats.
Later, more advanced avionic packs were installed in these early production aircraft. These included upgraded AN/APG-66 radar sets, AN/ALR-74 RWR and F100-PW-220 engine with digital control interface.” ” (F-16 versions)
F-16 Modifications and Upgrades
“Pacer Loft I & II saw the Block 1 and 5 models upgraded to Block 10 standard.
Between late-1987 and late-1993, some USAF Block 10 and early Block 15 aircraft were upgraded to Block 15OCU standard. Between 1991 and 1996, earlier models of the F-16 with the -200 engines had them upgraded to -220E standard, providing capabilities and lifespan comparable to the Block 15OCU -220 engine.
From 1994, British Aerospace Systems & Equipment TERPROM (Terrain Profile Matching) software was installed in ANG and AFRES F-16s. TERPROM minimalizes the ground collision danger. In October 1986, the USAF decided that remaining F-16A’s would be modified as Air Defence Fighters (F-16 ADF) for the Air National Guard.
The four original European customers of the F-16 are now upgrading their F-16 Block 15’s in the MLU program, whilst several other countries are also considering this upgrade.
Other upgrades are provided by Israel and Singapore, who developed their own upgrade programs for earlier F-16 models. These upgrade programs are called respectively ‘ACE’ (Avionics Capabilities Enhancement) and ‘Falcon One’. So far, no customers are found for these two programs.
Since 1988, all Foreign Military Sales (FMS) aircraft received some features of the F-16C/D, including a RLG (Ring Laser Gyro)/INS, AN-ALR-69 RWR, the -220 engine and provisions for the AIM-9P-4 Sidewinder.” (F-16 versions)
Software Capabilities Updates
The project requirement document (PRD) of software capabilities updates (SCU) are prepared by the program core team of the F-16 modernization at Air Logistic Centre. It assigns roles and responsbilities and schedule timelines for the upgrade and modification of a set of OFPs. There are two such requirements SCU 7.1 and SCU 8.0 which can be reffered as our case study.
“The F-16 Software Team 501 ACSS/GFLA sought support for aiding them in fielding the SCU7.1 which included Commercial Fire Control Computer (CFCC), X-MUX BUS modification for the Commercial Central Interface Unit (CCIU), Advance Color Programmable Data Generator (ACPDG) and Programmable Singal Processor (PSP) for F-16C/D Block 25/30/32 aircraft. It defined the development and test requirements for the upgrades which includes CFCC and X-MUX program. This software update was provided to the field through the Software Control Center. CFCC and X-MUX software and hardware modificaiton were to be accomplished by a depot field team to all USAF F-16 Block 30/32 bases.
The primary capabilities improvement in SCU7.1 was W-MUX implementing using the X-MUX in the CCIU and a new CFCC hardware and software update, and 1m and 5m Controlled Image Base (CIB) satellite images in the Color Multifuction Display System (CMSDS), a software update for the PSP and other discretionary candidates.” (Janice Talmage, 2010)
“The F-16 Modernization Team 00-ALC/GHBPA, F-16 Programs Branch sought support for aiding them in fielding the Software Capacility Upgrade 8 (SCU8). This upgrade is applied to the F-16 C/D Block 25/30/32 aircraft. It defines 309 SMXG tasks required to accomplish development and test of the SCU8 program.
The avionics Line Replaceable Units (LRUs) required for SCU8 include: Head Up Display (HUD) Electronics Unit (EU), Fire Control Radar (FCR), Up Front Controls (UFC), and Commerical Central Interface Unit (CCIU).
The primary capability improvements in SCU8 are Helmet-Mounted Integrated Targeting (HMIT), Small Diameter Bomb (SDB), Center Display Unit (CDU), AIM-9X Full Digital Integration and Ethernet.” (Kristal Vaughan, 2010)
Budgets and Costs
The F-16 OFP’s budgets and costs are always very high as it involves not only lots of development of the design part but also various real time simulations and practical tests of weapons operations.
Since these are very classified information, the exact figures or schedules are never known. The unclassified information available for F-16 Squadrons shows cost and budget “in millions of US$ as 118.512 for the year 2010, 129.10 for the year 2011 and 143.869 for the year 2012.” (“Budget work,” 2011)
Delivery Schedules
The F-16 OFP’s delivery schedules are always very critical and long terms. The information is also generally very classified.
Software Project Management
Software project management describes tools for the efficient coordination and automation of different project management processes. Software project management typically provides comprehensive monitoring functionality, such as day-to-day reports of project development, scheduling and dependency trees, and system-generated warnings when schedules fall below pre-set tolerances. Some project management tools provide web-accessible applications such that workers can access programme functions specific to their needs, and flexibility that enable administrators to share resource pools without overbooking.
“The OFP project manager develops an internal management control system to produce cost, sechedule and control data. The data incorporate metrics for the tracking of both program cost and schedule based on the critical path.
The project schedule is graphed showing the current schedule variance and the running end of project schedule projection. Project costs are also graphed showing planned and actual cost as a function of time, current cost variance and the running end of the project cost projection. A cost control table shows project cost by Production Control Number which include budget, actural and variable cost for the current month, current fiscal year, cumulative from the beginning of the project and projected cost at completion.” (Janice Talmage, 2010)
Software Development Lifecycle
“Software development, just like most other activities, has a beginning, middle and an end. The end of one development activity is sometimes perceived as being linked to the beginning of a new development activity thus producing a cycle of beginning-middle-end, link, beginning-middle-end, link, and so forth. This view of software development is referred to as the software development life cycle.
There are many variations of the software development life cycle such as Water Fall Theme, Rapid Prototyping, The Spiral Model, Incremental Model, Rapid Application Development Model (RAD), Synchronize and Stabilize Model, Object-Oriented Lifecycle Model, Extreme Programming model, Fountain Model, and Rational Unified Process Model.” (Fakhar Lodhi, 2004)
Results
It can be observed from the information gathered that Operational Flight Programs are developed for the manufacturers of F-16 aircraft by the F-16 Modernization Department of US Air Force. The individual weapons or hardware used are made at multiple locations by various different manufacturers and their OFPs are written separately by them. The final test and evaluation of the aircraft is done by the ordering unit of the US Air Force squadron.
Discussions
The Operational Flights Programs and their upgrades are given to the contractors of US Defense Department. The Project Requirement Document (PRD) and the Software Capability Update (SCU) are prepared by the software engineer of F-16 Modernization department. The contractor develops and delivery the OFPs as per the PRD. The final test and evaluation of the OFPs are done by the users and the testing and evaluation team.
[/sociallocker]
References:
- Charles P. Satterthwate, Initials. AVIONICS DIRECTORATE, WRITH LABORATORY. (1994). Testing operational flight programs (WL-TR-94-1007). Avionics Logistics Branch, WL/AAAF Bldg 635: National Technical Information Service (NTIS).
- Fakhar Lodhi, (2004). Software enginneringII. Lahore: Virtual University of Pakistan Ltd.
- F-16 versions. (2011, 11 07). Retrieved from http://www.f-16.net/f-16_versions.html
- Janice Talmage, . HILL AIR FORCE BASE UTAH, OGDEN AIR LOGISTICS CENTER (AFMC). (2010). Project requirements document for software capabilities upgrade 7.1 (scu7.1) (SCU7.1 PRD 2Feb10 Rev06). UTAH, USA: F-16 501 ACSS/GFLA.
- Kristal Vaughan, . F-16 Modernization Section, F-16 Programs Branch. (2010). Software capability upgrade 9 (scu8) prd (SCU9 PRD 25Aug10 Rev 02 Final). UTAH, USA: OGDEN Air Logistics Center (OO-ALC).
- Research, Development, Test & Evalucation, Airforce, USA. (2011). Budget work (PE 0207133F)F-16 Squadrons.
[/sociallocker]
