Upload
augusta-foster
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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