SAP Cross-Connector Software Architecture

Transcription

1 Course: Ingegneria del Software II academic year: Course Web-site: [ Lecture 5: The SXA Telecommunication System Software Architecture [TR 06/01] Lecturer: Henry Muccini and Vittorio Cortellessa Computer Science Department University of L'Aquila -Italy [ [

2 Copyright Notice» The material in these slides may be freely reproduced and distributed, partially or totally, as far as an explicit reference or acknowledge to the material author is preserved. Henry Muccini 2

3 Acknowledgment» This presentation comes from: - [TR 16/01] Luca Marcucci, Paola Inverardi, Henry Muccini. Formal and Semi-formal descriptions of a Cross-Connector Software Architecture. Internal Report 16/01, Universita' dell'aquila 3

4 General Context» Telecom Italia Network Architecture: - 3 layers: > urban > regional and > national telephone exchange» System behavior: - When a customer makes a call, his call is routed through a local network. - If the call is local, then the customer is connected to the local number 4 - If the call is not local, then the system routes the call to regional or national routers and finally to the final number

5 TELECOM ITALIA NETWORK ARCHITECTURE ADM ADM ADM ADM ADM ADM WL WL WDM WL WL ADM ADM STM-16 Ring STM-16 Ring ADM ADM National Level ADM ADM ADM ADM SXA SXA STM-4/16 SXC SXA SXC SXA 4/1 4/1 STM-4/16 SXA SXA Regional level STM-4/16 STM-1/4 Urban Level STM-1/4 STM-1/4 5

6 Simplified view National Router» Telecom Italia Network Architectural style Regional Router Regional R. Urban Router Urban R. Urban R 6 There is a (possible) error in this architecture. Can you find it?

7 Dynamics: phone call Irvine San Francisco Culver R Irvine R. S. F. Call Local? No 7

8 Our Context» The SXA subsystem» Our aim: SXA SXA National Level STM-4/16 Regional level SXC SXA SXC SXA 4/1 STM-4/16 SXA SXA 4/1 - The study of the SXA Cross Connector, in order to... - develop a formal or semi-formal architectural specification to realize quantitative analysis (explain) > The experimentation of different formalisms to describe this SA (UML, ADL, Process Algebra) > The elicitation and organization of the information necessary to build a performance model 8

9 What Siemens provided» A good physical (Hw) architectural description» An incomplete, only statical, description of the SXA Software Architecture - Components and Connectors - Deployment Software components in Hw nodes» The system dynamics and configuration is described only at the low-level, using a SDL-like notation 9

10 What Siemens provided» How did they evaluate the system performance before? - They modify the code and evaluate its execution time and resource consuming» How do they want to evaluate the system performance? - Modifying the architectural model and evaluating the architectural changes fast and cheap 10

11 What Siemens provided» 8 different manuals, each one of about 200 pages (at least they documented the system)» The possibility to contact the people responsible of the SXA development and documentation» The SDL specification and code of the system 11

12 SXA Cross-Connector (1)» The SXA is a cross-connector with a transmissivecapacity of 140 Mbit.» Its main behavior is to enable a cross-connection between networks nodes» One of its basic features is the possibility to monitor traffic for an automatic protection switching activation (fault management) or for dynamic reconfiguration (e.g., work balancing) (explain)» The SXAs are parts of the regional TIN layer and they enable the setting up of mesh networks composed of interconnected, different layers, ring networks. 12

13 SXA Cross-Connector (2)» In the available documentation, the SXA architecture is described by three different configurations or views: - The Software configuration: it represents the functional view. The software components are identified, and their behaviors are described; - the Hardware configuration: the system is represented by the hardware devices composing it; - the Deployment configuration: it represents a mapping between the software components and the hardware devices. 13

14 » 1. Software Configuration» 2. Hardware Configuration» 3. Deployment Configuration 14

15 1. SXA System Software Configuration NETWORK MANAGER OSI STACK COMMAND HANDLER DATABASE MANAGER SUPER- USER TERMINAL SYSTEM FUNCTION Database MIB XCONN 15

16 The SXA Software Configuration (1) 1. Super-User Terminals can locally or remotely be connected to the SXA system to handle system services; they can add or remove connections and manage the software and hardware system configuration. The terminals are bidirectionally connected to the system by an OSI Stack; 2. the Command Handler translates Users commands into system function calls; it is also connected to a global database; 3. The user-to-system communication is implemented by a complete OSI Stack 4. the MIB Global Database stores the external requests and the component software and hardware configuration; 16

17 The SXA Software Configuration (2) 5. the System Functions represent the software components implementing the Users requests. Each component has its own behavior: - CM manage the system configuration, - EPS manage the equipment protection resources, SYSTEM FUNCTION - FM provides fault detection and alarm generation, - PM evaluates the performance of transmission links, XCONN - LPS handles the line protection switching, - TIM manages the network synchronization, - DR performs the initializations in the system during power-up and restart and - TM organizes the execution of all the tests which are defined in the system. - XCONN is the core of the system; it manages the activities related to the routing, setting up point-to-point and broadcast cross-connections. 17

18 The SXA Software Configuration (3) - Terminology: >macro-components - the five components just shown > micro-components - their sub-components (i.e., each macrocomponent is composed by several microcomponents). 18

19 Macro and Micro components <<SYSTEM FUNCTION>> LPS CMDH <<SYSTEM FUNCTION>> XCONN <<XCONN component>> GXC <<SYSTEM FUNCTION>> XCONN Refinement 1..2 <<XCONN component>> CXC <<XCONN component>> SSXC» Macro Component» Micro Components NOTE: every connection at the macro-component level has to be mapped into a connection at the by H. micro-component Muccini and V. Cortellessa level / Ingegneria del Software II

20 2. SXA System Hardware Configuration, v1 ES-CORE Protection ES-CORE Working C-CORE T-MUX # 1 ET-MUX # 1 T-MUX16 # 1 20 T-MUX # n < 30 ET-MUX # n < 16 T-MUX16 # n < 8

21 Hardware Configuration In the hardware configuration the SXA system is described by means of the hardware devices composing it; the distributed system elements (shelves) are:» the T-MUX, ET-MUX and T-MUX16 contain the system ports and contain also part of the cross-connect processing. - Depending on the switching capability, there are multiple instances of these shelves: in the more complex case, there are 29 T-MUX, 15 ET-MUX and 7 T- MUX16;» the C-CORE contains the main controller;» the ES-CORE contains the central part of the cross-connect processing and the system timing synchronization function;» The ES-CORE is duplicated (protection and working) for the hardware faults management. 21

22 SXA System Hardware Configuration, v2 ES-CORE Protection ES-CORE Working. C-CORE GLOBAL SHELF C-LAN PERIPHERAL SC-LAN 22 T-MUX # 1 T-MUX # n < 30 ET-MUX # 1 ET-MUX # n < 16 T-MUX16 # 1 T-MUX16 # n < 8 SC-LAN

23 Hardware Layers» All shelves are connected via an external lan (C-LAN).» In each shelf more processors can be located, connected by a local lan (SC- LAN);» the processors are organized in a hierarchical manner and are partitioned into three levels: global, shelf and peripheral.» Global processors are located in the C-CORE; they are devoted to the system management;» Shelf processors are located in each shelf; they are devoted to the shelf management;» Peripheral are located in each shelf; they are devoted to specialized functionalities. 23

24 SXA System Hardware Configuration, v2 - VIEWS ES-CORE Protection ES-CORE Working. Timing 8 ETMSU PSCU C-CORE MSCU LAN HUB MSCU GLOBAL SHELF C-LAN PERIPHERAL 2 TSU PSCU 2 TSU PSCU 2 TSU PSCU TDU DPS TDU DPS Porte Fisiche ASU Porte Fisiche ASU Porte Fisiche ASU TDU 24 T-MUX # 1 T-MUX # n < 30 ET-MUX # 1 ET-MUX # n < 16 T-MUX16 # 1 T-MUX16 # n < 8

25 SXA System Hardware Configuration, v2 - FLOW ES-CORE Protection ES-CORE Working. Timing 8 ETMSU PSCU C-CORE MSCU LAN HUB MSCU GLOBAL SHELF C-LAN PERIPHERAL 2 TSU PSCU 2 TSU PSCU 2 TSU PSCU TDU DPS TDU DPS Porte Fisiche ASU Porte Fisiche ASU Porte Fisiche ASU TDU 25 T-MUX # 1 T-MUX # n < 30 ET-MUX # 1 ET-MUX # n < 16 T-MUX16 # 1 T-MUX16 # n < 8

26 3. Deployment Configuration» In the deployment configuration each SXA macro-component is decomposed in several micro-components;» each micro-component is implemented by a process running in global, shelf or peripheral processors;» Each macro-component could be composed of several instances of its micro-components. 26

27 Software and Hardware ES-CORE ES-CORE Protection. Working C-CORE GLOBAL SHELF SYSTEM FUNCTION??? C-LAN PERIPHE RAL XCONN SC- LAN 27 T- ET- MUX MUX # 1 # 1 T- ET-MUX MUX # n < 16 # n<30 T- MUX16 # 1 T- MUX16 # n < 8 SC- LAN

28 For each component XCONN GLOBAL SHELF XCONN XCONN1 PERIPHE RAL XCONN XCONN2 XCONN2 XCONN3 XCONN3 28

29 Components Deployment ES-CORE Protection ES-CORE. Working PSCU runs XCONN2 C-LAN C-CORE MSCU runs XCONN1 XCONN XCONN1 PSCU runs XCONN2 runs XCONN3 GLOBAL SHELF PERIPHERAL 1..2 XCONN2 XCONN3 29 ET-MUX # 1

30 Summarizing» Software: - each component, is composed in sub-components» Hardware: - Three layers: global, shelf and peripheral» Deployment: - each software sub-component deployed in one layer 30 - SXA Architecture

31 The Approach 31

32 Our Research» Our aim: - The study of the SXA Cross Connector, in order to... - develop a formal or semi-formal architectural specification to realize quantitative analysis (explain)» What we did: - A Reverse Engineering approach to analyze the existent documentation and produce an architectural description. 32

33 REVERSE ENGINEERING PROCESS System Domain Analysis Domain Analysis of the XCONN System Function Architectural Description Functional Partition 33

34 1. System Domain Analysis 1.System Domain Analysis High-Level Components Documentation 2. Domain Analysis of XCONN Meeting with the developers System Domain Analysis High-Level High-Level Class Class and and Sequence Sequence Diagram Diagram (UML) (UML) 3.Architectural Description 4.Functional Partition 34

35 SXA Class Diagram (Macro-Component Level) DATABASE MANAGER <<SYSTEM FUNCTION>> LPS CMDH <<SYSTEM FUNCTION>> XCONN <<SYSTEM FUNCTION>> EPS <<SYSTEM FUNCTION>> CM <<SYSTEM FUNCTION>> FM 35

36 Step1: encountered problems» Macro-components level description is too abstract for quantitative analysis» Sequence diagrams are not enough informative» Solution: - Analyze only the SXA main component in detail: the XCONN component - Analyze how XCONN sub-components interact 36

37 2. Domain Analysis of XCONN 1.System Domain Analysis Previous Step Results 2. Domain Analysis of XCONN 3.Architectural Description Components Detailed Documentation Domain Analysis of the XCONN System Function Exchanged Exchanged messages messages list list Stereotyped Stereotyped class class diagram diagram (UML) (UML) Deployment Deployment Diagram Diagram (UML) (UML) 4.Functional Partition 37

38 PREVIOUS ARCHITECTURE <<component>> Element Manager <<component>> CMDH <<component>> EPS <<component>> FM <<XCONN component>> GXC 1..2 <<component>> CM ALL macro components <<XCONN component>> CXC XCONN <<XCONN component>> 1..* SSXC <<XCONN component>> BXC <<XCONN component>> PSXC 1..* <<XCONN component>> STXC 1..* 1..* <<XCONN component>> TXC <<component>> LPS 1..* 1..2 <<XCONN component>> PTXC 38

39 UML Class Diagram XCONN SYSTEM FUNCTION macro components <<component>> Element Manager <<component>> FM <<component>> CMDH <<XCONN component>> GXC 1..2 <<component>> CM <<component>> EPS macro components micro components <<XCONN component>> CXC <<XCONN component>> 1..* SSXC <<XCONN component>> BXC <<XCONN component>> PSXC <<XCONN component>> STXC 1..* 1..* 1..* 39 <<XCONN component>> TXC <<component>> LPS macro component 1..* 1..2 <<XCONN component>> PTXC

40 Step2: encountered problems» UML is not the best tool to analyze software architectures» We decided to use an ADL: - Darwin for the topology - The FSP process algebra for the dynamic» XCONN micro-components and communication channels (previously defined using the UML Class Diagram) have been modeled as Darwin components and connectors.» The FSP specification language has been used to describe the Darwin components behavior. SDL code and diagrams have been used to produce the FSP specification 40

41 1.System Domain Analysis 2. Domain Analysis of XCONN 3. ARCHITECTURAL DESCRIPTION Components Detailed Documentation SDL Code and Diagrams Previous Steps Results Architectural Description Message Message Abstraction Abstraction Components Components Topological Topological Description Description (DARWIN) (DARWIN) 3.Architectural 41 Description 4.Functional Partition Previous Previous results results modification modification Behavioral Behavioral Description Description (FSP) (FSP)

42 DARWIN TOPOLOGICAL DESCRIPTION SAXC Graphical Description SAXC cxc[0] cxc[1] bxc[0] bxc[1] txc[1] txc[2] txc[n] 42

43 SDL GRAPHICAL DESCRIPTION SDL State INPUT MESSAGES OUTPUT MESSAGES 43

44 range Active_Cxc = 0..1 range State = range p_state= 0..1 GXC= GXC_INIT, FSP Specification GXC_INIT = (gcm_state_require-> GXC_WAITING[0][...][...]...), a) b) c) GXC_WAITING[cxca:Active_Cxc][...][...][...][...]= d) (epg_matrix_state -> (gc_matrix_state[0][0] -> GXC_W_ACK_STATE[1][escore1][escore2][tmux1][tmux2] gc_matrix_state[0][1] -> GXC_W_ACK_STATE[0][escore1][escore2][tmux1][tmux2] tout -> GXC_WAITING[cxca][escore1][escore2][tmux1][tmux2]) cmg_resource_state[nescore1:statop][nescore2:statop][ntmux1:statop][ntmux2:statop] -> gcm_ack -> (gc_matrix_state[0][0] -> gcstate_matrix[1][1] ->......), GXC_W_ACK_STATE[cxca:Active_Cxc][...][...]... = (cg_gxcack -> GXC_W_ACK_STATE[cxca][...][...]... cmg_resource_state[p: p_state]->......),... e) 44

45 Labeled Transition System generated from the FSP Specification BXC Process LTS 45

46 4. FUNCTIONAL PARTITION 1.System Domain Analysis Previous Steps Results 2. Domain Analysis of XCONN 3.Architectural Description SDL Code and Diagrams Functional Partition Messagge Messagge SequenceChart SequenceChart (MSC) (MSC) Activity Activity Diagram Diagram (UML) (UML) 4.Functional Partition 46

47 Functional Partition» In the first step we manually generated some system scenarios. This description was too high level for quantitative analysis» In the third step we used the available SDL documentation to write an FSP specification of the XCONN component; in this case the level of abstraction was right BUT we were not able to generate the system model due to the model complexity.» At this step, the idea is to integrate the low level scenarios produced in step1 with XCONN internal interactions, described in the FSP spec two different levels of abstraction in the same model 47

48 APPROACH CONCLUSIONS Documentation lackness Not well defined development process Incoerence between low-and high-level documentation Poor architectural description UML is not enough to describe the behavioral description Formal tools limitations 48

49 Lecture Conclusions» Software and Hardware Together» Too complex way to abstract XCONN - Two level of abstraction XCONN1» SA for quantitative (performance) analysis - why!» Architectural style 1..2 XCONN2 XCONN3 - it was not achieved (picture) 49» Consistency problems. (message name)