Detecting Emergent Behavior In Distributed Systems Caused By Overgeneralization

1. Detecting Emergent Behavior In Distributed Systems Caused By Overgeneralization SeyedehmehrnazMireslami, Mohammad Moshirpour, Behrouz H. Far Department of Electrical and Computer Engineering University of Calgary, Canada {smiresla, mmoshirp, far}@Ucalgary.ca

2. Outline Introduction Background Problem Solution and Challenges Distributed System Example Behavioral Modeling Identical States Semantic Causality and State Values Detecting Emergent Behavior Criteria for merging identical States Conclusion and Future work

3. Introduction Emergent behavior is a vital problem in distributed systems which leads to unexpected behaviors and major problems. Detecting emergent behavior in early design stages reduces the deployment costs significantly. Overgeneralization happens as the result of behavior model synthesis and depends on the assumptions of the process. Designing an automated algorithm for detecting emergent behaviorsis beneficial.

4. Background Message sequence charts have been widely used for analyzing the behavior of the system. In order to explicitly model the system behavior, state machines are used. Blending scenarios that are used for describing the system, is necessary since it provides a comprehensive overview of the system behavior.

5. Background (Ctd.) Two methods are proposed for combining the scenarios: State identification: In state identification, the components of the scenarios are first modeled with different states in the state machines. Then, similar component states are identified in a set of scenarios and combined in different state machines to enable the scenarios to merge Scenario composition using high-level MSC graphs: Scenarios are split to smaller parts with lower complexity. Then, high-level MSC graphs are used to blend the smaller sequence of behavior since they are simpler to manage.

6. Problem Merging all similar states to achieve only one state machine for all of the scenarios is proposed for improving the synthesis of behavior models. However, this method takes too much time because of merging all the common states which is not always necessary as not all the common states lead to occurrence of emergent behavior.

7. Solution and challenges In a message sequence chart MSC, Finite State Machines (FSMs) are built for any component. Merging partial behaviorsfrom different scenarios automatically: Define a mechanism to identify identical states of components in different scenarios and assign state values. Considering three criteria before merging identical states in order to save the costs. Designing an automated method to deal with the defects which are caused by behavior model synthesis.

8. Distributed System Example Mine Sweeping Robot (prototype) Navigates through a city-like course Navigates using sensory information (i.e. Battery , GPS data) Identifies and flags the location of landmines To cope with all of the robots functionalities two multi-core CPU units are utilized The units are built on separate boards connected via a simple but reliable connection protocol Two CPUs interact using the client-server architecture

9. Distributed System Example (Ctd.) Partial behavioral scenarios for the robot

10. MSC1 MSC2 MSC3 Behavioral Modeling MSCn Behavioral Modeling For a given system component, the process of constructing a finite state machine (FSM) from message sequence charts (MSCs) that component appears in, is referred to as behaviour modeling. The state machine includes all the messages that are received or sent by that component. FSM

11. Behavioral Modeling Example The behavior of the component is described by producing all the state machines of that system component.

12. Behavioral Modeling (Ctd.) During construction of behavioral model of a component, identical states must be identified. What is identical state? A state of a component that remains the same during execution of multiple scenarios. Why is it important? Identical States in the constructed behavioral model are where emergent behavior can potentially occur.

13. Identical States Other solutions: Merge two states if their incoming transitions are the same. Annotate all the messages in the scenarios with values of some “important” variables. Merge two states if their incoming transitions are the same and the values of system variables are also the same. Let the domain expert decide! Our solution Using semantic causality and state values

14. Semantic Causality and State Values Semantic causality: A message m is a semantic cause for message n, if a component i has to keep the result of the operation m in order to perform n. Semantic causality is an invariant property of the system under construction. To detect identical states, we assign values to the states of the FSMs based on Semantic Causality. State values: First, the initial and final states of a FSM are defined. Then, the states value of the state m is defined depending on the transitions that come after this state.

15. Detecting Emergent Behavior Identical states are merged if the new behaviour that could be generated as the result of this merge is allowed by the system’s architecture expressed by scenarios.

16. A q Criteria for merging identical states B Assume two identical states qs and qt of two state machines A and B for the process iare merged into a single state q. The emergent behavior ...asbt+1... is obtained if:

17. Criteria for merging identical states (Ctd.) bt+1is a send message for component i. bt+1is a receive message for iand in a scenario m there is a process j where bt+1 could be sent by j to ieven when as+1 does not happen. Furthermore, process i must receive bt+1 after as+1. After bt, component i stops. qt is a final state for B. If as+1 is a send message for i, then i has two options when it is in a state q: Send message because of state machine A. Component i must continue with message as+1. Stop to send because of state machine B. So, emergent behavior ...as will happen.

18. Example There is no emergent behavior (none of the criteria happens )

19. Conclusion and Future Work Detecting unwanted behavior during the design phase is about 20 times cheaper than finding them during the deployment phase. Many of the methodologies utilized to analyze system requirements and design documents introduce a certain amount of overhead to the software development lifecycle. This work provides a systematic approach to analyze system requirements for defects, while saving on overhead by replacing ad-hoc methodologies with automated ones.

20. Conclusion and Future Work In this work, a new algorithm is developed for behavior model synthesis and emergent behavior detection while preventing overgeneralization. The future work may be implementing the proposed algorithm to provide an automated tool. Moreover, this work can be utilized as part of a comprehensive framework to analyze system requirements and design.