1 Intelligent Coordination Design in Software Systems Srini Ramaswamy Computer Science - UALR [email protected]@acm.org/[email protected]@ieee.org Nothing

1

Intelligent Coordination Design in Software

SystemsSrini Ramaswamy

Computer Science - [email protected]/[email protected]

Nothing endures but change [Heraclitus]

2© Srini Ramaswamy, Professor & Chairperson ● Computer Science ● Donaghey College of Information

Science and Systems Engineering ● University of Arkansas at Little Rock ● Little Rock ● AR 72204 September 19th 2006 Phone 501-569-8130 ● Fax: 501-569-8144 ● Email: [email protected] / [email protected] / [email protected] Wayne State Univ.

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

Srini Ramaswamy

Surface tension Phonons (mode of vibration occurring in a rigid crystal lattice)



Intelligent Coordinating Entities

• Structure: Uniform, scalable design

• Vorticity: Relies on a communication-centric framework

• Behavior: Localized decision-making behaviors, reinforced with

• Dynamic aggregated learning models and information-sharing models

Simple, structured, well-defined coordinations

• Uniform (locally homogeneous)

• Symmetric (repeatable)• Well-defined & Scalable



Major Topic Outline

Entity Modeling & Design Coordination Design Multi-tiered Intelligent Control Examples

A moments insight is sometimes worth a life experience. Thomas Fuller



Practicality of Coordinated, Hierarchical Abstractions

Hierarchical:

Bottom up data sharing top-downdecisions flow Coordination time:log N N

Democratic:

All share data, All participate in decisionsCoordination time: N2

Slide adapted from : Bernard P. Zeigler, Univ. of Arizona

Nnumber of performers

speed-up: time to complete relative to single programmer

)(/1)( NaFNNt

t(1)

F(N) = N2

F(N) = N

F(N) = log N

1/ N

relative time to complete job (inverse ofspeed up)

Coordinationoverhead, F(N)





OO: Encapsulation of resource (at some granularity) and its associated functions (strive for norms).

Needs: 1. Service Interface: Mechanism to

publish service availability2. 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





Major Topic Outline

Entity Modeling & Design Coordination Design Multi-tiered Intelligent Control Examples



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



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



Addressed by hierarchical abstractions / task focused design

Addressed by information sharing mechanisms



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)





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



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



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



Using Petri Net Invariants: Reader's Writer's Problem (Readers)

P1

P4

P3

P2 P5

2

2

T2

T3

T4

T1



Petri Net Invariants Example: Reader's Writer's Problem (Writers)

P1

P4

P3

P2 P5

2

2

T2

T3

T4

T1



Petri Net T-Invariants: Reader's Writer's Problem (Readers Loop)

T2

T3

T4

P1

P4

P3

P2 P5

2

2

T1



Petri Net T-Invariants: Reader's Writer's Problem (Writers Loop)

P1

P4

P3

P2 P5

2

2

T2

T3

T4

T1



Coordination Design: Login Process

Begin Login

User ID & Password

Verify

Check MailInvalid Password

Mail PasswordTry Again

Authenticate



Coordination Design: T-Invariant Coverage

T1, T2, T9

T3, T7

T4, T5, T8T6

First Invariant (correct Login)

Second Invariant (incorrect Login)

Third Invariant (forgot password)

“n” tries and lock technique based on T6



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

Coordination Design: Login Process



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



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

ICE ≠ SOA



Tool Support







Emergent BehaviorExample

Red

uced

acc

ess

Ful

l acc

ess

No

acce

ss



Proceedw/ best (pre-determined) decision choiceStart reinforcement / supportanalysis

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

Emergent BehaviorExample



• With evolution, the normal state set grows over time with stronger support

• Creates a psuedo-normal state



Major Topic Outline

Entity Design Coordination Design Multi-tiered Intelligent Control Examples

The journey is the reward [Tao]





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



SOA work w/ Malarvannan, Cybelink Systems, LLC



Major Topics Outline

Entity Design Coordination Design Multi-tiered Intelligent Control Examples

Seekers are finders [Afghan]



• Modeled and analyzed using Petri nets• Enhance coordination by leveraging operational level intelligence

COORDINATION

INFORMATION

Example: MARS



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



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



Example: Job shop Scheduling

J1 Ji JNc…

M1 MMcMm …

Auctioneer Auctioneer Auctioneer

…

…

Prices

BidsXijt

(Subproblem)

(Price-adjustment) Time slots

L

Decision point

tc

Length ofrolling time horizon

work w/ Ning Liu, Dr. Abdelrahman, TnTech



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



Extended Common Coupling

Definition-use analysis

Open source operating systems

Common coupling

Kernel-based

software

Common coupling in

kernel-based software

New common coupling categories

Software maintainability and reusability

tested oncan be applied to

combine

affects

applied to

generate defined

used for

work w/ Dr. Ligou Yu, IUSB



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



Impact of Better Algorithms

Slide Source: David Keyes, Columbia University



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



The Snowflake Analogy Revisited Growth (learning new behaviors communicating 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 of necessary 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

Srini Ramaswamy

surface tension: attraction between the molecules of the liquid, due to various intermolecular forcesVorticity: Amount of "circulation" or "rotation" in a fluid



Questions / DiscussionsCurrently 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

Documents

1 Intelligent Coordination Design in Software Systems Srini Ramaswamy Computer Science - UALR [email protected]@acm.org/[email protected]@ieee.org Nothing