Chapter 6. Air Traffic Control

1. Chapter 6. Air Traffic Control A Case Study in Designing for High Availability ZoltánTakács 2005

2. Initial Sector Suite System (ISSS) • next-generation Air traffic control (ATC) system for the United States • never put into operation because of budgetary constraints • implemented and demonstrated that the system could meet its quality goals

3. En route centers in the USA

4. Flying from point A to point B

5. An airline flight • communicates with ground control to taxi from the gate to the end of the runway • A’s tower during takeoff and climb-out • en route centers • B’s tower guides its approach and landing • ground control for its taxi to the gate after leaving the runway

6. Architecture Business Cycle (ABC) applied to the ATC system

7. the end users are federal air traffic controllers • the customer is the Federal Aviation Administration (controller of air traffic in the United States) • the developing organization is a large corporation that supplies many other important software-intensive systems

8. Requirements and Qualities • Air traffic control is highly visible, with huge amounts of commercial, government, and civilian interest. • It involves the potential loss of human life if it fails.

9. Two most important quality requirements

10. Ultrahigh availability • The actual availability requirement for ISSS is targeted at 0.99999. • The system should be unavailable for less than 5 minutes a year. • If the system is able to recover from a failure and resume operating within 10 seconds, that failure is not counted as unavailable time.

11. High performance • The system has to be able to process large numbers of aircraftwithout "losing" any of them. • Networks have to be able to carry the communication loads, • The software has to be able to perform its computations quickly and predictably.

12. In addition, The major drivers in the shape of the architecture • Openness: the system has to be able to incorporate commercially developed software components. • The ability to field subsets of the system, to handle the case in which the billion-dollar project falls victim to reductions in budget.

13. In addition, The major drivers in the shape of the architecture • The ability to make modifications to the functionality and handle upgrades in hardware and software. • The ability to operate with and interface to a set of external systems, both hardware and software, some decades old, others not yet implemented.

14. The scale of ISSS • Up to 210 consoles per en route center. • Each console contains its own IBM RS/6000 CPU. • To control from 400 to 2,440 aircraft tracks simultaneously.

15. The scale of ISSS • May be 16 to 40 radars. • A center may have from 60 to 90 control positions. • The code to implement ISSS contains about 1 million lines of Ada.

16. The ISSS system must do • Acquire radar target reports that are stored in an existing ATC system called the Host Computer System. • Convert the radar reports for display and broadcast them to all of the consoles. • Handle conflict alerts.

17. The ISSS system must do • Provide extensive monitoring and control information to allow site administrators to reconfigure the installation in real time. • Provide a recording capability for later playback. • Provide graphical user interface.

18. ISSS PHYSICAL VIEW

19. ISSS PHYSICAL VIEW • The Host Computer System is the heart of the en route automation system. • At each en route center there are two host computers. • The Host provides processing of both surveillance and flight plan data.

20. ISSS PHYSICAL VIEW • The air traffic controller's workstations. • They provide displays of aircraft position information. • Allow controllers to modify the flight data

21. ISSS PHYSICAL VIEW • The Local Communications Network. • Four parallel token ring networks for redundancy and for balancing. • One is a spare.

22. ISSS PHYSICAL VIEW • Provide connections between the networks. • Provide the ability to substitute the spare ring for a failed ring. • Make other alternative routings.

23. ISSS PHYSICAL VIEW • Each Host is interfaced to the LCN via dual LCN interface units. • Each one is a fault-tolerant redundant pair.

24. ISSS PHYSICAL VIEW • EDARC provides a backup display of aircraft position. • It is used in the event of a loss of the display data provided by the host. • Interfaces radar data to an ESI (External System Interface) processor.

25. ISSS PHYSICAL VIEW • The Backup Communications Network (BCN) is an Ethernet network using TCP/IP protocols. • It is used for the EDARC interface and as a backup network.

26. ISSS PHYSICAL VIEW • The Test and Training for testing new hardware and software and training users without interfering with the ATC mission. • Both the LCN and the BCN have associatedMonitor-and-Control consoles.

27. ISSS PHYSICAL VIEW • The central processors are mainframe-class processors that provide the data recording and playback functions.

28. MODULE DECOMPOSITION VIEW • The module elements are called Computer Software Configuration Items (CSCIs). • They are defined in the government software development standard. • Large teams are devoted to designing, building, and testing them.

29. Computer Software Configuration Items • Display Management, responsible for producing and maintaining displays on the common consoles. • Common System Services, responsible for providing utilities generally useful in air traffic control software-recall that the developer was planning to build other systems.

30. Computer Software Configuration Items • Recording, Analysis, and Playback, responsible for capturing ATC sessions for later analysis. • National Airspace System Modification, entailing a modification of the software that resides on the Host. • The IBM AIX operating system, providing the underlying operating system.

31. PROCESS VIEW • The basis of concurrency is implemented as an Ada "main" units called applications. • Applications communicate by message passing, which is the connector in this component-and-connector view. • Processors are logically combined to form a processor group. • Two types of applications.

32. Operational unit • One executing copy is primary called primary address space (PAS). • the others are secondary called standby address space (SAS). • The collection of one primary address space and its attendant standby address spaces is called an operational unit .

33. Functional groups • Functional groups are present on each processor as needed, with each copy a separate instance of the program, maintaining its own state.

34. PROCESS VIEW

35. Message receiving • When a functional group receives a message, it need only respond and update its own state as appropriate. • The PAS of an operational unit receives and responds to messages on behalf of the entire operational unit. It then must update both its own state and the state of its SASs.

36. In the event of a PAS failure • A SAS is promoted to the new PAS. • The new PAS reconstitutes with the clients of that operational unit. • A new SAS is started to replace the previous PAS. • The newly started SAS announces itself to the new PAS.

37. If failure is detected within a SAS • A new one is started on some other processor. • It coordinates with its PAS. • Starts receiving state data.

38. A new operational unit • Identify the necessary input data and output data to avoid deadlocks. • Identify internal state data that must be used for checkpointing. • Partition the state data into messages that fit well on the networks. • Etc.

39. Availability tactics • state resynchronization • shadowing • active redundancy • removal from service

40. CLIENT-SERVER VIEW

41. CODE VIEW • An Ada program is created from one or more source files. • It uses subprograms and packages. • The ISSS is composed of several programs. • An Ada program may contain one or more tasks.

42. CODE VIEW • Ada tasks are mapped onto UNIX (AIX) processes, which means that all of them are independent AIX processes. • Applications (i.e., operational units and functional groups) are decomposed into Ada packages. • It is carried out by an operational unit's chief designer.

43. An overlay of layers and a component-and-connector view

44. Within the AIX kernel's address space. • Written in the C language. • Faults can potentially damage AIX.

45. Outside the AIX kernel's address space. • Operating system extensions. • Faults cannot directly damage AIX.

46. The applications.

47. FAULT TOLERANCE • The fault-tolerant hierarchy is designed to trap and recover from errors. • Detects errors in self, peers, and lower levels. • Handles exceptions from lower levels. • Diagnoses, recovers, reports, or raises exceptions.

48. System monitor and control Global availability Group availability Local availability Application Runtime environment Operating system Physical

49. ADAPTATION DATA • Uses the modifiability tactic of configuration files called adaptation data. • User-or center-specific preferences. • Configuration changes. • Requirements changes. • Complicated mechanism to maintainers. • Increases the state space.

50. CODE TEMPLATES • The primary and secondary copies are never doing the same thing. • But they have the same source code. • Continuous loop that services incoming events. • Makes it simple to add new applications. • Coders and maintainers do not need to know about message-handling.