Transcript Introduction - Rose

Air Traffic Control
Case Study
CSSE 377 Software Architecture and Design 2
Steve Chenoweth, Rose-Hulman Institute
Tuesday, October 5, 2010
1
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 –


2
Special guest, Matt Ellis, Microsoft
Intro to Testability (as time allows)
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
3
Outline
Air Traffic Control Overview
 Advanced Automation System (AAS)
 Initial Sector Suite System (ISSS)
 Architectural Views

4
Air Traffic Control

Ground control


Tower control


takeoff/landing
Terminal control


movement on ground,
taxiing
near airport
En Route Center

regional
5
Image from travel.howstuffworks.com/air-traffic-control2.htm .
Cartoon of the Day
6
Advanced Automation
System (AAS)

New version of all control systems

ground control, tower control, terminal
control, en route centers
Ultimately proved too ambitious
 Architecture and code kept for new
system, included parts of ISSS


7
Involved procurement from many
sources
Q1
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)

8
Q2
Requirements



Availability - ultrahigh: no more than 5
minutes downtime per year
Performance - high: up to 2440 active
aircraft without losing them
Other qualities:




9
Openness
Subsets
Ease of modification
Many interfaces
Physical View (1/2)

2 Host Computer Systems (HCS) at
each en route center

one as hot standby
Common Consoles
 Local Communication Network (LCN)



10
4 parallel token-ring networks, one is
spare
LCN Interface Units (LIU)
Q3
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

11
Q 2 - addendum
Module Decomposition View

5 main modules
1.
2.
3.
4.
5.
12
Display management
Common system services
Recording, analysis and playback
National Airspace System
Modification system
IBM AIX operating system
Q4
Process View
Functional Group - simple process
 Operational Unit - fault tolerant
 Primary Address Space (PAS) –
active
 Standby Address Space (SAS)

look for timeouts
 take over as PAS as needed
(complicated algorithm)

13
Q5
Client-Server View
PAS communicates with client/server
 PAS updates states of standby units
(SAS’s)

14
Another Cartoon of the Day!
15
Layered View
AIX does not have all services needed
for fault tolerance
 Kernel extensions run within AIX
kernel's address space

written in C
 small, trusted


16
Rest written in Ada
Q6
Fault Tolerance View
Describes recovery from errors due to
cross-application interaction
 Each level:

detects errors in self, peers and lower
 handles exceptions from lower
 diagnoses, recovers, reports or raises
exceptions
 standard tactics are used

17
Adaptation Data
To achieve Modifiability
 Configuration files

site-specific changes
 "presets" for development and
deployment changes
 complicates code
 complicates testing

18
Code Templates
Standard event-handler template for
every application
 Complicated fault tolerance algorithms
encoded in templates
 All applications share commonalities

19
Q7
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.)“
20
More, at http://gettheflick.blogspot.com/2007/11/faa-history-lesson-november-30.html.