Post on 13-Dec-2015
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)
ModifiabilityPrevent rippleevents
Fault protection software can be added into existing fault protection software or replaced or eliminated
[M, M]
Availability Repair timeFault 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. : 1Scenario: Upper layer component checks parameter of lower layer components for detecting faults
Attributes Performance
Environment Normal operation
Stimulus Result parameter of operation
Response 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-server
Server 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 ComparisonEf-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-serverIt 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 ComparisonEf-fect
Pipe-filterContext switching cannot be performed on the data which is al-ready being processed in pipe-filter architecture
-
Client-serverIn 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 ComparisonEf-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 ComparisonEf-fect
Pipe-filterBuilt-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)