"... In PAGE 48: ... The resource type displayed with the name is link (LNK). Substitution Variables: The resource types that can be associated with each substitution variable shown in Table3 -1 on page 3-4 are defined as follows: Line description This is the name of a line description created by a create line description command. See the Communications Configuration book for the create line description commands.... In PAGE 49: ... Second level resource This is the name of the physical resource that is associated with the failing resource and second closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Third level resource This is the name of the physical resource that is associated with the failing resource and third closest to the system processor.... In PAGE 49: ... Third level resource This is the name of the physical resource that is associated with the failing resource and third closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Fourth level resource This is the name of the physical resource that is associated with the failing resource and is the fourth closest to the system processor.... In PAGE 49: ... Fourth level resource This is the name of the physical resource that is associated with the failing resource and is the fourth closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Network interface description This is the name of a network interface description created by the Create Network Interface Description (CRTNWIISDN) command.... In PAGE 49: ... Refer to the ISDN Support book for more infor- mation. Note: See Table3 -5 on page 3-16 for a list of the resource type abbreviations. Alert Hierarchy: Only one number is defined for the resource name variable, but if this number is known by the system, a complete hierarchy, which includes an entry for each resource in the hier- archy, is built by the system, starting from the name of the failing resource up through the name of the system itself.... In PAGE 51: ... bulletmed Handle problems differently depending on the type of problem. Table3 -2 on page 3-6 shows the relationship between the alert option (ALROPT) parameter in the message description and the alert status (ALRSTS) network attribute. In this figure, the messages defined as *DEFER have the log problem (LOGPRB) parameter in the message description set to *YES; setting the LOGPRB parameter to *NO in a message causes all alerts for that message to be treated as *IMMED.... In PAGE 60: ... You can control the logging of alerts using the alert logging status (ALRLOGSTS) network attribute. Logging Alerts: Table3 -3 shows whether an alert is logged in the alert database, depending on: 1. The ALRLOGSTS network attribute (*ALL, *LOCAL, *RCV, or *NONE) 2.... In PAGE 60: ... When a held alert is successfully sent, the alert logging status network attribute controls whether the alert remains in the alert database. If the con- ditions shown in Table3 -3 indicate that the alert should not be logged, it is deleted from the alert database. If the conditions indicate that the alert should be logged, it remains in the alert database, but it is no longer displayed as a held alert.... In PAGE 72: ... Determining the Message ID: The message ID for a code point consists of the code point plus a 3-character prefix. Table3 -6 shows the message ID prefixes for the alert code points: For example, the message ID for failure cause X apos;1234 apos; is ALF1234. The code point for the detail qualifier data ID is only 2 hexadecimal digits.... In PAGE 73: ... For code point X apos;xxYx apos;, Y determines the number. Table3 -7 lists the number of qualifiers required by a code point with the given third digit. Substitution Text for Detailed Qualifiers: When you create a code point message that con- tains detailed qualifiers, you must specify where the qualifiers will be displayed.... In PAGE 73: ... To specify detailed qualifiers that appear on the same line as the code point text, you use substi- tution variables to define the placement of the qualifiers. Table3 -8 shows the substitution vari- able numbers that should be used for each qual- ifier. If the detailed qualifier placement is defined at the end of the code point text, you can omit the sub- stitution variable at the end of the text, and the system displays the detailed qualifier on the line following the code point text.... ..."

"... In PAGE 48: ... The resource type displayed with the name is link (LNK). Substitution Variables: The resource types that can be associated with each substitution variable shown in Table3 -1 on page 3-4 are defined as follows: Line description This is the name of a line description created by a create line description command. See the Communications Configuration book for the create line description commands.... In PAGE 49: ... Second level resource This is the name of the physical resource that is associated with the failing resource and second closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Third level resource This is the name of the physical resource that is associated with the failing resource and third closest to the system processor.... In PAGE 49: ... Third level resource This is the name of the physical resource that is associated with the failing resource and third closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Fourth level resource This is the name of the physical resource that is associated with the failing resource and is the fourth closest to the system processor.... In PAGE 49: ... Fourth level resource This is the name of the physical resource that is associated with the failing resource and is the fourth closest to the system processor. The type of resource named by this variable depends on the type of subsystem as shown in Table3 -1 on page 3-4. Network interface description This is the name of a network interface description created by the Create Network Interface Description (CRTNWIISDN) command.... In PAGE 49: ... Refer to the ISDN Support book for more infor- mation. Note: See Table3 -5 on page 3-16 for a list of the resource type abbreviations. Alert Hierarchy: Only one number is defined for the resource name variable, but if this number is known by the system, a complete hierarchy, which includes an entry for each resource in the hier- archy, is built by the system, starting from the name of the failing resource up through the name of the system itself.... In PAGE 51: ... bulletmed Handle problems differently depending on the type of problem. Table3 -2 on page 3-6 shows the relationship between the alert option (ALROPT) parameter in the message description and the alert status (ALRSTS) network attribute. In this figure, the messages defined as *DEFER have the log problem (LOGPRB) parameter in the message description set to *YES; setting the LOGPRB parameter to *NO in a message causes all alerts for that message to be treated as *IMMED.... In PAGE 60: ... You can control the logging of alerts using the alert logging status (ALRLOGSTS) network attribute. Logging Alerts: Table3 -3 shows whether an alert is logged in the alert database, depending on: 1. The ALRLOGSTS network attribute (*ALL, *LOCAL, *RCV, or *NONE) 2.... In PAGE 60: ... When a held alert is successfully sent, the alert logging status network attribute controls whether the alert remains in the alert database. If the con- ditions shown in Table3 -3 indicate that the alert should not be logged, it is deleted from the alert database. If the conditions indicate that the alert should be logged, it remains in the alert database, but it is no longer displayed as a held alert.... In PAGE 72: ... Determining the Message ID: The message ID for a code point consists of the code point plus a 3-character prefix. Table3 -6 shows the message ID prefixes for the alert code points: For example, the message ID for failure cause X apos;1234 apos; is ALF1234. The code point for the detail qualifier data ID is only 2 hexadecimal digits.... In PAGE 73: ... For code point X apos;xxYx apos;, Y determines the number. Table3 -7 lists the number of qualifiers required by a code point with the given third digit. Substitution Text for Detailed Qualifiers: When you create a code point message that con- tains detailed qualifiers, you must specify where the qualifiers will be displayed.... In PAGE 73: ... To specify detailed qualifiers that appear on the same line as the code point text, you use substi- tution variables to define the placement of the qualifiers. Table3 -8 shows the substitution vari- able numbers that should be used for each qual- ifier. If the detailed qualifier placement is defined at the end of the code point text, you can omit the sub- stitution variable at the end of the text, and the system displays the detailed qualifier on the line following the code point text.... ..."

"... In PAGE 48: ... The resource type displayed with the name is link (LNK). Substitution Variables: The resource types that can be associated with each substitution variable shown in Table3 -1 on page 3-3 are defined as follows: 3-2 OS/400 Alerts Support V4R1 ... In PAGE 49: ... Table 3-1. Resource Name Variables Defined by the System Variable Description Resource Type Com- munications Sub- system Resource Type Storage Sub- system Resource Type Work Station Sub- system 23 Line description LNK, BCH N/A N/A 24 Controller description CTL N/A CTL, LC 25 Device description N/A TAP, DKT DSP, PRT 26 First level resource LC LC LC 27 Second level resource ADP ADP DSP, PRT 28 Third level resource POR DSK, DKT, TAP N/A 29 Fourth level resource BCH N/A N/A 30 Network interface description DCH N/A N/A 30 Network server description SVR N/A N/A Note: See Table3 -5 on page 3-16 for a list of the resource type abbreviations. Alert Hierarchy: Only one number is defined for the resource name variable, but if this number is known by the system, a complete hierarchy, which includes an entry for each resource in the hier- archy, is built by the system, starting from the name of the failing resource up through the name of the system itself.... In PAGE 51: ... bulletmed Handle problems differently depending on the type of problem. Table3 -2 shows the relationship between the alert option (ALROPT) parameter in the message description and the alert status (ALRSTS) network attribute. In this figure, the messages defined as *DEFER have the log problem (LOGPRB) param- eter in the message description set to *YES; setting the LOGPRB parameter to *NO in a message causes all alerts for that message to be treated as *IMMED.... In PAGE 59: ... You can control the logging of alerts using the alert logging status (ALRLOGSTS) network attribute. Logging Alerts: Table3 -3 shows whether an alert is logged in the alert database, depending on: 1. The ALRLOGSTS network attribute (*ALL, *LOCAL, *RCV, or *NONE) 2.... In PAGE 60: ... the alert remains in the alert database. If the con- ditions shown in Table3 -3 indicate that the alert should not be logged, it is deleted from the alert database. If the conditions indicate that the alert should be logged, it remains in the alert database, but it is no longer displayed as a held alert.... In PAGE 71: ... Determining the Message ID: The message ID for a code point consists of the code point plus a 3-character prefix. Table3 -6 shows the message ID prefixes for the alert code points: For example, the message ID for failure cause X apos;1234 apos; is ALF1234. The code point for the detail qualifier data ID is only 2 hexadecimal digits.... In PAGE 72: ... For code point X apos;xxYx apos;, Y determines the number. Table3 -7 lists the number of qualifiers required by a code point with the given third digit. Substitution Text for Detailed Qualifiers: When you create a code point message that con- tains detailed qualifiers, you must specify where the qualifiers will be displayed.... In PAGE 72: ... To specify detailed qualifiers that appear on the same line as the code point text, you use substi- tution variables to define the placement of the qualifiers. Table3 -8 shows the substitution vari- able numbers that should be used for each qual- ifier. If the detailed qualifier placement is defined at the end of the code point text, you can omit the sub- stitution variable at the end of the text, and the system displays the detailed qualifier on the line following the code point text.... ..."

"... In PAGE 48: ... The resource type displayed with the name is link (LNK). Substitution Variables: The resource types that can be associated with each substitution variable shown in Table3 -1 on page 3-3 are defined as follows: 3-2 OS/400 Alerts Support V4R1 ... In PAGE 49: ... Table 3-1. Resource Name Variables Defined by the System Variable Description Resource Type Com- munications Sub- system Resource Type Storage Sub- system Resource Type Work Station Sub- system 23 Line description LNK, BCH N/A N/A 24 Controller description CTL N/A CTL, LC 25 Device description N/A TAP, DKT DSP, PRT 26 First level resource LC LC LC 27 Second level resource ADP ADP DSP, PRT 28 Third level resource POR DSK, DKT, TAP N/A 29 Fourth level resource BCH N/A N/A 30 Network interface description DCH N/A N/A 30 Network server description SVR N/A N/A Note: See Table3 -5 on page 3-16 for a list of the resource type abbreviations. Alert Hierarchy: Only one number is defined for the resource name variable, but if this number is known by the system, a complete hierarchy, which includes an entry for each resource in the hier- archy, is built by the system, starting from the name of the failing resource up through the name of the system itself.... In PAGE 51: ... bulletmed Handle problems differently depending on the type of problem. Table3 -2 shows the relationship between the alert option (ALROPT) parameter in the message description and the alert status (ALRSTS) network attribute. In this figure, the messages defined as *DEFER have the log problem (LOGPRB) param- eter in the message description set to *YES; setting the LOGPRB parameter to *NO in a message causes all alerts for that message to be treated as *IMMED.... In PAGE 59: ... You can control the logging of alerts using the alert logging status (ALRLOGSTS) network attribute. Logging Alerts: Table3 -3 shows whether an alert is logged in the alert database, depending on: 1. The ALRLOGSTS network attribute (*ALL, *LOCAL, *RCV, or *NONE) 2.... In PAGE 60: ... the alert remains in the alert database. If the con- ditions shown in Table3 -3 indicate that the alert should not be logged, it is deleted from the alert database. If the conditions indicate that the alert should be logged, it remains in the alert database, but it is no longer displayed as a held alert.... In PAGE 71: ... Determining the Message ID: The message ID for a code point consists of the code point plus a 3-character prefix. Table3 -6 shows the message ID prefixes for the alert code points: For example, the message ID for failure cause X apos;1234 apos; is ALF1234. The code point for the detail qualifier data ID is only 2 hexadecimal digits.... In PAGE 72: ... For code point X apos;xxYx apos;, Y determines the number. Table3 -7 lists the number of qualifiers required by a code point with the given third digit. Substitution Text for Detailed Qualifiers: When you create a code point message that con- tains detailed qualifiers, you must specify where the qualifiers will be displayed.... In PAGE 72: ... To specify detailed qualifiers that appear on the same line as the code point text, you use substi- tution variables to define the placement of the qualifiers. Table3 -8 shows the substitution vari- able numbers that should be used for each qual- ifier. If the detailed qualifier placement is defined at the end of the code point text, you can omit the sub- stitution variable at the end of the text, and the system displays the detailed qualifier on the line following the code point text.... ..."

"... In PAGE 32: ........................................................ Electrical and Environmental The Promina 100 Model 2 electrical and environmental operating specifications are listed in Table3 -1. Power for the Promina 100 Model 2 must conform to National Electrical Code (NEC) standards.... In PAGE 35: ... Wattage and BTU Output The Promina shelf types with their maximum wattage and BTUs per hour are listed in Table 3-6. Module Power Consumption The module power consumption for the Promina systems are listed in Table3 -7 to Table 3-11. Table 3-5 Power Assembly Specifications... ..."

"... In PAGE 8: ...able 2-3 Hazard Causes and Controls - Examples .........................................................16 Table3 -1 NASA Software Lifecycle - Reviews and Documents.... In PAGE 8: ...able 3-1 NASA Software Lifecycle - Reviews and Documents......................................20 Table3 -2 MIL-STD-882C Software Hazard Criticality Matrix.... In PAGE 8: ...able 3-2 MIL-STD-882C Software Hazard Criticality Matrix.......................................28 Table3 -3 Software Sub-system categories.... In PAGE 8: ...able 3-3 Software Sub-system categories........................................................................29 Table3 -4 Required Software Safety Effort .... In PAGE 8: ...able 3-4 Required Software Safety Effort .......................................................................30 Table3 -5 Software Requirements Phase.... In PAGE 8: ...able 3-5 Software Requirements Phase...........................................................................33 Table3 -6 Software Architectural Design Phase.... In PAGE 8: ...able 3-6 Software Architectural Design Phase................................................................34 Table3 -7 Software Detailed Design Phase .... In PAGE 8: ...able 3-7 Software Detailed Design Phase .......................................................................34 Table3 -8 Software Implementation Phase.... In PAGE 8: ...able 3-8 Software Implementation Phase........................................................................35 Table3 -9 Software Testing Phase .... In PAGE 8: ...able 3-9 Software Testing Phase .....................................................................................35 Table3 -10 Dynamic Testing .... In PAGE 8: ...able 3-10 Dynamic Testing .............................................................................................36 Table3 -11 Software Module Testing .... In PAGE 27: ...19 3.1 Software Development Lifecycle Approach Table3 -1 NASA Software Lifecycle - Reviews and Documents (page 20)shows the typical NASA software waterfall design lifecycle phases and lists the reviews and deliverable project documents required at each lifecycle phase. Each of these reviews and project documents should contain appropriate references and reports on software safety.... In PAGE 28: ...20 Table3 -1 NASA Software Lifecycle - Reviews and Documents LIFECYCLE PHASES MILESTONE REVIEWS SOFTWARE SAFETY TASKS DOCUMENTS Software Concept and Initiation (Project System and Subsystem Requirements and Design Development) SCR - Software Concept Review Software Management Plan Review Phase-0 Safety Review Scoping Safety Effort 2.1.... In PAGE 31: ... The system development phases are separated by system design reviews. Each system design review is conducted approximately in parallel with a corresponding system safety review as shown in Table3 -1 NASA Software Lifecycle - Reviews and Documents on page 20. The software development effort may or may not be synchronized with the system development effort.... In PAGE 35: ... 3.3 Scoping of Software Subsystem Safety Effort The level of required software safety effort for a system (shown in Table3 -3) is determined by its System Category, derived from Table 2-2 Hazard Prioritization - System Risk Index (Page 8), and the hazard severity level from Section 2.... In PAGE 36: ...28 Table3 -2 MIL-STD-882C Software Hazard Criticality Matrix HAZARD CATEGORY CONTROL CATEGORY CATASTRO- PHIC CRITICAL MODERATE NEGLIGIBLE / MARGINAL I1135 II 1 2 4 5 III 2 3 5 5 III 3 4 5 5 Software Hazard Risk Index Suggested Criteria 1 High Risk - significant analysis and testing resources 2 Medium risk - requirements and design analysis and in-depth testing required 3-4 Moderate risk - high level analysis and testing acceptable with management approval 5 Low Risk - Acceptable 3.3.... In PAGE 37: ...29 Table3 -3 Software Sub-system categories System Category Descriptions I Partial or total autonomous control of safety critical functions by software. (System Risk Index 2) Complex system with multiple subsystems, interacting parallel processors, or multiple interfaces.... In PAGE 38: ...30 Table3 -4 Required Software Safety Effort SYSTEM CATEGORY HAZARD SEVERITY LEVEL from Section 2.... In PAGE 39: ... Ultimately, the range of selected techniques must be negotiated and approved by project management, software development, software quality assurance, and software systems safety. Table3 -5 Software Requirements Phase through Table 3-11 Software Module Testing are modifications of tables that appear from an early International Electrotechnical Committee (IEC) draft standard IEC 1508, quot;Software For Computers In The Application Of Industrial Safety-Related Systems quot; [5]. This document is currently under review by national and international representatives on the IEC to determine its acceptability as an international standard on software safety for products which contain Programmable Electronic Systems (PESs).... In PAGE 39: ... These tables provide guidance on the types of assurance activities which may be performed during the lifecycle phases of safety-critical software development. For this guidebook, the Required Software Safety Efforts values displayed in Table3 -4 Required Software Safety Effort (page 30), will determine which development activities are required for each level of effort. Each of the following tables lists techniques and recommendations for use based on safety effort level for a specific software development phase or phases.... In PAGE 40: ... The final list of techniques to be used on any project should be developed jointly by negotiations between project management and safety assurance. All the following tables, Table3 -5 Software Requirements Phase through Table 3-11 Software Module Testing , list software development, safety and assurance activities which should be implemented in the stated phases of development. Life Cycle Phase Tasks and Priorities How To: Development Tasks How To: Analysis Tasks Concept Initiation Table 3-5 Software Requirements Phase Section 4.... In PAGE 40: ... All the following tables, Table 3-5 Software Requirements Phase through Table 3-11 Software Module Testing , list software development, safety and assurance activities which should be implemented in the stated phases of development. Life Cycle Phase Tasks and Priorities How To: Development Tasks How To: Analysis Tasks Concept Initiation Table3 -5 Software Requirements Phase Section 4.1 Section 5.... In PAGE 40: ...1 Section 5.1 Software Requirements Table3 -5 Software Requirements Phase Section 4.2 Section 5.... In PAGE 40: ...2 Section 5.1 Software Architectural Design Table3 -5 Software Requirements Phase Section 4.3 Section 5.... In PAGE 40: ...3 Section 5.1 Software Detailed Design Table3 -7 Software Detailed Design Phase Section 4.4 Section 5.... In PAGE 40: ...4 Section 5.3 Software Implementation Table3 -8 Software Implementation Phase Section 4.5 Section 5.... In PAGE 40: ...5 Section 5.1 Software Test Table3 -9 Software Testing Phase Table 3-10 Dynamic Testing Table 3-11 Software Module Testing Section 4.6... In PAGE 40: ...5 Section 5.1 Software Test Table 3-9 Software Testing Phase Table3 -10 Dynamic Testing Table 3-11 Software Module Testing Section 4.6... In PAGE 40: ...5 Section 5.1 Software Test Table 3-9 Software Testing Phase Table 3-10 Dynamic Testing Table3 -11 Software Module Testing Section 4.6... In PAGE 42: ...34 Table3 -6 Software Architectural Design Phase TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL 5.2.... In PAGE 42: ....2.4.2 Independence Analysis HR M M Table3 -7 Software Detailed Design Phase TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL 5.3.... In PAGE 43: ...35 Table3 -8 Software Implementation Phase TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL 5.4.... In PAGE 43: ...4.9 Formal Methods NR HR HR Table3 -9 Software Testing Phase TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL Testing Defensive Programming NR HR M Boundary Value Tests R HR M Error Guessing NR NR R Test Coverage Analysis R HR M Functional Testing M M M Fagan Formal Inspections (Test Plans) HR HR M Reliability Modeling NR HR HR Checklists of Tests R HR... In PAGE 44: ...36 Table3 -10 Dynamic Testing TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL Typical sets of sensor inputs HR M M Test specific functions HR M M Volumetric and statistical tests R HR HR Test extreme values of inputs R M M Test all modes of each sensor R M M Path testing R M M Every statement executed once HR M M Every branch tested at least once HR M M Every predicate term tested R HR M Every loop executed 0, 1, many times R M M Every path executed R HR M Every assignment to memory tested NR HR HR Every reference to memory tested NR HR HR All mappings from inputs checked NR HR HR All timing constraints verified R M M Test worst case interrupt sequences R R... In PAGE 45: ...37 Test significant chains of interrupts R R NR Test Positioning of data in I/O space HR M M Check accuracy of arithmetic NR HR M All modules executed at least once M M M All invocations of modules tested HR M M Table3 -11 Software Module Testing TECHNIQUE SAFETY EFFORT LEVEL MIN MOD FULL Simulation (Test Environment) R HR M Load Testing (Stress Testing) HR M M Boundary Value Tests R HR M Test Coverage Analysis R HR M Functional Testing M M M Performance Monitoring R HR M Formal Progress Reviews R M M Reliability Modeling NR HR HR Checklists of Tests R HR... ..."

"... In PAGE 7: ... Conversely the two systems with different charge distributions behave differently at low temperature. The impact of HT-T charges on the total energy is much more important than the one of HT-AT charges, inducing also a slight but significant increase in the orientational order and density at the lowest T* (see also Table1 ). This is particularly evident at the Nem-Colh transition (T* = 0.... ..."

"... In PAGE 6: ...LIST OF TABLES Table3 -1: Relative error of greedy k-median and greedy UFLP algorithms.... In PAGE 6: ...able 3-1: Relative error of greedy k-median and greedy UFLP algorithms............................... 47 Table3 -2: Distance matrix of the network in figure 3-2.... In PAGE 6: ...able 3-2: Distance matrix of the network in figure 3-2. ............................................................. 51 Table3 -3: Selecting the second median.... In PAGE 6: ...able 3-3: Selecting the second median. ...................................................................................... 52 Table3 -4: Selecting the third median.... In PAGE 6: ...able 3-4: Selecting the third median........................................................................................... 53 Table3 -5: Summary of the performance parameters.... In PAGE 54: ...ccuracy. On average, the greedy-based algorithms deviate merely 5% from optimum. For k-median problem, we run a simple greedy construction algorithm against 40 test cases from [ORLIB]. The results are shown in Table3 -1. The average deviation from the optimum is very low, 1.... In PAGE 54: ...ery low, 1.51%, while the worst case error is only 4.3%. As we have addressed earlier, the UFLP cannot be used directly unless the appropriate facility opening costs are known beforehand. Table3 -1 also shows the results of using UFLP for solving k-median problem by performing a binary search on the opening costs for the instance of UFLP that yields minimum objective value and opens the number of facilities less than or equal to k. The running time of the algorithm is higher than solving k-median problem using greedy algorithm since it requires solving many instances of UFLP during the binary search.... In PAGE 55: ... Table3 -1: Relative error of greedy k-median and greedy UFLP algorithms. k-MEDIAN UFLP Problem Instances n k % k / n OPT SOL SOL %ERROR SOL %ERROR pmed01 100 5 5.... In PAGE 59: ... Table3 -2: Distance matrix of the network in figure 3-2. Nodes A B C D E F G H I J K L TOTAL A 0 15 37 55 24 60 18 33 48 40 58 67 455 B 15 0 22 40 38 52 33 48 42 55 61 61 467 C 37 22 0 18 16 30 41 28 20 58 39 39 348 D 55 40 18 0 34 12 59 46 24 62 43 34 427 E 24 38 16 34 0 36 25 12 24 47 37 43 336 F 60 52 30 12 36 0 57 42 12 50 31 22 404 G 18 33 41 59 25 57 0 15 45 22 40 61 416 H 33 48 28 46 12 42 15 0 30 37 25 46 362 I 48 42 20 24 24 12 45 30 0 38 19 19 321 J 40 55 58 62 47 50 22 37 38 0 19 40 468 K 58 61 39 43 37 31 40 25 19 19 0 21 393 Facilitie s L 67 61 39 34 43 22 61 46 19 40 21 0 453 15 22 18 A B C D Figure 3-3: The clustering result of the network in figure 3-2 using set covering clustering method.... In PAGE 60: ... The coverage distance is still 20. Starting from the distance matrix in Table3 -2, by summing the entries in each, we obtain the total connection cost for 1-median problems. The smallest total connection cost is 321, when node I is selected as a facility.... In PAGE 60: ... The algorithm continues. Table3 -3: Selecting the second median. Nodes A B C D E F G H I J K L TOTAL A 0 15 20 24 24 12 18 30 0 38 19 19 219 B 15 0 20 24 24 12 33 30 0 38 19 19 234 C 37 22 0 18 16 12 41 28 0 38 19 19 250 D 48 40 18 0 24 12 45 30 0 38 19 19 293 E 24 38 16 24 0 12 25 12 0 38 19 19 227 F 48 42 20 12 24 0 45 30 0 38 19 19 297 G 18 33 20 24 24 12 0 15 0 22 19 19 206 H 33 42 20 24 12 12 15 0 0 37 19 19 233 I 48 42 20 24 24 12 45 30 0 38 19 19 321 J 40 42 20 24 24 12 22 30 0 0 19 19 252 K 48 42 20 24 24 12 40 25 0 19 0 19 273 Facilitie s L 48 42 20 24 24 12 45 30 0 38 19 0 302 Once node I is selected, we locate the second median by updating each entry of the distance matrix by calculating min{dIj, dij}.... In PAGE 60: ... In other words, node j connects to facility I if the connection cost is lower than connecting to the current facility i. Table3 -3 shows the resulting update. The second facility that we will select is node G since it yields the minimum connection cost of 206.... In PAGE 60: ... We again update the distance matrix by calculating min{dGj, dIj, dij} for each node / candidate location pair (i, j), and find that the third facility is located at node C, which yields the minimum connection cost of 161. Table3 -4 shows the update. Now the farthest distance is 22 ... In PAGE 61: ...nd the average distance is 13.42. The algorithm proceeds in this manner until the distance from any node to the nearest facility are lower than or equal to 20. Table3 -4: Selecting the third median. Nodes A B C D E F G H I J K L TOTAL A 0 15 20 24 24 12 0 15 0 22 19 19 170 B 15 0 20 24 24 12 0 15 0 22 19 19 170 C 18 22 0 18 16 12 0 15 0 22 19 19 161 D 18 33 18 0 24 12 0 15 0 22 19 19 180 E 18 33 16 24 0 12 0 12 0 22 19 19 175 F 18 33 20 12 24 0 0 15 0 22 19 19 182 G 18 33 20 24 24 12 0 15 0 22 19 19 206 H 18 33 20 24 12 12 0 0 0 22 19 19 179 I 18 33 20 24 24 12 0 15 0 22 19 19 206 J 18 33 20 24 24 12 0 15 0 0 19 19 184 K 18 33 20 24 24 12 0 15 0 19 0 19 184 Facilitie s L 18 33 20 24 24 12 0 15 0 22 19 0 187 In our example, the greedy d-median algorithm stops after five facilities were selected: I, G, C, A and K, respectively.... In PAGE 62: ... The average radius of clusters is the average of the delay from anchor to the farthest node in the cluster. Table3 -5 summarizes the descriptions of these parameters. G E H I F J K L 16 24 18 12 25 24 12 12 30 15 22 25 19 19 22 19 21 20... ..."

"... In PAGE 10: ... GQIPS Provider system Represents the underlying software and hardware that provide the IP connectivity between the various parties. Table3 -1 VPN Actors These actors participate in two main use cases Request VPN Service and Create VPN Connection ,... In PAGE 11: ... Exceptions An exception is raised, which must be caught by the IESPS and handled according to the nature of the exception (Invalid input, etc.) Traceability Business process: VPN Service Configuration Table3 -2 Use case description of Request VPN Service Use case Name Create VPN Connection Summary The use case demonstrates how the VPNS Provider System fulfils the VPN order for the VPNS Customer by provisioning and activating a VPN connection Actors IESPS and GQIPSPS Pre-Conditions The relationship between the IESPS and VPNSPS exists and the service instance for the VPNS Customer has been created. Begins When When the VPN order (Create VPN Connection) has arrived from the IESPS Steps The IESPS requests the VPNSPS to create a VPN connection.... In PAGE 11: ... Exceptions An exception is raised, which must be caught by the IESPS and handled according to the nature of the exception (Invalid input, network failure, etc.) Traceability Business process: VPN Service Configuration Table3... In PAGE 12: ...2.1 Boundary Objects Boundary Objects Responsibility VPN Service Interface This object provides the interface of the VPNSPS towards the IESPS Table3... In PAGE 13: ... The object will control and manipulate IPSec tunnels through the use of IETF IPSec Provisioning Policies. Table3 -6 Control Objects The analysis object form an abstract system model where each object has a certain responsibility to carry out part of the use case. In the next section these abstract objects are grouped in Building Blocks and thus each Building Block has responsibility for several steps of the use case.... ..."