The IBM 9020 was an IBM System/360 computer adapted into a multiprocessor system for use by the U.S. FAA for Air Traffic Control.[1] Systems were installed in the FAA's 20 en route Air Route Traffic Control Centers (ARTCCs), beginning in the late 1960s.[2]: 6 The U.K. CAA also installed a system in its London centre.[3] The IBM 9020A, for example, was based on the S/360-50 and the 9020D used two out of three or four S/360-65 processors for flight and radar data processing with two out of three S/360-50 processors providing input/output capability.[2]: 4–5
There were three operational variants of the 9020 system: 9020A CCC (Central Computer Complex); 9020D CCC; and 9020E DCC (Display Channel Complex). All the 9020A CCCs were attached to a non-IBM display complex, while the 9020D CCCs could be attached to either a non-IBM display complex or to the IBM 9020E DCC. The 9020A and 9020D CCCs carried out flight and radar data processing but needed an attached display complex to provide a plan view display (PVD) to the air traffic controllers. The non-IBM display complex was the Raytheon 730 Computer Display Channel (CDC) in the U.S. and the Plessey Processed Radar Display System (PRDS) in the U.K.[4] The Raytheon CDC could drive a maximum of 60 PVDs. The five ARTCCs that exceeded this requirement were equipped with the IBM DCC which could drive up to 90 PVDs.
Initially three 9020 CCC variants were proposed, with different flight plan (FP) capacities: 9020A max 325 FPs; 9020B max 200 FPs; and 9020C max 100 FPs. In the event, only the 9020A was delivered, plus the later 9020D with a 650 FP capacity.
Each FAA ARTCC had a System Maintenance Monitor Console (SMMC - not itself part of the 9020) that brought together the status indications of the installed 9020 system(s) as well as related components, such as environmental systems and communications links.
A maximum configuration CCC/DCC complex contained 12 IBM S/360 mainframes. Not all FAA ARTCCs, of which there were 20, had the maximum configuration. The U.K. centre had a 9020D "Triplex" system with six IBM S/360s (three S/360-65s and three S/360-50s).
In addition to the 21 ARTCCs there were four sites with variously configured non-operational systems: 9020A, 9020D and 9020E support and development systems at the FAA's NAFEC; 9020A and 9020E training systems at the FAA Academy; a simplex 9020D support system co-located with the CAA's operational triplex 9020D London system, and a 9020A at Raytheon for testing their display system.
Jacksonville ARTCC initially had a 9020A, which was replaced by a 9020D. The relocated 9020A remained at Jacksonville to become the hardware platform for the Central Flow Control Function within the FAA's Washington-based ATCSCC. It was renamed the Central Flow Control Computer and had a digital data link to the Washington command center. It was replaced by an IBM 4341 system in 1984.
On June 9, 1977, a treaty “IRAN - Aviation: Technical Assistance” [5] was signed between the FAA and the Civil Aviation Organization of Iran. Under the terms of the treaty the FAA would provide technical assistance to improve the Iranian National Airspace System. This assistance included the installation of a 9020D and 9020E and associated equipment at a cost of $29m (out of a total contract cost of $272m).[6] The treaty fell foul of the 1979 Iranian Islamic Revolution and the systems were never delivered.
| ARTCC | CCC | Display |
|---|---|---|
| Albuquerque | IBM 9020A | Raytheon 730 |
| Atlanta | IBM 9020D | Raytheon 730 |
| Boston | IBM 9020A | Raytheon 730 |
| Chicago | IBM 9020D | IBM 9020E |
| Cleveland | IBM 9020D | IBM 9020E |
| Denver | IBM 9020A | Raytheon 730 |
| Fort Worth | IBM 9020D | IBM 9020E |
| Houston | IBM 9020A | Raytheon 730 |
| Indianapolis | IBM 9020D | Raytheon 730 |
| Jacksonville | IBM 9020D | Raytheon 730 |
| Kansas City | IBM 9020D | Raytheon 730 |
| Los Angeles | IBM 9020D | Raytheon 730 |
| Memphis | IBM 9020A | Raytheon 730 |
| Miami | IBM 9020A | Raytheon 730 |
| Minneapolis | IBM 9020A | Raytheon 730 |
| New York City | IBM 9020D | IBM 9020E |
| Oakland | IBM 9020A | Raytheon 730 |
| Salt Lake City | IBM 9020A | Raytheon 730 |
| Seattle | IBM 9020A | Raytheon 730 |
| Washington DC | IBM 9020D | IBM 9020E |
| London (United Kingdom) | IBM 9020D | Plessey PRDS |
Longevity and follow-on systems
editThe 9020As and 9020Ds were in service in North America until 1989 when they were finally replaced by IBM 3083 BX1 mainframes as part of the FAA's HOST Computer System (HCS) upgrade.[7][8] The 3083s in turn were replaced with IBM 9672 RA4 parallel processing servers during the FAA's Host and Oceanic Computer System Replacement (HOCSR) completed in 1999. One reason for the 1999 upgrade was concern, probably unfounded, that the IBM 3083's microcode would not operate properly in the year 2000.[8] At least during the first phase of the upgrade, the 9672s were running the FAA's original assembly language code in System/360 emulation mode. Because of the failure of the FAA's Advanced Automation System (AAS) project, the 9020E Display Channel Complexes lasted well into the 1990s.
NATS in the UK had a 9020D system in service running NAS from 1974 to 1990, at which time NAS was rehosted on to an IBM 4381 system. This system was known as the Host Computer System (HCS), and it retained the System/360 technology Peripheral Adapter Modules (PAMs) from the 9020D. The three PAMs (IBM 7289s) were switched off for the last time 27 November 1997 when their replacement (SPRINT) came into service.
The IBM 9020D system was operational at the London Air Traffic Control Centre, RAF West Drayton, from 1974 to 1990 supporting the UK Air Traffic Controllers.
Originally developed for the American Federal Aviation Administration, the 9020 consisted of a number of IBM S/360 processors in a multi-processing configuration.
There were several variants of the 9020, but the UK had a 9020D Triplex consisting of three S/360 Model65 and three S/360 Model 50 processors with shared discs, tapes, printer and Card Reader Punch.
Three of the processors were Compute Elements (CE) and three were Input Output Compute Elements (IOCE). An operational system was 2 CEs and 2 IOCEs. All processors ran the National Airspace System (NAS) Software. The IOCEs handled all the input output channel programmes and processed radar data.
The CEs ran the Flight Data processing software in a real-time, multiprocessor environment.
The third CE and IOCE provided backup in case of a hardware error and they would be automatically switched into the configuration upon failure of the online system.
A simplex system of one CE and one IOCE (and peripherals) provided a test and development environment
The NAS Software ran in 2.5Mb of memory with a couple of spare storage elements which were switched in automatically in the event of a storage check.
The application software ran on a modified version of OS/360 as an embedded Operating System known as the “Monitor”. The monitor provided communications, storage management, timing, scheduling and recording services.
The Air Traffic Control Software, Known as NAS in the UK had five primary operational functions:
(in the US, NAS refers to the Whole Air Traffic System - National Airspace System)
1) ROUTE PROCESSING - Convert a flight plan into a series of fixes. For each fix, determine what time the flight will arrive, at which height it will be and determine which air traffic control team (Sector) are responsible for that geographical space.
2) STRIP POSTING – At a parameter time before the flight is due in the sector, print a flight strip with the aircraft information to allow the air traffic controllers to identify flights that are planned to be in the same place, at the same height at the same time so they can be safely separated.
3) RADAR PROCESSINIG - Convert range and bearing radar data from 10 different radars into an [x,y] coordinate on the system plane. Stereographic projection converts the data to a flat-earth model with the point of tangency (where the flat plane meets the round earth) near to Oxford. For each 16 mile square there was a preferred, secondary and tertiary radar source. If available, the preferred source would always be used for the conversion with the secondary and tertiary sources being used if the preferred radar was not available. This gave the controllers the best possible radar coverage in a mosaic. The [x,y] data was sent on to a Plessey radar display system.
4) CORRELATION – by matching the radar beacon codes transmitted by an aircraft and by looking for the right flight in the right place at about the right time, the radar and flight plan data could be correlated and the flight tracked. This allowed the flight strip data presented to the air traffic controllers to be updated with actual times. If the flight was ahead or behind of schedule a time-update could be sent to the controllers.
5) CO-ORDINATION – Interfaces to adjacent countries allowed flights to be electronically passed between the country’s airspace. The simple protocol said “This flight, will be at this location, at this height, at this time.” If there was no rejection within 60 seconds, the flight was deemed to be handed over.
The NAS software records the flight plan database to disk every 30 seconds. In the event of a failure, the system will perform a STARTOVER. This involves dumping the contents of memory to disk and tape for offline analysis of the failure, reloading all of the software from disk and reconstituting the flight plan database from the latest recovery recording. A startover takes between 2 and 10 seconds.
Later in its life NAS Terminator processing was added to detect if the same flight causes two startovers in a parameter time. In this case, the flight plan is quarantined as “Potentially bad” and it is removed from the database.
The NAS Software suite included a wide range of build, debug, analysis, test and patching software.
The NAS software is written in BAL for the MONITOR and JOVIAL for the ATC Applications. JOVIAL is particularly well suited to managing tables and linked lists which are used extensively in the system. The support tools, assemblers and compilers all run on MVT/MVS which shares its roots with OS/360.
To save system resources at run time, the geographic database of the UK airspace and the addresses of all of the peripherals are pre-processed, sorted and linked into a pre-populated database by an offline build tool which is attached to the Applications and Monitor at system build time.
In the late 1980s, the UK 9020D gained an unhelpful reputation for becoming unreliable after two failures in a single year. The failures were actually in the 60Hz UPS systems that provided power but the 9020 was condemned. Only at decommissioning did it become apparent that the system could have run on 50Hz with a slightly slower cooling fan speed.
In 1990, the NAS software was rehosted onto System 370, 4381 processors with 3380 DASD and 3480 tapes. The software configuration was changed to main and standby with a heartbeat between the two processors. If the Standby processor fails to receive a heartbeat in a parameter time, it promotes itself to Main, switches all of the peripherals to itself and performs a startover to rebuild the flight plan database. The system is no longer multi-processing.
Sources
edit- "IBM FAA 360/65-9020 display". Stanford University Computer History museum. Retrieved June 2, 2010. pictures of 9020E being recycled
- "Switches go to 'off' to mark the end of an era". UK Civil Aviation Authority staff newspaper. 29 December 2012. Article about the PAM final switch-off
References
edit- ^ IBM Systems Journal, Volume 6, Issue 2, 1967.
- ^ a b Broadley, William; Freeman, Harvey; Oiesen, James; Rutledge, Ronald; Thurber, Kenneth (September 1981). An Analysis of Selected Enhancements to The En Route Central Computing Complex (PDF) (Technical report). FAA-EM-81-18. Archived (PDF) from the original on February 27, 2022.
- ^ Gibson, Gary (July 15, 2020). "The greatest innovations in the history of Air Traffic Control: Flight Data Processing". NATS.
{{cite web}}: CS1 maint: url-status (link) - ^ Hewish, Mark (July 17, 1980). "No flies on Britain's air-traffic control system". New Scientist. p. 190.
- ^ IRAN - Aviation: Technical Assistance
- ^ 1975 Iranian National Airspace System Study Report
- ^ "Advanced Automation Program HOST Computer System Acquisition Phase Acceptance Test Report" (PDF). August 1987.
- ^ a b "Air Traffic Control: FAA Plans to Replace Its Host Computer System Because Future Availability Cannot Be Assured" (PDF). May 1, 1998.