Intelligent Coordination Design in Software Systems

1. Intelligent Coordination Design in Software Systems Srini Ramaswamy Computer Science - UALR srini@acm.org/srini@ieee.org Nothing endures but change [Heraclitus]

2. Analogy: Snowflake symmetry • Growth in each arm affects the growth in other arms • Grow independently in a dynamic environment (rapidly varying temps, humidity, etc.) • Spatially homogenous for a single flake • Locally high level of visual similarity - Each arm responds in identical ways to identical conditions • Larger environmental scales  lack of correlation between the shapes of different snowflakes • Locally homogeneous – globally heterogeneous

3. Intelligent Coordinating Entities • Structure: Uniform, scalable design • Behavior: Localized decision-making behaviors, reinforced with • Dynamic aggregated learning models and information-sharing models • Uniform (locally homogeneous) • Symmetric (repeatable) • Well-defined & Scalable • Vorticity: Relies on a communication-centric framework • Simple, structured, well-defined coordinations

4. Major Topic Outline • Entity Modeling & Design • Coordination Design • Multi-tiered Intelligent Control • Examples A moments insight is sometimes worth a life experience. Thomas Fuller

5. speed-up: time to complete relative to single programmer F(N) = N2 t(1) Hierarchical: Bottom up data sharing top-down decisions flow Coordination time: log N  N Democratic: All share data, All participate in decisions Coordination time: N2 F(N) = N relative time to complete job (inverse of speed up) Coordination overhead, F(N) 1/ N F(N) = log N N number of performers Practicality of Coordinated, Hierarchical Abstractions Slide adapted from : Bernard P. Zeigler, Univ. of Arizona

7. OO: Encapsulation of resource (at some granularity) and its associated functions (strive for norms). • Needs: • Service Interface: Mechanism to publish service availability • Info. Sharing Interface: Critical layer missing in current SOA • Major functions • Mechanisms to identify critical decisions for communication • Mechanisms to swiftly make a decision, apply reinforcement learning based validation – support for evolutionary behaviors

9. Major Topic Outline • Entity Modeling & Design • Coordination Design • Multi-tiered Intelligent Control • Examples

10. Learning from Biology (Symbiosis) ‘The major source of evolutionary novelty is the acquisition of symbionts - the whole thing then edited by natural selection’ i.e. Single-celled creatures evolved by symbiosis.Dr. Lynn Margulis

11. Factors to be Considered • Decision Complexity (selection) • From simple (atomic) to complex / aggregated decisions • Information Sharing Complexity (Symbionts) • Individually aggregated over time – residual/reinforcement effect • In pockets, share info. with group appropriately

12. Addressed by information sharing mechanisms Addressed by hierarchical abstractions / task focused design

13. Key Premises • Ability for basic communication in every entity • Information transfer (on “key” decisions) forms the basis (need checks) for intelligent coordination • Sharing timely information regarding key decisions (time or response checks) defines successful coordinations between entities • Other application / domain dependent factors: Usability, reliability, availability (-bility checks)

15. Basic Communication Strategies • Techniques • Peer to peer, full or selective broadcasts Selective broadcasting introduced in: B. T. Barcio, S. Ramaswamy, K. S. Barber, "An Object Oriented Model Based Approach to Software Systems Development", 1995 ASQC Intnl. Conference on Software Quality, Oct. 1995 B. T. Barcio, S. Ramaswamy, K. S. Barber, "An Object-Oriented Modeling and Simulation Environment for Reactive Systems Development", International Journal of Flexible Manufacturing Systems, Volume 9, No. 1, Jan 1997, pp. 51-80

16. Basic Communication Strategies • Issue: Determine what needs to be communicated • Base case • Normal (equilibrium state) – a priori defined normal states – system designed • Information pertaining to errors / critical decision choices needs to be communicated • Dynamic evolution • Allow for emergent behavior

17. Needs for Info. Sharing Design • Increased # decisions  increased design complexity • Software design quirks also lurk in corners and problems normally “appear” due to insufficient “testing and monitoring” at the seams • Seams may be deep and nested • Information about nested decision choices embedded at these seams are critical to designing good information sharing systems (apply “hierarchy locks” to define security / sharing privileges in hierarchical abstractions) • Petri Net transition invariants - an useful means for enabling coordinations

18. Using Petri Net Invariants: Reader's Writer's Problem (Readers) P1 P3 T3 T1 2 P4 P2 P5 2 T4 T2

19. Petri Net Invariants Example: Reader's Writer's Problem (Writers) P1 P3 T3 T1 2 P4 P2 P5 2 T4 T2

20. Petri Net T-Invariants: Reader's Writer's Problem (Readers Loop) P1 P3 T3 T1 2 P4 P2 P5 2 T4 T2

21. Petri Net T-Invariants: Reader's Writer's Problem (Writers Loop) P1 P3 T3 T1 2 P4 P2 P5 2 T4 T2

22. Coordination Design: Login Process Begin Login User ID & Password Verify Invalid Password Check Mail Mail Password Try Again Authenticate

23. Coordination Design: T-Invariant Coverage First Invariant (correct Login) T3, T7 T1, T2, T9 Second Invariant (incorrect Login) Third Invariant (forgot password) T6 T4, T5, T8 • “n” tries and lock technique based on T6

24. Coordination Design: Login Process • Knowledge about T3, T5 and T6 can help design much better coordination behaviors • sufficient to understand (monitor) and predict systems’ evolutionary behavior. • T3: Key to maintenance and profiling - shared for logging maintenance and predicting usage patterns • T5: Key to behavior analysis – Shared for prediction of user behaviors (ex. forgetfulness) between periods of usage • T6: Key to identifying intrusions – shared appropriately with live intrusion detection modules Bottomline: Appropriate communication of embedded knowledge (~key decisions) supports intelligent behavior evolution

25. ICE ≠ SOA • Modeling • Specs: Semantic behavior, not technical (Unlike SOA) • Coordination requests: complied with or fails (like SOA) • Explicit boundaries • Trust boundaries: • Entities adapt and modify from apriori defined trust boundaries with other entities in the environment (unlike SOA) • Data boundaries (unlike SOA) • Entities selectively share “black box” information – expected to be published by service (key decision information) • Security boundaries (like SOA) • Entities may/should impose security (like SOA) • Key issue, however, is not security, but selective information transfer • Coordination can be unavailable & takes time

26. ICE ≠ SOA • Autonomous: self-governing, self-determination • Entities respond to “requests”, not “commands” (like SOA) • Location transparency – request independence (like SOA) • Allows flexible, dynamic ‘context-dependent’ communication - selective or broadcast (unlike SOA) • Encapsulated & loosely coupled - via provided services (like SOA) • Entity is not independent of caller (s) (unlike SOA) • Coordination is defined (SOA - Contract Exchange) • Schema & Contract (a priori design) • Request parameters / result defined by schema • Contract defines procedures for coordination • Apriori defined multi-level information ‘sharing’ structure • Logical boundary

27. Tool Support

30. Reduced access Full access No access Emergent BehaviorExample

31. Emergent BehaviorExample Proceed w/ best (pre-determined) decision choice Start reinforcement / support analysis • If decision supported, • continue • Else roll back and proceed • with best supported • decision • Update path choice info. • Apply aging / evolution criteria for best choice determination

32. With evolution, the normal state set grows over time with stronger support • Creates a psuedo-normal state

33. Major Topic Outline • Entity Design • Coordination Design • Multi-tiered Intelligent Control • Examples The journey is the reward [Tao]

35. 3-Tiered Intelligent Coordination Structure • Intelligence – ability to identify problems and subsequently act / react to situational contexts • 3 tier design architecture • Lowest Tier: Handle routine disruptions • Middle Tier: Manage resources, support scalability • Top Tier: Long term planning / analysis • Each tier builds on the previous levels • Provides a framework for self-adaptation, group intelligence and adaptive optimization • Supports distributed deployment • Supports scaling behaviors

36. SOA work w/ Malarvannan, Cybelink Systems, LLC

37. Major Topics Outline • Entity Design • Coordination Design • Multi-tiered Intelligent Control • Examples Seekers are finders [Afghan]

38. Example: MARS C O O R D I N A T I O N I N F O R M A T I O N • Modeled and analyzed using Petri nets • Enhance coordination by leveraging operational level intelligence

39. Alessandro Farinelli; Luca Iocchi; Daniele Nardi. “Multirobot Systems: A Classification Focused on Coordination.” Transactions on Systems, Man, and Cybernetics-Part B: Cybernetics, October 2004, vol. 34, no. 5. Student: Joe Ernest

40. Results • Software framework available for • Multithreading • Modified pair-wise communication in SMiRF (Serial Miniature RF Link) firmware to a 5-layer protocol stack implementation for wireless communication • Error handling needs improvement • Authentication non-existent • Mobile agent platform • Implemented & tested on Mark III’s

41. Example: Job shop Scheduling work w/ Ning Liu, Dr. Abdelrahman, TnTech

42. Results • Stable performance • Independent agents • Decentralized, with minimum global information (number current jobs and machines) • no master/slave relationships for dynamic job shop scheduling in distributed manufacturing systems • Robust during unpredictable job arrivals • Good, stable performance in static job shop scheduling • Stable, robust in dynamic job shop scheduling with unpredictable job arrivals

43. Extended Common Coupling Software maintainability and reusability affects Common coupling Definition-use analysis used for combine applied to Common coupling in kernel-based software defined generate New common coupling categories Kernel-based software tested on can be applied to Open source operating systems work w/ Dr. Ligou Yu, IUSB

44. Coupling Results • Extended common coupling types: Stamp-common (A), data-common (B), stamp-control-common (C) and data-control-control (D) coupling • Studied global variable “current” in Linux • Appears in 18 kernal (114D, 382U)and 1071 non-kernal (1403D, 6785U) modules • 68%(A), 12%(B), 11%(C), 9%(D), 0%(pure common coupling) • More complex to maintain

45. Impact of Better Algorithms Slide Source: David Keyes, Columbia University

46. Conclusions • Overlaying hierarchical info. sharing software solutions onto existing implementation schemes (ex. SOA) • Support intelligent behaviors and improve scalability • Simple framework for enabling good coordinations • Similar to fractals • Self-similarity: Smaller pieces are “similar” to larger pieces • System is made up of a few big entities, many medium sized entities, and a huge number of tiny entities, statistical self-similarity between log (Number) versus Log(size) for all entities • Scaling: Value measured depends on the resolution level • Tiered intelligence structure with information sharing modeled and analyzed using Petri nets

47. Growth (learning new behaviorscommunicating learned behaviors) in one arm (entity) affects growth in other arms Faceting (simple a priori defined behaviors) affects growth when the crystals are small Surface tension / inward attractive (molecular) force (group behaviors to build high vorticity (due to “good” cohesion and coupling support for information transfer), dynamic coordination mesh) helps build stability Phonons (determination ofnecessary information to be communicated / group membership determination) support structural evolution Branching instability (errors / disruptions in a dynamic operating environment) affects growth (adaptation) in larger forms The Snowflake Analogy Revisited

48. Questions / Discussions • Currently Funded Projects / Activities • Acxiom Corporation (06-07) • SME Driven Trainable Matching Engine • NSF: MRI (06-09) • Arkansas ICE Emulation Laboratory • US DOT Eisenhower Fellowship (06-09) • Immersive Frameworks for Interactive Research, Support and Training • NASA Space Grant Consortium (06-07) • Development of Algorithms for Cooperating Multi-robotic Systems