Air Traffic Control

COMP 529 Case StudyGuy Lifshitz & Sevan Hanssian

1

2

Outline

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 controlcoordinates movement of aircraft on the ground at an airport

• terminal control areatowers control aircraft flying through the cylindrical section of airspace centered at an airport

• en route centersresponsible 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

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 controllermonitors radar surveillance data, communicates with aircraft, maintains safe separations• data controllerretrieves info about each aircraft at the sector & sends it to radar controller

5

Description

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

• hard real timetiming deadlines must be met absolutely

• safety criticalhuman lives at risk if system doesn’t perform correctly

• highly distributedmany controllers cooperating to guide aircraft through the airways system

8

Application Demands

Ultrahigh availabilitythe system cannot remain inoperative for longer than five minutes a year

High performancethe 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

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

ISSS Elements:

• Host Computer Systemprovides 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 Consolesprovide 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

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 Processormainframe-class processors that provide the data recordings & playback functions for the system

12

Physical View (2)

13

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 servicesanticipate expected changes, generalize module, maintain interface stability

Module Decomposition View

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 spaceSAS: standby address space

PAS sends state change notifications to each of its SASsSAS look out for timeouts or PAS failure so they can take over & become primary

Process View

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

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

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

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 Managerprovides datagram services on LCN & serves as local representative of LCN network management services

Layered View

22

Layers (cont’d):

• Network Interface Sublayer

• Local Availability Managerapplication-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

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 schemeAcross 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

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