1

Air Traffic Control Case Study

CSSE 377 Software Architecture and Design 2Steve Chenoweth, Rose-Hulman InstituteTuesday, October 5, 2010

2

Today

Variety! Possible special guest – Tyler Gonnsen, X by 2 Air Traffic Control – this

• We’ll spend a bit of the hour on it

Leave time for finishing Project 3 if needed Thursday –

Special guest, Matt Ellis, Microsoft Intro to Testability (as time allows)

3

Acknowledgements

Some of the material in these slides is taken from Software Architecture in Practice, 2nd edition by Bass, Clements and Kazman.

Lecture created by Mark Ardis

4

Outline

Air Traffic Control Overview Advanced Automation System (AAS) Initial Sector Suite System (ISSS) Architectural Views

5

Air Traffic Control

Ground control movement on ground,

taxiing Tower control

takeoff/landing Terminal control

near airport En Route Center

regional

Image from travel.howstuffworks.com/air-traffic-control2.htm .

6

Cartoon of the Day

7

Advanced Automation System (AAS)

New version of all control systemsground control, tower control, terminal

control, en route centers Ultimately proved too ambitious Architecture and code kept for new

system, included parts of ISSSInvolved procurement from many

sources

Q 1

8

Initial Sector Suite System (ISSS) Acquire radar reports Convert radar reports for display Handle conflict alerts Provide network management Recording capability for later playback GUI with special safety requirements Provide reduced backup capability

(p. 135, slide 11)

Q 2

9

Requirements

Availability - ultrahigh: no more than 5 minutes downtime per year

Performance - high: up to 2440 active aircraft without losing them

Other qualities: Openness Subsets Ease of modification Many interfaces

10

Physical View (1/2)

2 Host Computer Systems (HCS) at each en route centerone as hot standby

Common Consoles Local Communication Network (LCN)

4 parallel token-ring networks, one is spare

LCN Interface Units (LIU)

Q 3

11

Physical View (2/2)

Enhanced Direct Access Radar Channel (EDARC)

Backup Communications Network (BCN)Ethernet using TCP/IP

Monitor-and-Control (M&C) consoles Test and Training - add new HW/SW

Q 2 - addendum

12

Module Decomposition View

5 main modules1. Display management

2. Common system services

3. Recording, analysis and playback

4. National Airspace System Modification system

5. IBM AIX operating system

Q 4

13

Process View

Functional Group - simple process Operational Unit - fault tolerant Primary Address Space (PAS) –

active Standby Address Space (SAS)

look for timeoutstake over as PAS as needed

(complicated algorithm)

Q 5

14

Client-Server View

PAS communicates with client/server PAS updates states of standby units

(SAS’s)

15

Another Cartoon of the Day!

16

Layered View

AIX does not have all services needed for fault tolerance

Kernel extensions run within AIX kernel's address spacewritten in Csmall, trusted

Rest written in Ada

Q 6

17

Fault Tolerance View

Describes recovery from errors due to cross-application interaction

Each level:detects errors in self, peers and lowerhandles exceptions from lowerdiagnoses, recovers, reports or raises

exceptionsstandard tactics are used

18

Adaptation Data

To achieve Modifiability Configuration files

site-specific changes"presets" for development and

deployment changescomplicates codecomplicates testing

19

Code Templates

Standard event-handler template for every application

Complicated fault tolerance algorithms encoded in templates

All applications share commonalities

Q 7

20

How it really turned out…

In just a few short years the FAA went from visions of glory to dunning their contractors –

”Nov 30, 1992: FAA gave a “cure notice” to IBM concerning its development of the Initial Sector Suite System (ISSS), a part of the Advanced Automation System (AAS). The agency stated that unless the company provided a plan to remedy deficiencies within 10 calendar days, the government would withhold progress payments under the contract. Earlier in November, IBM had stated that, because of software difficulties and other problems, the ISSS would not be ready for FAA acceptance until Sep 1994, thus adding another 14 months to an already delayed timetable. Following the cure notice, IBM submitted to FAA an initial and later a final cure plan. FAA’s own steps to remedy the situation included changes in the project’s management structure and an Apr 1 ban on further changes in user requirements for the ISSS. (See Oct 1, 1991, and Dec 13, 1993.)“

More, at http://gettheflick.blogspot.com/2007/11/faa-history-lesson-november-30.html.