Clymer_4 by Waterloo Institute for Complexity and Innovation

Simulation-Based Engineering of Complex Systems Dr. John R. Clymer, INCOSE Fellow

Module 4: Simulation of Complex-Sensitive Systems (CSS)

University of Waterloo October 6-7, 2010

Module 4: A Tool for Modeling Complex Systems • Types of process interactions • How ExtendSim has been modified to implement the OpEM language – Process identifiers and their Use – Timeline analysis of example process • How blocks work together implement OpEM language • How to model a system problem using OpEMCSS

• Summary

Types of Complex System Interactions â&#x20AC;˘ Process Synchronization

One or more process instances must wait while another process completes a task

â&#x20AC;˘ Resource contention

One or more process instances must wait while another process uses a resource

â&#x20AC;˘ Communication and adaptation

One process instance sends a message to another process instance that is then used to decide an action 3

Example Process to Study System Interactions A1

AND B

AND

A job request arrives every N units of time • Tasks A1 and A2 share resource A as noted by same color • Task B exclusively uses resource B • Task C exclusively uses resource C 4

Timeline Demonstrates Types of Complex System Interactions JOB1

JOB2

A1 B

JOB3

Communication And Adaptation

WA2 A2

WA1

A1 B

Synchronization: Split and Assemble

Resource Contention

WA2

C WA1 B

A1 C

Module 4: A Tool for Modeling Complex Systems • Types of process interactions

• How EXTEND has been modified to implement the OpEM language – Process identifiers and their Use – Timeline analysis of example process

• How blocks work together implement OpEM language • How to model a system problem using OpEMCSS • Summary

How ExtendSim has been modified to implement the OpEM language • Basic ExtendSim Discrete Event (DE) library blocks model transactions flowing through a network of queues and servers. • Basic ExtendSim DE blocks can only access local attributes that are associated with the current item passing through the block • Basic ExtendSim DE blocks can not synchronize the flow of multiple items flowing through the network 7

ExtendSim Models Items Moving Through a Network of Blocks • An OpEM model employs a sequence of states and events to represent each process instance or thread. – States consist of the discrete state (defines current state of affairs of the process) and state variables. – State variables represent structural and operational conditions of the system. – OpEM maps onto ExtendSim using an item for each process instance or thread. • ExtendSim maintains a set of indices specifying all items currently in the model where each item consists of all information needed to describe a process instance. • A single number is not sufficient to identify an item moving through the model blocks describing a process instance. 8

Process Identifiers Allow Multiple Process Instances Using Same Block Structure to be Executed Process=1 Job Arrival JOB1

JOB2

A1 B

Process=3, Duplicate1=2 Process=3, Duplicate1=3

WA2 A2 Process=2, Duplicate1=2

WA1 Process=3, Duplicate1=1

Process=2, Duplicate1=1

JOB3

I A1 B

Duplicate1 models multiple jobs at level 1

WA2

C WA1

A2 Process=2, Duplicate1=3

and Bâ&#x20AC;˘ Process, Duplicate, I Level are integers C â&#x20AC;˘ Remember: Duplicate1 for level 1, Duplicates 1&2 for level 2, and Duplicates 1,2, & 3 for level 3 of split 9

Module 4: A Tool for Modeling Complex Systems

• Types of process interactions • How ExtendSim has been modified to implement the OpEM language – Process identifiers and their Use – Timeline analysis of example process • How blocks work together implement OpEM language • How to model a system problem using OpEMCSS • Summary 10

How blocks work together to implement OpEM language • Control the Simulation: OpEMCSS ExecutiveS Block • Define a system process instance: Begin and End of Simulation Run or Replication • Define concurrent processes: Split & Assemble • Model time in a discrete state: Wait Until Event and Reaction Time Event • Communication and Adaptation : Local Event Action, Context Sensitive System Event Action, and Global Event Action blocks Work Together

Simulation OpEMCSS ExecutiveS block

ExecutiveS is modified version of the ExtendSim Executive Block

• The OpEMCSS ExecutiveS Block controls moving objects, decides when to evaluate wait logic, and controls all event sequencing. –ExtendSim Executive Block only controls event sequencing.

• NOTE: This block must always be placed in the upper left-hand corner of the model with all other blocks to the right. 12

Begin & End Event Blocks Begin Event Block

• •

End Event Block

Begin Event Block lets us start the model. It sets all initial states and contexts as shown in the dialog box. End Event Block lets us stop the model. It also collects any statistics from the model’s execution. – In this example the dialog box is setup to compute average through-put. 14

Split Action & Assemble Performed At Two Levels: Job Level 1 and Job Task Level 2 Level 1 Split

Level 2 Split

Level 1 Assemble

Level 2 Assemble

â&#x20AC;˘ Note in the timeline that both dupl1 and dupl2 of the process identifier are required to properly perform level 1 and 2 assemble functions 16

Job Arrival Process

â&#x20AC;˘ Job Arrival Process interactively generates a new job execution process item every 8 simulated time units 17

Wait Until Event and Reaction Time Event Blocks Work Together to Model Resource Contention Interaction Allocate Resource A

DeAllocate Resource A

Wait Logic for Task A1

•

Logic is “( (RA >0) && (MinStartTime == StartTime) )” where RA is available(1) or busy(0), “StartTime” is a local attribute defining when wait time started, and “MinStartTime” is a global attribute defining minimum global start time for all concurrent processes waiting. 19

Hierarchical Context Analysis Block

Hierarchical Block

Inside Hierarchical Block

â&#x20AC;˘

Hierarchical Block

Inside Hierarchical Block

Context Analysis hierarchical block contains three OpEMCSS blocks that implement communication resource allocation data. 21

Blocks Work Together to Achieve Communication and Adaptation Second Step: Search for global minimum “StartTime” First Step: Set “StartTime” Local Attribute to Current Time

• •

Third Step: Make “MinStartTime” Global

Context Sensitive System Event Action block searches through selected concurrent processes to extract attributes that measure context-sensitive relationships. Global Event Action block allows local attributes to be made global (same value available to selected concurrent processes). 22

Exercise: Run Model in Trace Mode and Verify How ExtendSim +OpEMCSS Works Model Scoreboard Contains MOEs and MOPs

â&#x20AC;˘ Run model in trace mode, draw timeline from trace, and compare to slides 6 and 10. Verify model scoreboard values using your time line. 23

Exercise: Run Modified Model in Trace Mode and Verify How ExtendSim+OpEMCSS Works Change Process “C” Duplicate “C” in Split 2 from 1 to 2

• •

Change Assemble Logic

Change Process “C” Duplicate “C” in Split 2 from 1 to 2 and describe how duplicate2 is used to model multiple threads for process 3 at level 2. Run model in trace mode, draw timeline from trace, and compare to slides 6 and 10. Verify model scoreboard values using your time line. 24

Define a System Problem Using Levels of System Description

â&#x20AC;˘ â&#x20AC;˘

Requirements analysis proceeds from the top-down using levels of system description: Mission, Function, Parallel Process, Mission Attribute Interface (KPPs and rules), and Resources. Requirements are not understood until the resources level is reached where a simulation model provides the derived requirements such as values for KPPs, numbers of resources, and system management rules. 26

Model Development Tasks Perform Requirements Analysis Using 5 Levels of System Description • Define the system to be evaluated and describe system scenario or context. • Define the missions and mission objectives of the system and measures of effectiveness. • Define objectives for study of each system solution using the model. • List tasks that must be performed to achieve each mission objective. • Subdivide tasks into periods of time represented by states 27

Model Development Tasks Perform Requirements Analysis Using 5 Levels of System Description (Continued) • Group purely sequential tasks into the same processes and tasks that can be performed concurrently into separate processes. • Develop time-lines of concurrent states that describe system operation and assist visualization of system operation. • Develop a directed graph model diagram on the computer screen using OpEMCSS and ExtendSim • Generate traces to verify and validate model and modify the directed graph model diagram until satisfied. • Execute model to achieve requirements analysis objectives 28

Define the System to be Evaluated and Describe System Scenario Ships arrive and enter queue

When loading and unloading is complete, tug moves ship out of harbor

When dock is available, tug moves ship to dock

â&#x20AC;˘ Scenario: System is a seaport in which ships arrive and enter the system by anchoring outside the breakwater area in the ship queuing area shown. 29

Steps Two and Three of Requirements Analysis • Define Mission and MOEs: What the system must do to solve the user’s problem and how well it must do it. – Mission: Move cargo in and out of harbor – MOE1: Minimize wait time spent in ship queue – MOE2: Maximize harbor resource utilization

• Define Model Objectives: What questions model must answer dictates model details.

– Determine optimal ship arrival rate for specified alternative system KPP values (derived requirements tradeoff analysis) 30

Steps Four and Five of Requirements Analysis • List tasks that must be performed to achieve each mission objective. – Move ship to dock – Move ship from dock – Unload/Load ship • Subdivide tasks into periods of time represented by states – ARV: inter-arrival time for ships to enter system – WTD: wait for dock to become available – WTG: wait for tug boat to move ship into dock – MVD: tug move ship to dock – LDT: unload and load cargo – WTB: wait for tug boat to move ship away from dock – MVO: move ship out of harbor 31

Steps Six and Seven of Requirements Analysis • Group purely sequential tasks into the same processes and tasks that can be performed concurrently into separate processes. –Ship Arrival Process: ARV –Ship Operation Process: WTD, WTG, MVD, LDT, WTB, MVO

• Develop time-lines of concurrent states that describe system operation and assist visualization of system operation.

WTB

Step Eight of Requirements Analysis â&#x20AC;˘ Develop a directed graph model diagram on the computer screen using OpEMCSS and ExtendSim

Step Nine of Requirements Analysis â&#x20AC;˘ Generate traces to verify and validate model and modify the directed graph model diagram until satisfied.

Step Ten of Requirements Analysis â&#x20AC;˘ Execute model to achieve requirements analysis objectives.

Summary Module 4: A Tool for Modeling Complex Systems • How OpEM Language Blocks Work to Model Interacting Concurrent Processes • How to Apply Ten Steps of Requirements Analysis to Build a Model and Apply It to Perform Tradeoffs and Derive Requirements. The third (and final) step to understand a Complex or Adaptive Intelligent System is to iteratively improve requirements’ clarity through simulation. 37