Modeling and Simulation: Exploring Dynamic System Behaviour

Modeling and Simulation: Exploring Dynamic System Behaviour
Chapter 4 A Conceptual Modelling Framework for DEDS Temps de présentation: Objectifs Sujets de discussion Préalables Texte Références Évaluation (3) Site Web du cours (2) Détails du corps enseignant _______________________________________________ 13 acétates – 20 minutes Organisation du cours (3) Histoire des télécommunications (2) Application d’affaires Application pour les domiciles (2) Implications sociales (2) _______________________________________________ 10 acétates – 20 minutes Modèle simple de communications Données vs information Modèle de communication Communication de données _______________________________________________ 4 acétates –10 minutes Les réseaux – quelques définitions (2) Réseaux locaux Réseaux à longue portée _______________________________________________ 4 acétates – 10 minutes Pourquoi une architecture ? Modèle OSI Les 7 couches (2) Organisation du cours Comités de normalisation

Topics of discussion Discrete Event Models
Abstraction of discrete event systems (SUI): recall stochastic processes Entities: abstraction of SUI components (structure) Events: abstraction of SUI behaviour Discrete Event Conceptual Modelling Framework Based on Activity Scanning World View Not a programming environment, but provides a foundation for programming development

Department Store Three shopping areas
Serviced by three service desks for payment Customers enter the store Browse and select items in a shopping area Pay at service desk Can browse and select items in another area Can leave after payment at any desk Comments on description?

Department Store Entities

Events of the Department Store

Activity Based Conceptual Model (ABCMod)
Entities Basic components of the model Describe the various components of the system to be modelled Three broad categories: consumer entity classes, resource entities, aggregate entities Activities Specifies interaction of model entities Defined in terms of events and duration Event defines a point in time where state of the model changes Duration, using a data model, allows the scheduling of events and represents the passage of time for some interaction Represents a specific unit of behaviour Cannot be broken down into smaller units of behaviour Events and duration characterized in terms of constants, parameters, variables, and modules Inputs, Data Models and Outputs Inputs represent impact of external environment Data models provide means of representing autonomous stochastic processes Outputs consists records data for dependent stochastic processes of interest

The ABCmod specification
Θ is a set of consumer entity classes, Ω is a set of service entities (the union of a set of aggregates and a set of resources), Φ is a set of activities. Activity is a unit of behaviour that represents the abstraction of a some purposeful task Has a duration, and results in changes to the model (events) Action is an activity with no duration, simply invokes an event to change the model Interpretation of sets Θ and Ω is flexible Delivery trucks at the department store can be seen as consumers although providing a service to the store Membership of consumer and service entities can become blurred: machines in a manufacturing model are resources when processing parts, but become consumers when they break down and need repair from the maintenance team (a resource entity)

Entities and Model Structure
Consumer entities Entities that flow through the system looking for service represents the set of all consumer entities Sets Ck are disjoint, each set is the collection of entities belonging to an entity class Өk SUI defines n, i.e. number of entity classes Typically transient in system (but not always) Interact directly with resources and aggregates Located in an aggregate or at a resource Resource entities Entities that provide services to consumer entities Service often constrained (causing consumers to wait) Aggregate entities Collection of entities Consumers waiting for service attached to a queue aggregate. Group aggregates typically define a collection of consumers engaged in similar activities, e.g. browsing in a grocery store aisle Exit of the consumer in the queue related to queuing discipline, not so for the group aggregate

Entities in the Department Store
Consumer entity classes Customers, single consumer class Can you think of possible consumer classes? Resource entities Service desk Other possible resources? Aggregates Customer queues Shopping area groups Questions? How is set of shopping areas visited selected and what is order of visitation? Number of servers assigned to each service desk? Can customers balk (queuing discipline)? These questions often arise during conceptual modelling and not addressed initially during the project description phase.

Characterization of Entities: Attributes
Detailed specification (characteristics) of the entities in the sets Θ and Ω Define attributes for each entity type (consumer class, resource, aggregate) Attributes serve as the basis for state variables Attributes selected based on project goal that includes output requirements. Provides the means to specify behaviour Specifications of the dynamic behaviour includes events that describe changes to theses attributes These events are part of the activities and actions in Φ

Consumer Entity Class Attributes
Want to track the existence and status of consumer entities Consumers can produce trail of data (output) Define a set of attributes, mk, for each consumer class Өk Property reflectors: Essential property that has direct relevance to how consumer is treated, e.g.. size Path reflectors: Tracks nodes visited by the consumer, e.g.. counters visited in a deli store. Elapsed-time reflectors: typically for measuring how consumer entity has progressed though the model, e.g.. time waiting in a queue

Consumer Entity Class and Attribute-tuples
Notation: C.consumerName = (attrib1, attrib2, , attribk) C prefixes all consumer entity references, and consumerName identifies the class of consumer Names attrib1, attrib2, used for referencing an attribute value as in C.consumerName.attrib1 Attribute-tuple (set of data values) defines instance of the consumer entity Initially values are set to “nil”, typically set upon arrival of consumer Choice of attributes depend on SUI and project goal As consumers flow through the model, the attribute-tuples are connected to either an aggregate or a resource

Specifying a Consumer Entity Class
Consumer Entity Class: EntityClassName General description of the Consumer Class. Attributes Description AttrName1 Description of attribute AttrName1. AttName2 Description of attribute AttrName2.

Aggregate Entities Collection of consumer entities, i.e. attribute-tuples Consumer entities must be attached to an aggregate or resource entity Also possible to be attached to more than one of these (ex. See the port project). Queue entities Collection of consumer entities waiting for resource Group entities Collection of entities engaged in similar activities

Queue Entity Attributes
Notation: A.queueName = (List, N) A prefixes all aggregate references queueName is specific name for the queue Can also define arrays as in A.BankQueue[i] A.queueName.List[i] is a reference to an attribute-tuple A.queueName.N is a reference to the queue attribute. List – collection of attribute-tuples N – number of entities enqueued Some queue protocol is defined for adding and removing attribute-tuples to and from the queue FIFO – first-in, first-out – queues in a bank Priority schemes (often in combination with FIFO) – queues in an emergency room Can be virtual queue: list of machines waiting to be repaired.

Group Entity Attributes
Notation: A.groupName = (List, N) A prefixes all aggregate references groupName is specific name for the queue Can also define arrays as in A.aisleGroup[i] A.groupName.List[i] is a reference to an attribute-tuple A.group.N is a reference to the queue attribute. List – collection of attribute-tuples N – number of entities in the group Groups have no real protocol for removing or adding consumer entities to the group Typically an event relating the consumer entity to an activity will trigger the removal of the specific entity from the group, e.g. complete shopping in the grocery store aisle.

Aggregate Entity: AggregateName
Aggregate Construct Aggregate Entity: AggregateName General description of the Aggregate (can include description of queuing discipline). Attributes Description AttrName1 Description of attribute AttrName1. AttName2 Description of attribute AttrName2.

Resource Entity Attributes
Typically has an attribute for holding the attribute-tuple of the consumer being serviced Other attributes relate to the activity of servicing or some other state of the resource Busy: servicing a consumer Broken: is no longer in operating condition Notation: R.resourceName = (Client, Busy, Broken) R prefixes all references to resources resourceName can reference a specific resource Can use array notation to reference multiple resources of same type as in R.machine[i] R.resourceName.Client is a reference to the client attached to the resource. R.resourceName.Broken is a reference to the attribute of the resource.

Resource Entity Construct
Resource Entity: ResourceName General description of the Resource. Attributes Description AttrName1 Description of attribute AttrName1. AttrName2 Description of attribute AttrName2.

Model State Variables Apply Property Σ
Resources and Aggregate attributes provides state variables All consumer attribute-tuples attached to resources or aggregates at any time t Behaviour can be expressed in terms of changing these state variables Use presented notation to reference the various entities and entity attributes. Need to specify how to effect the changes – the events and activities

New idea – the ABCmod Structural Diagram
Use a number of symbols to show the structure of the model in terms of the basic constructs Consumer Entity Instances Resources Queue Aggregates Group Aggregates

ABCmod Structural Diagram for the Port Project

Time, Events, and Activities
Dealing with dynamic models Variable t that represents time, used to simulate time across the observation interval Units of t are fixed, seconds, days, years, etc. Specify in the model behaviour Activity: basic construct to represent interactions in the model, some purposeful task Event: points at which states change in the model, eg. Event occurs at start and end of and activity Duration: Elapsed time between events based on a data model that describes time required for some purposeful task

Department Store Behaviour

Observations on Department Store Behaviour
Transitions occur at each event Coincidence of certain transitions A2 and B2 A3 and C2 What other ones? Intervals where the shoppers are engaged in the same activity Where? Shoppers (consumer entities) seize the service desk (resource entity) to start payment activity Pre-condition must be TRUE for payment to start (what?) Payment activity has a duration State variables change value at the start and end of the payment activity Basic conceptual construct: the ACTIVITY

The Activity Captures a unit of behaviour Structure
Represents interaction in the system – note the abstraction Unit is meant to be atomic – does not break down into a number of other activities Structure Initial phase, duration, and a terminal phase Duration: Activity, once “energized” ends after a certain time has elapsed Need not be contiguous, allow for activities to be interrupted Each of the initial phase and terminal phase corresponds to an event specification

The Event Specification
Activated event specification becomes an event Collection of changes to the status of the model All changes occur simultaneously No time is consumed by an event Conditional event Event occurs when certain state conditions are reached, i.e. certain values of state and/or input variables E.g. Activity initial phase, the starting event. Scheduled event Event occurs at a specific time t, independent of model state E.g. Activity terminal phase, the terminating event. Status Change Specification (SCS) Pseudo-code with the tradition conditional statements Specifies how the status of the model changes when the event occurs

The Activity – generic concept
Pre-condition: some logical expression that acquires a TRUE value to start the activity Starting event: an SCS at the start of the activity Required to render the pre-condition false Duration: some duration (tentative) Δ Usually defined via some data module tend= tstart + Δ (where tstart is current time at which Activity starts, i.e., when starting event occurs) Terminating event: an SCS at the end of the activity Framework provides a number of activity constructs: Activity, Triggered Activity, Extended Activity, Extended Triggered Activity, Action, Action sequence

Activity: ActivityName
Activity Construct Activity: ActivityName Precondition Boolean expression that specifies the conditions which initiate the Activity Event SCS associated with Activity initiation Duration The length of the duration (typically acquired from a Data Module that references a data model). SCS associated with the Activity completion No intervention possible on duration

Triggered Activity: ActivityName
Event SCS associated with Activity initiation Duration The length of the duration (typically acquired from a Data Module that references a data model). SCS associated with the Activity completion No pre-condition Must be triggered from within an event of another Activity – normally terminating event (notation - TA.ActivityName) Useful in modelling an activity that unconditionaly follows another (see port project)

Notes on Duration Recall that duration Δ, was defined as tentative
In the Activity and Triggered Activity, Δ is definite In other constructs, extended activities interventions can affect the duration Interventions possible Pre-emption: resources seized by higher priority consumer, e.g. high priority job arrives in a repair shop Interruption: input or change in model state interrupts and activity: a storm that interrupts the progress of a boat in a harbour Effects of interventions on the duration Can alter duration: slow down boat during storm Can create disjointed times to complete duration: boat drops anchor until storm is over Both of the above

Extended Activity Construct
Extended Activity: ActivityName Precondition Boolean expression that specifies the conditions which initiate the Activity Event SCS associated with Activity initiation Duration The length of the duration (typically acquired from a Data Module that references a data model). Pre-emption SCS when activity is pre-empted Interrupt Condition Boolean expression that specifies the conditions under which an interrupt occurs SCS associated with Activity Interruption SCS associated Activity completion Pre-emption is triggered from within an event of another Activity (notation - PE.ActivityName)

Extended Triggered Activity
Extended Triggered Activity: ActivityName Event SCS associated with Activity initiation Duration The length of the duration (typically acquired from a Data Module that references a data model). Pre-emption SCS when activity is pre-empted Interrupt Condition Boolean expression that specifies the conditions under which an interrupt occurs SCS associated with Activity Interruption SCS associated Activity completion Pre-emption is triggered from within an event of another Activity (notation - PE.ActivityName)

Actions and Action Sequences
Initiated using a pre-condition Pre-condition can be formulated exclusively in terms of t (no state variables). Action is autonomous Does not incorporate a duration Has a single event specification. Action can be repetitive Recurring modification of the pre-condition (more details when discussing inputs) Leads to action sequence – used for modelling input streams.

Action and Action Sequence Construct
Action/Action Sequence: ActivityName Precondition Boolean expression that determines conditions which initiate the Action Event SCS associated with the Action initiation

Summary of Activity Constructs
Feature Activity Triggered Extended Extended Triggered Action/ Action Sequence Pre-Condition Yes No Starting Event Duration Intervention Terminating Event Optional

Modelling Inputs Inputs u(t), function of time, represents influence of environment Seen as an ordered pair (tk,uk) for k = 0, 1, 2, N tk is time where uk=u(tk), i.e., change in u(t) occurs tj < ti for j < i Observation interval contains all tk’s Characterizing sequence denoted as CS[u]. Two separate sequences associated with CS[u] Domain sequence: CSD[u] = {tk: k = 0,1,2, …} Range sequence: CSR[u] = {uk: k = 0,1,2, …} Almost always true that domain sequence has stochastic nature, i.e. tj+1 = tj + ∆j , where ∆j provided by stochastic data model. Range sequence may or may not be stochastic

Input as a piecewise continuous function
u(t) is often a piecewise constant (PWC) time function Example: number of electricians available in the maintenance team of a plant CS[u] = <(t0,1), (t1,2), (t2,4), (t3,4), (t4,3), (t5,1), (t6,2)>

Input as a discrete function
u(t) can also be a discrete function Example: number of product units in received shipment CS[u] = <(t1, u1), (t2, u2), …, (tj, uj), …> In this case, uk would normally be stochastic (i.e. require a data model)

Modelling Arrivals – Input Entity Stream
Associate an input variable, ũ(t), with input entity stream of entity class Өk Characterizing sequence: CS[ũk] = < (tη, 1), (tη+1, 1), (tη+2, 1), … (tj, 1), …> Arrivals occur one at a time (ũk = 1, for all tk) tj gives to the arrival times of the entities n=0, if first arrival is at boundary of observation interval (i.e. t0), otherwise n = 1 where t1 > t0 Domain sequence is constructed from the arrival stochastic process (data model) associated to the consumer entity class Өk

Inputs Construct Inputs Input Variable Description Data Models
Action Sequence Domain Sequence Range Sequence u(t) Description of the input which the input variable represents Details for CSD[u] Details for CSR[u] Name of the associated Action Sequence ũK(t) Description of the input entity stream which the input variable represents Details for CSD[ũK] Details for CSR[ũK]

Templates for Action Sequence
Action Sequence: ActivityName(u) Precondition t = tk  CSd[u] Event Typically the assignment to u of the value which it acquires at time t Action Sequence: ActivityName(C.EntityClassName) Precondition t = tk  CSd[ũK] Event Typically a collection of value assignments to the attributes of the arriving consumer entity instance from the class referenced together with a status change that reflects the initial positioning of the arriving cei.

Output – PSOV’s and DSOV’s
Recall that PSOV’s (point-set output variables) are classified as either: Sample set: a set of discrete values generated during a simulation run (often represents values of an consumer entity attribute) Trajectory set: a set of time/value pairs representing the piecewise continuous function of some model variable (ex: busy attribute of a resource). DSOV’s represent some scalar value obtained by applying an operator on a PSOV Examples of operators: NUMBER, SUM, MEAN, MAX, PERCENT Recall the SSOV (simple scalar output variable) Not based on a PSOV

Operators for Specifying DSOV’s
Operation on Time-set Variable X Operation on Sample-set Variable Y NUMBER The number of changes in X The number of samples generated for Y. SUM Area of the graph of X, when plotted against time. Sum of all sample values MEAN SUM divided by the observation interval. SUM/NUMBER MAX The maximum of X over the observation interval. The maximum of Y for all Y. PERCENT For Boolean variables, computes the percentage of time the Boolean value evaluates to TRUE over the observation interval.

ABCMod Constructs for PSOVs
Sample Sets Name Description PHI[y] Description of the sample variable y whose values populate the sample set PHI[y] Trajectory Sets Name Description TRJ[y] Description of the time variable y(t)

ABCMod Construct for DSOV’s
Derived Scalar Output Variables Name Description Output Set Name Operator Y The meaning of the value acquired by Y The value of Y is obtained by carrying out an operation on the values in this output set. The operation that is carried out on the underlying data set to obtain the value assigned to Y.

ABCMod Construct for the Simple Scalar Output Variable (SSOV)
Simple Scalar Output Variables (SSOV’s) Name Description Y The meaning of the value acquired by Y and a description on how Y acquires its value (e.g. count the number of customers that balk)

Other Constructs Constants and Parameters Data Modules
Constants provides labels for constant values Parameters: Values are constant over a simulation run Values can vary from one run to another - used to vary behaviour of the model Data Modules Data modules that encapsulate data models for inputs and other autonomous random processes Standard Modules and User-Defined Modules Construct for specifying procedures used in the Conceptual model For general use, including generation of input, encapsulating complex rules and decisions. Initialize Construct Specifies the initialisation of the model required at the start of a simulation run Summary of Activities: gives a overall picture of activities defined for the model

Constants and Parameters
Name Role Value Label1 Description of constant. Value (typically numeric) Label2 Parameters Values Parameter1 Description of parameter. Range of values

Data Modules Data Modules Name Description Data Model
ModuleName(paramList) Description of the purpose of the data module called ModuleName. Description the mechanism that is invoked to generate the data values provided by the data module called Module Name.

User-Defined Modules User-Defined Modules moduleName (paramList)
Description of the purpose of the user-defined module called moduleName.

Initialisation Construct
Initialize An SCS that describes the initialisation required at the start of a simulation run.

Actions and Action Sequences Extended Triggered Activities
Summary of Activities Summary of Activities Actions and Action Sequences ActionName Description of action. Activities ActivityName Description of activity. Triggered Activities Extended Activities Extended Triggered Activities

Examples Conceptual Model Specifications Template
A Port in Africa – Version 1 Simple loading service A Port in Africa – Version 2 Interrupting the Tug – let’s go back to get a tanker A Stormy Port in Africa Inputs other than arrivals

Modeling and Simulation: Exploring Dynamic System Behaviour

Similar presentations

Presentation on theme: "Modeling and Simulation: Exploring Dynamic System Behaviour"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Modeling and Simulation: Exploring Dynamic System Behaviour

Similar presentations

Presentation on theme: "Modeling and Simulation: Exploring Dynamic System Behaviour"— Presentation transcript:

Similar presentations

About project

Feedback