1. Software System Architecture Software System Architecture Chapter 6:Air Traffic Control: A Case Study in Designing for High Availability. Chapter 6:Air Traffic Control: A Case Study in Designing for High Availability. Prepared by : Azmi H. Alsaqqa 420050007 Prepared by : Azmi H. Alsaqqa 420050007 Supervised by: Eng. Tasnim Darwish Supervised by: Eng. Tasnim Darwish 2010 2010 1

2. 2 CODE VIEW An Ada program is created from one or more source files. An Ada program is created from one or more source files. It uses subprograms and packages. It uses subprograms and packages. The ISSS is composed of several programs. The ISSS is composed of several programs. An Ada program may contain one or more tasks. An Ada program may contain one or more tasks.

3. 3 CODE VIEW Ada tasks are mapped onto UNIX (AIX) processes, which means that all of them are independent AIX processes. Ada tasks are mapped onto UNIX (AIX) processes, which means that all of them are independent AIX processes. Applications (i.e., operational units and functional groups) are decomposed into Ada packages. Applications (i.e., operational units and functional groups) are decomposed into Ada packages. It is carried out by an operational unit's chief designer. It is carried out by an operational unit's chief designer.

4. 4 An overlay of layers and a component-and-connector view

5. 5  Within the AIX kernel's address space.  Written in the C language.  Faults can potentially damage AIX.

6. 6  Outside the AIX kernel's address space.  Operating system extensions.  Faults cannot directly damage AIX.

7. 7  The applications.

8. 8 FAULT TOLERANCE The fault-tolerant hierarchy is designed to trap and recover from errors. The fault-tolerant hierarchy is designed to trap and recover from errors. Detects errors in self, peers, and lower levels. Detects errors in self, peers, and lower levels. Handles exceptions from lower levels. Handles exceptions from lower levels. Diagnoses, recovers, reports, or raises exceptions. Diagnoses, recovers, reports, or raises exceptions.

9. 9 Physical Operating system Runtime environment Application Local availability Group availability Global availability System monitor and control

10. 10 ADAPTATION DATA Uses the modifiability tactic of configuration files called adaptation data. Uses the modifiability tactic of configuration files called adaptation data. User-or center-specific preferences. User-or center-specific preferences. Configuration changes. Configuration changes. Requirements changes. Requirements changes. Complicated mechanism to maintainers. Complicated mechanism to maintainers. Increases the state space. Increases the state space.

11. 11 CODE TEMPLATES The primary and secondary copies are never doing the same thing. The primary and secondary copies are never doing the same thing. But they have the same source code. But they have the same source code. Continuous loop that services incoming events. Continuous loop that services incoming events. Makes it simple to add new applications. Makes it simple to add new applications. Coders and maintainers do not need to know about message-handling. Coders and maintainers do not need to know about message-handling.

12. 12 Tactics Code templates represent a refinement of the "abstract common services" tactic. Code templates represent a refinement of the "abstract common services" tactic. Gives the processes a "semantic coherence”, because they all do the same thing when viewed abstractly. Gives the processes a "semantic coherence”, because they all do the same thing when viewed abstractly. The template leading to "generalizing the module”. The template leading to "generalizing the module”. By making the interfaces and protocols part of the template, they "maintain interface stability" and achieve "adherence to defined protocols." By making the interfaces and protocols part of the template, they "maintain interface stability" and achieve "adherence to defined protocols."

13. 13 terminate:= false initialize application/application protocols ask for current state (image request) Loop Get_event Get_event Case Event_Type is Case Event_Type is -- "normal" (non-fault-tolerant-related) requests to perform actions; -- "normal" (non-fault-tolerant-related) requests to perform actions; -- only happens if this unit is the current primary address space -- only happens if this unit is the current primary address space when X=> Process X when X=> Process X Send state data updates to other address spaces Send state data updates to other address spaces when Y=>Process Y when Y=>Process Y Send state data updates to other address spaces Send state data updates to other address spaces...... when Terminate_Directive => clean up resources; terminate := true when Terminate_Directive => clean up resources; terminate := true Code structure template for fault-tolerant ISSS applications

14. 14 when State_Data_Update => apply to state data -- will only happen if this unit is a secondary address space, receiving -- will only happen if this unit is a secondary address space, receiving -- the update from the primary after it has completed a "normal" action -- the update from the primary after it has completed a "normal" action -- sending, receiving state data -- sending, receiving state data when Image_Request => send current state data to new address space when Image_Request => send current state data to new address space when State_Data_Image => Initialize state data when State_Data_Image => Initialize state data when Switch_Directive => notify service packages of change in rank when Switch_Directive => notify service packages of change in rank -- these are requests that come in after a PAS/SAS switchover; they -- these are requests that come in after a PAS/SAS switchover; they -- report services that they had requested from the old (failed) PAS -- report services that they had requested from the old (failed) PAS -- which this unit (now the PAS) must complete. A,B, etc. are the names -- which this unit (now the PAS) must complete. A,B, etc. are the names -- of the clients. -- of the clients. when Recon_from_A=>reconstitute A when Recon_from_A=>reconstitute A when Recon_from_B=>reconstitute B when Recon_from_B=>reconstitute B...... when others=>log error when others=>log error end case end case exit when terminate end loop

15. 15 How the ATC System Achieves Its Quality Goals Goal: High Availability Goal: High Availability How Achieved: Hardware redundancy, software redundancy How Achieved: Hardware redundancy, software redundancy Tactic(s) Used: State resynchronization; shadowing; active redundancy; removal from service; limit exposure; ping/echo; heartbeat; exception; spare Tactic(s) Used: State resynchronization; shadowing; active redundancy; removal from service; limit exposure; ping/echo; heartbeat; exception; spare

16. 16 How the ATC System Achieves Its Quality Goals Goal: High Performance Goal: High Performance How Achieved: Distributed multiprocessors; front-end schedulability analysis, and network modeling How Achieved: Distributed multiprocessors; front-end schedulability analysis, and network modeling Tactic(s) Used: Introduce concurrency Tactic(s) Used: Introduce concurrency

17. 17 How the ATC System Achieves Its Quality Goals Goal: Openness Goal: Openness How Achieved: Interface wrapping and layering How Achieved: Interface wrapping and layering Tactic(s) Used: Abstract common services; maintain interface stability Tactic(s) Used: Abstract common services; maintain interface stability

18. 18 How the ATC System Achieves Its Quality Goals Goal: Modifiability Goal: Modifiability How Achieved: Templates and adaptation data; module responsbilities; specified interfaces How Achieved: Templates and adaptation data; module responsbilities; specified interfaces Tactic(s) Used: Abstract common services; semantic coherence; maintain interface stability; anticipate expected changes; generalize the module; component replacement; adherence to defined procotols; configuration files Tactic(s) Used: Abstract common services; semantic coherence; maintain interface stability; anticipate expected changes; generalize the module; component replacement; adherence to defined procotols; configuration files

19. 19 How the ATC System Achieves Its Quality Goals Goal: Ability to Field Subsets Goal: Ability to Field Subsets How Achieved: Appropriate separation of concerns How Achieved: Appropriate separation of concerns Tactic(s) Used: Abstract common services Tactic(s) Used: Abstract common services

20. 20 How the ATC System Achieves Its Quality Goals Goal: Interoperability Goal: Interoperability How Achieved: Client-server division of functionality and message-based communications How Achieved: Client-server division of functionality and message-based communications Tactic(s) Used: Adherence to defined protocols; maintain interface stability Tactic(s) Used: Adherence to defined protocols; maintain interface stability