Project 2 PresentationsCS554 – Designs for Software and Systems

Team HAND – Seokin Hong, Gieil Lee, Jesung Kim, Yebin LeeDepartment of Computer Science, KAIST

Page 2

Requirements• Quality Attribute (Utility Tree)• Rating

Candidate Architecture Style• Pipe-filter• Client-server

Scenarios Analysis Architectural Analysis Rating

Architecture Overview

Contents

Page 3

Requirements – Quality Attribute (Utility Tree)

Utility

Performance

Response time

Throughput

Modifiability

Availability

Testability Built-in monitor

Repair time

Deadline time

Latency

Prevent ripple events

Page 4 4

Requirements – Quality Attribute (Utility Tree)

Performance

Response time

Throughput

Deadline time

When the fault occurs, fault protection system invoked asynchronously at any time

Upper layer component checks parameter of lower layer components

Fault occurs when the critical function is running, the fault protection system responses within specific time

[H, L]

[M, L]

[H, H]

Latency[H, L] In order to check parameter, a component

accesses DB for fetching predefined operating range value

Page 5

Requirements – Quality Attribute (Utility Tree)

Modifiability Prevent rippleevents

Fault protection software can be added into existing fault protection software or replaced or eliminated

[M, M]

Availability Repair time Fault protection system tests itself for detecting its fault

[H, M]

Testability Built-in monitorVerification of fault protection system is performed by the combination of inspection, simulation, and analysis

[M, H]

Page 6

Quality Attribute Rating

Requirements – Rating

Priority Quality Attribute Rating

1 Performance 4.25

2 Availability 4

3 Modifiability 3

4 Testability 2

Page 7

Pipe-filter

Asynchronous, concurrent, Independent

Data stream

Non-recursive, pipeline

Client/Server

Asynchronous / synchronous

Performance, Modifiability, Reliability

N-tier

Candidate Architecture Style

Page 8

Performance – Throughput

Scenarios Analysis

Scenario No. : 1 Scenario: Upper layer component checks parameter of lower layer components for detecting faults

Attributes PerformanceEnvironment Normal operationStimulus Result parameter of operationResponse Parameter checking is proceeded.Response mea-surement Parameter checking process starts within specific time.

Architectural deci-sion

Sensitivity point Tradeoff point Risks Non-risks

Bound queue sizes S1 R1

Reasons

- An upper layer can have many lower layer components. If many lower layer components send their parameters to upper layer, response time can be decreased.

- Queue size of upper layer component affects average response time directly. (S1)

- If queue is full, some important parameters can be delayed or discarded. (R1)

Page 9

Performance – Throughput

Scenarios Analysis

Architecture Comparison Effect

Pipe-filter Performance can be guaranteed by limiting the bound of queue size but fault information may be lost when the queue entries are full thus, reliability may decrease. -

Client-serverServer can limit the queue entries for the performance while preventing decrement of reliability because if the client requests fault processing when the queue entries of server is full, server sends feedback to client to wait for specific time and client keeps the fault request then attempt to request fault processing again. Fault information is not lost leastwise in this architecture.

+

Parameter checkerComponent

Parameter checker

Component Component

Pipe and Filter Client/Server

Page 10

Performance – Latency

Scenarios Analysis

Scenario No. : 2 Scenario: A component access to database for fetching normal operation range values.

Attributes Performance

Environment Normal operation

Stimulus Result parameter of operation

Response Access to database Response measurement Fetching range value within specific time.

Architectural decision Sensitivity point Tradeoff point Risks Non-risks

Caching storage S1 N1

Basis

- If multiple components access to database at same time, throughput of database may be decreased. This performance degradation can decrease latency of components.

- Caching strategy ease resource competition. (S1) - Normally, caching invokes synchronization problems. Moreover, If main

data which in the database are frequently modified, synchronization also invokes performance degradation. However, in case if spacecraft, normal operating rage values are calculated statically. So, this strategy cannot affects performance directly. (N1)

Page 11

Performance – Latency

Scenarios Analysis

Architecture Comparison Effect

Pipe-filter In pipe-filter architecture, caching component is realized with informal shape of pipe-filter archi-tecture. -

Client-serverLatency of fetching normal operation range value from database can be reduced by placing caching component between client and server. By using caching component, access traffic of server can decrease and fetching latency can decrease if it is hit in caching component.

+

Component

Caching storage

Database

Component Component Component

Caching storage

Database

Component

Pipe and Filter Client/Server

Page 12

Performance – Response time

Scenarios Analysis

Scenario No. : 3 Scenario: Abnormal parameter is detected.

Attributes Performance

Environment Normal operation

Stimulus Abnormal parameter

Response Transit state of fault protection system into fault recovery mode

Response measurement

Delay time of transitioning state of fault protection system into fault recovery mode

Architectural decision Sensitivity point Tradeoff point Risks Non-risks Fault processing request S1 R1

Basis

- Response for processing particular fault may be delayed if other faults are already being processed by fault protection system. (S1)

- Fault may propagate or spacecraft may fall into dangerous state unless the fault is recovered within specific time. (R1)

Page 13

Performance – Response time

Scenarios Analysis

Architecture Comparison Ef-fect

Pipe-filterBecause of its characteristic (data is processed as FIFO order), it cannot make a response for upcoming faults until processing of prior fault is incomplete.

-

Client-server It can respond rapidly because the client makes connection with server individually. +

Page 14

Performance – Deadline time

Scenarios Analysis

Scenario No. : 4 Scenario: Fault occurs while critical function is running

Attributes Performance

Environment Critical operation

Stimulus Abnormal parameter

Response Start fault recovery immediately to allow the critical function to be continued.

Response measurement Completion time of fault recovery

Architectural decision Sensitivity point Tradeoff point Risks Non-risks

Priority scheduling S1 T1

Basis

- Faults which occur during critical function is running have highest priority to be processed. (S1)

- Processing for other faults may be delayed till the critical fault is processed completely.

Page 15

Performance – Deadline time

Scenarios Analysis

Architecture Comparison Ef-fect

Pipe-filter Context switching cannot be performed on the data which is al-ready being processed in pipe-filter architecture -

Client-server In client-server architecture, the server can process the data which has higher priority by delaying current data processing. +

Page 16

Modifiability – Prevent ripple events

Scenarios Analysis

Scenario No. : 5 Scenario: Fault protection software is newly added into existing fault protection software or replaced or eliminated.

Attributes Modifiability

Environment Run-time

Stimulus Modification of fault protection system software

Response Perform modification without affecting to other functionality Response measurement Modification effect on functionality or attribute of other software

Architectural decision Sensitivity point Tradeoff point Risks Non-risks

Software framework S1 R1

Basis

- Adding software or replacing with existing software or eliminating existing software may affect to functionality or attribute of other existing software. (S1)

- Modification may incur malfunction of existing software because of conflict or dependency between softwares. (R1)

Page 17

Modifiability – Prevent ripple events

Scenarios Analysis

Architecture Comparison Ef-fect

Pipe-filterBecause the filter can communicate only by the pipe, pipe-filter ar-chitecture is appropriate to this scenario. one characteristic of pipe-filter is that it can perform the computation by combination of filters.

+

Client-serverClient should know the service what it calls to receive. Service modification of server may require partial or entire modification of the client.

-

Page 18

Testability – Built-in monitor

Scenarios Analysis

Scenario No. : 6 Scenario: Fault protection system is verified by each module.

Attributes Testability

Environment Design or development stage

Stimulus Architecture

Response Allow to accessing status of modules. Response measurement Component returns status of performance capability, and etc.

Architectural decision Sensitivity point Tradeoff point Risk element Non-risk element

Built-in monitor S1 N1

Basis

- Using built-in monitor, a component can maintain various status which is accessed by their interfaces.

- More information provides higher testability. (S1) - Logging status can consume more resources, but, normally, logging

activates only for testing. (N1)

Page 19

Testability – Built-in monitor

Scenarios Analysis

Architecture Comparison Ef-fect

Pipe-filter Built-in monitor can be realized in informal shape of pipe-filter ar-chitecture. -

Client-serverIn client-server architecture, built-in monitor can be implemented easily by inserting the client which is in charge of Q&A about its status.

+

Page 20

Availability – Repair time

Scenarios Analysis

Scenario No. : 7 Scenario: Fault protection system detecting its fault.

Attributes Availability

Environment Failure mode

Stimulus Fault protection system produce inappropriate value

Response Fault protection system corrects wrong value. Response measurement System availability with specific rates.

Architectural decision Sensitivity point Tradeoff point Risks Non-risks

Active redundancy S1 T1 N1

Voting S2 T2 R1

Basis

- Redundant components response to events at same time. - Number of redundant components affects availability. More redundant

increase availability. (S1) - However, if this redundant is process level redundant, the system

performance may be decreased. Generally, more process consumes more resources (e.g., CPU time). (T1)

- If a component has failure, other components may still operational. (N1)

- A voter sense abnormal operation of a process, it use majority voting scheme to correcting fault.

- Synchronization is important issues on voting scheme. (S2) - If processes use same sequence and algorithms (or flow), voting cane

detect only processors faults. If each processes consist of different sequence and algorithm (or flow), testability will be decreased. (T2)

- If faults in voter can lead to failure of entire system.

Page 21

Availability – Repair time

Scenarios Analysis

Architecture Comparison Effect

Pipe-filter In pipe-filter architecture, filters operate independently from each other thus, triplex system can be implemented by just adding three identical filters and connect them each other. +

Client-server Triplex system can be realized by replicating same clients. +

Parameter checker

Parameter checker

Parameter checker

Voter

Parameter checker

Parameter checker

Parameter checker

Voter

Pipe and Filter Client/Server

Page 22

Measurement metrics

+ = 3, - = 1

Performance = x 1, Availability = x 0.9

Modifiability = x 0.8, Testability = x 0.7

Rating

Architecture Rating

Pipe-filter 1.37

Client-server 2.48

Page 23

Client-server Architecture Approach

Architecture Overview– client / sever

Database Server(Predefined

operating value)

Fault Detection Server

ParameterChecker

LocationFinder

Component

Isolation Server

IsolationManager

IsolationMechanismAnalyzer

IsolationAgent

Recovery Server

RecoveryManager

Database Server(Backup & Instruction

mechanism)

Page 24

Thank you!