Clymer_4

Simulation-Based Engineering of Complex Systems

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

1

Dr. John R. Clymer, INCOSE Fellow

University of WaterlooOctober 6-7, 2010

2

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

3

Types of Complex System Interactions

• Process SynchronizationOne or more process instances must wait while

another process completes a task• Resource contention

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

• Communication and adaptationOne process instance sends a message to another

process instance that is then used to decide an action

4

Example Process to Study System Interactions

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

A1

B C

A2AND AND

5

Timeline Demonstrates Types of Complex System Interactions

JOB1 JOB2 JOB3

A1

B C

I A2

WA1 A1

B

WA2

C

B

WA2

WA1

C

I

A1

A2

I

Synchronization:Split and Assemble

Resource Contention

Communication And

Adaptation

A2

6


• Types of process interactions• How EXTEND has been modified to implement the

OpEM language – Process identifiers and their Use– Timeline analysis of example process



• Summary

7

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

8

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.

9

JOB1 JOB2 JOB3

A1

B C

I A2

WA1 A1

B

WA2

C

B

WA2

WA1

C

I

A1

A2

I

Process=2,Duplicate1=1






• Process, Duplicate, and Level are integers

• Remember: Duplicate1 for level 1, Duplicates 1&2 for level 2, and Duplicates 1,2, & 3 for level 3 of split

Process Identifiers Allow Multiple Process Instances Using Same Block Structure to be Executed

Duplicate1 models

multiple jobs at level 1

Process=1Job Arrival

10






• Summary

11

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

12

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.

13



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

14

Begin & End Event Blocks

• 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.

Begin Event Block

End Event Block

15


• 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



16

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

• Note in the timeline that both dupl1 and dupl2 of the process identifier are required to properly perform level 1 and 2 assemble functions

Level 1Split

Level 2Split

Level 1Assemble

Level 2Assemble

17

Job Arrival Process

• Job Arrival Process interactively generates a new job execution process item every 8 simulated time units

18






19

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

Interaction

• 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.

Wait Logic for Task A1

Allocate Resource A

DeAllocate Resource A

20


• Control the Simulation: OpEMCSS ExecutiveS Block • Define a system process instance: Begin and End of




21

Hierarchical Context Analysis Block

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

Hierarchical Block Hierarchical Block

Inside Hierarchical Block

Inside Hierarchical Block

22

Blocks Work Together to Achieve Communication and Adaptation

• 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).

First Step:Set

“StartTime”Local Attribute

toCurrent Time

Second Step:Search for

global minimum

“StartTime”

Third Step:Make

“MinStartTime”Global

23

Exercise: Run Model in Trace Mode and Verify How ExtendSim +OpEMCSS Works

ModelScoreboard

ContainsMOEs and

MOPs

• 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

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 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.

Change Process “C” Duplicate “C” in Split 2 from 1 to 2

Change Assemble

Logic

25






• Summary

26

Define a System Problem Using Levels of System Description

• 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.

27

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

28

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

29

Define the System to be Evaluated and Describe System Scenario

• 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.

Ships arrive and enter

queue

When dock is available, tug moves ship to

dock

When loading and unloading is complete,

tug moves ship out of harbor

30

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)

31

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

32

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

33

Step Eight of Requirements Analysis• Develop a directed graph model diagram on the computer screen

using OpEMCSS and ExtendSim

34

Step Nine of Requirements Analysis• Generate traces to verify and validate model and modify the

directed graph model diagram until satisfied.

35

Step Ten of Requirements Analysis• Execute model to achieve requirements analysis

objectives.

36






• Summary

37

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.

Documents

Clymer_4