1. Air Traffic Control COMP 529 Case Study Guy Lifshitz & Sevan Hanssian 1

2. 2 Outline

3. Overview 3 A flight progressing from departure airport to arrival airport deals with several ATC entities that guide it safely through each portion of the airways it is using: ground control coordinates movement of aircraft on the ground at an airport terminal control area towers control aircraft flying through the cylindrical section of airspace centered at an airport en route centers responsible for a section of the skies Initial Sector Suite System (ISSS): intended to be an upgraded hardware & software system for the 22 en route centers in the U.S.

4. 4

5. Sector suite: controllers that together control all of the aircraft in a particular sector of the en route center’s airspace Aircraft are handed off from center to center & from sector to sector within each center Sectors are defined in ways unique to each center: - may be defined to balance the load among center’s controllers - densely flown areas might have smaller sectors Each sector needs at least 2 controllers: radar controller monitors radar surveillance data, communicates with aircraft, maintains safe separations data controller retrieves info about each aircraft at the sector & sends it to radar controller 5 Description

6. 6 Broadly influenced by requirements of all the upgraded systems (not just ISSS-specific ones) The different systems share many elements: interfaces to radio systems interfaces to flight plan databases interfaces to each other interpreting radar data reliability requirements performance requirements Reusability (adopt common designs and elements) Design Influences

7. 7

8. hard real time timing deadlines must be met absolutely safety critical human lives at risk if system doesn’t perform correctly highly distributed many controllers cooperating to guide aircraft through the airways system 8 Application Demands

9. Ultrahigh availability the system cannot remain inoperative for longer than five minutes a year High performance the system has to be able to process as many as 2,440 aircrafts without losing any of them The system must be able to operate with & interface to a large set of external systems, from very old, to not-yet-implemented & more… 9 Requirements

10. The ISSS system must: acquire radar target reports stored in the Host Computer System convert reports for display & broadcast them to all the consoles - each console chooses the report it needs to display handle conflict alerts (potential aircraft collisions) or other transmitted data interface to the Host for input & retrieval of flight plans provide extensive monitoring & control info provide recording capability for later playback provide GUI facilities on the consoles provide reduced backup capability (in the event of a failure) 10 Tasks

11. ISSS Elements: Host Computer System provides processing of surveillance and flight plan data Local Communications Network (LCN) - each host is interfaced to the LCN via dual LCN interface units (LIU-H) which acts as a fault-tolerant redundant pair - is composed of 4 parallel token ring networks for redundancy & balance loading Common Consoles provide radar display, flight plan data display, & allow controllers to modify flight data & control info displayed & its format Backup Communications Network (BCN) Each common console is connected to both the LCN & the BCN, & multiple LCN access rings are used to support them all Physical View 11

12. ISSS Elements (cont’d): Enhanced Direct Access Radar Channel (EDARC) provides backup display of aircraft position and limited flight data block info to en route display consoles Associated Monitor-and-Control (M&C) Consoles for LCN & BCN that give control to system maintenance staff Test & Training subsystem provides capability to test new hardware & software & train users Central Processor mainframe-class processors that provide the data recordings & playback functions for the system 12 Physical View (2)

13. 13

14. 14 ISSS Module: Computer Software Configuration Items (CSCIs): correspond to work assignments form units of deliverable documentation & software contain small software elements grouped by a coherent theme/rationale Five CSCIs in ISSS: Display Management Common System Services Recording, Analysis and Playback National Air space System Modification IBM AIX operating system (as the underlying OS) Modifiability: semantic coherence for allocating responsibilities to each CSCI abstraction of common services anticipate expected changes, generalize module, maintain interface stability Module Decomposition View

15. 15 Concurrency in ISSS: Applications cooperating sequential processes implemented as an Ada main unit (process schedulable by OS) forms part of a CSCI Applications communicate by message passing (event connector) Fault tolerance & concurrency: processor groups responsible for hosting separate copies of 1 or more applications The different application copies can be: PAS: primary address space SAS: standby address space PAS sends state change notifications to each of its SASs SAS look out for timeouts or PAS failure so they can take over & become primary Process View

16. 16 Operational unit: collection of 1 PAS & its attendant SASs resides entirely within processors of a single processor group upon receiving a message, the PAS responds on behalf of the unit, & updates its own state & states of its SASs (more messages sent) Functional group: parts of ISSS not constructed as coexisting primary & standby versions run independently on different processors each copy is a separate instance of the program, maintains its own state upon receiving a message, needs to respond, update its own state Availability: state synchronization shadowing active redundancy removal from service Process View (2)

17. 17

18. 18 Applications are decomposed into Ada packages: some packages basic, include only type definitions some packages complex, reused across applications Packaging: abstraction information hiding Code View

19. 19 Applications interact in a client-server fashion: client of transaction sends the server a service request message server replies with an acknowledgement Clients and servers designed to have consistent interfaces, by using simple message-passing protocols for interaction Modifiability : maintaining interface stability component replacement adherence to defined protocols Client-Server View

20. 20

21. 21 Underlying layer: AIX, a commercial UNIX OS Additional system services software added for better fault-tolerance support Layers: AIX extensions small C programs running within kernel’s address space, but with limited exposure Atomic Broadcast Manager (ABM) for communication among Local Availability Manager modules within a sector suite Station Manager provides datagram services on LCN & serves as local representative of LCN network management services Layered View

22. 22 Layers (cont’d): Network Interface Sublayer Local Availability Manager application-level system service responsible for managing initiation, termination & availability of the application programs Connector? Internal Time Synchronization synchronizes the processor’s clock with that of the other ISSS processors (crucial) Layered View (2)

23. 23

24. 24 Cold system restart in the event of a failure was out of the question Immediate/rapid switchover to a component/standby ‘seemed the best approach’ Design to trap and recover from errors: Within a single application: PAS/SAS scheme Across applications: Fault-tolerant hierarchy Each level in the hierarchy asynchronously: detects errors in self, peers & lower levels - using ping/echo, or heartbeats handles exceptions from lower levels diagnoses, recovers, reports or raises exceptions Fault Tolerance View

25. 25

26. 26 What architecture style does the ISSS system’s overall architecture seem to resemble? What types of connectors seem the most prevalent? Which of the ‘views’ described in the case study are more intuitive (or less intuitive)? Do the elements, connectors, and other design decisions seem tied tightly to the requirements of the system? Do you agree that the ‘high availability’ constraint was the driving force behind most of the design decisions made for the ISSS? Evidence? Could there have been cheaper design decisions made (to keep the ISSS in the budget)? Discussion

27. 27