1 / 20

Air Traffic Control Case Study

Air Traffic Control Case Study. CSSE 377 Software Architecture and Design 2 Steve Chenoweth, Rose-Hulman Institute Tuesday, October 5, 2010. Today. Variety! Possible special guest – Tyler Gonnsen, X by 2 Air Traffic Control – this We’ll spend a bit of the hour on it

crowell
Download Presentation

Air Traffic Control Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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 • Involved 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 center • one 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 modules • Display management • Common system services • Recording, analysis and playback • National Airspace System Modification system • 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 timeouts • take 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 space • written in C • small, 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 lower • handles exceptions from lower • diagnoses, recovers, reports or raises exceptions • standard tactics are used

  18. Adaptation Data • To achieve Modifiability • Configuration files • site-specific changes • "presets" for development and deployment changes • complicates code • complicates 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.

More Related