September 24, 2001GSS Architecture2 Grocery Store Simulation Entry Exit Aisle 1 Aisle 2 Cart Pool Conveyor 0 1 2 9 Aisle Delta Checkout Queue clerk Aisle n Aisle Width Starting Point Sales Register Bagging Bin bagger Shopper Enters Bagger Returns Cart Bagger & Shopper Exit Checkout Subsyste m Shopper & Cart
September 24, 2001GSS Architecture3 Checkout Station Model Conveyor Scales & Scanner Clerk Bagging Bin Sales Terminal Bagger Shopper Cart 1: Shopper unloads grocery items, if there is room on conveyor. 2: Shopper places plastic divider on conveyor after last grocery item. 3: Conveyor has a fixed capacity in numbers of items and transports them at a constant rate to the clerk’s station. 4:Clerk removes grocery items from conveyor and enters their identity and price into the sales system. Some items are identified and priced by bar codes. Other items must by manually identified and weighed. 5: When all items have been processed by the clerk, the shopper is presented with the total amount of the purchase. 6: The shopper pays for the groceries and is given a sales receipt. 7: When the cart has been unloaded, the shopper gives the cart to the bagger to be filled with bags of groceries. 8:The bagger loads grocery bags with items that have been priced by the clerk. Bags are held in the bin until the cart becomes available from the shopper. 9:When the payment transaction has been completed and all bags have been loaded in the cart, the shopper leaves the store with the bagged groceries.
September 24, 2001GSS Architecture4 Conveyor Model RULES: (1) A slot is the space that can be occupied by a single item. (2) The shopper always deposits the next item at slot 1, when it is empty. (3) The clerk always removes an item from slot N, when it is full. (4) If slot N is empty and at least one other slot is filled, the conveyor rotates one slot to the right. The amount of time necessary for the conveyor to rotate one slot position is a model parameter and is specified as a multiple of the simulation time granule. slot N slot 1 ShopperClerk N = Conveyor capacity in Slots.
September 24, 2001GSS Architecture5 State Transition Models Activity Start [C] Event/Action [C] an [optional] boolean precondition that must be true before the Event can trigger a transition; no precondition implies the transition will occur unconditionally whenever the Event occurs in the system. Event: a signal or message received that triggers a change in state. Action: computation performed and/or message(s) sent in response to an event. Activity: a state of processing that will continue until the next event; an activity could be a state of idleness. Stop
September 24, 2001GSS Architecture7 Clerk Model Ring-up Items  ReceiveItem /RequestItem Start Divider Received [~1] ReceiveItem /AcceptTotal /LastItemInBin  /RequestItem AcceptCash /(update receipt) AcceptChange Transition Conditions:  Grocery item received  Cash Received > Sales Total Make Change Produce Receipt AcceptCredit /(update receipt) Done Messages Sent RequestItem => Conveyor LastItemInBin => Bagger CartRelease => Bagger AcceptTotal => Shopper AcceptChange => Shopper AcceptReceipt => Shopper Messages Received ReceiveItem <= Conveyor AcceptCash <= Shopper AcceptCredit <= Shopper /CartRelease /AcceptReceipt
September 24, 2001GSS Architecture8 Bagger Model Bagging Items W/o Cart Start Bagging Items With Cart AcceptCart Last Item with Cart CheckBin /CheckBin Transition Conditions:  More items in Bin  No Items, but More Bags Bagging Items with Release Fill Cart W/o Release Wait for Release Fill Cart with Release Done Messages Sent CheckBin => Bagger AcceptCart => Shopper Messages Received CheckBin <= Bagger LastItemInBin <= Clerk ReleaseCart <= Clerk /CheckBin (open bag) CheckBin /CheckBin LastItemInBin /CheckBin  CheckBin /CheckBin  CheckBin /ReleaseCart [~1] CheckBin   ReleaseCart [~1] CheckBin  CheckBin /CheckBin [~2] [~2] / AcceptCart ReleaseCart /AcceptCart
September 24, 2001GSS Architecture9 Simulation Requirements 1.The Checkout Station Simulation (CSS) shall simulate the behavior of the following active agents in a realistic manner: Shopper Checkout clerk Checkout bagger Checkout conveyor The fidelity and realism of the models defining these agents shall be determined by the granularity of simulation time, the set of events that characterize their interaction, and by input parameters that control the response of each agent engaged in given interaction event. (See later modeling requirements.) The interaction events modeled shall be sufficient to realistically support the interaction scenarios and activities (1 – 9) described on the slide entitled: “Checkout Station Model.” 2.The CSS shall operate in a faster-than-realtime mode, that is, it shall compute and handle events in simulation time independent of real time. 3.The CSS shall provide the following input capabilities: An ascii file for specifying the grocery items in the shopper’s cart at runtime. An ascii file for specifying model parameters for each active agent in the simulation at runtime.
September 24, 2001GSS Architecture10 Simulation Requirements 4.The CSS shall provide the following output capabilities: An ASCII simulation log file shall capture the following system output: 1.Runtime date and time 2.A display of the intial state of the following objects after all input operations have been completed: cart, shopper, clerk, bagger, conveyor. 3.The simulation time and description of each simulated event ordered by simulation time. Events that occur simultaneously in simulation time shall be ordered by the cause-effect relation whenever it applies. 4.A display of the final state of the following objects after similation is complete, or whenever these objects are destroyed, whichever occurs first in real time: shopping receipt, cart, each bag in the cart, the shopper. Messages to the user terminal: 1.“INITIALIZATION COMPLETE” 2.“SIMULATION ENDS” Error messages shall be written to the standard system output device.
September 24, 2001GSS Architecture11 Simulation Requirements 5.Modeling Requirements Simulation time granularity = 1 second (all event times must be integers) Shopper: 1.Unload time per item ( simulation time) 2.Unload time for divider ( simulation time) 3.Amount of cash (units of cents ) 4.Payment delay for cash ( simulation time ) 5.Payment delay for credit ( simulation time ) NOTE: if cash is insufficient to pay for groceries, and the pay by cash option is exercised, then pay by credit must override the payment option. NOTE: assume that pay by-credit always succeeds when used – insufficient funds will not be modeled for credit payment. NOTE: Parameter #6 applies when shopper and bagger interact to exchange cart possession. Checkout Clerk: 1.Ring-up delay for bar coded items ( simulation time) 2.Processing delay for divider ( simulation time ) 3.Ring-up delay for weighed items (simulation time ) 4.Payment delay for change ( simulation time ) 5.Payment delay for credit (simulation time) 6.Processing delay for receipt (simulation time) NOTE: assume all other delays are zero (0). For example, parameters #1 and #2 include time to drop item in bagging bin.
September 24, 2001GSS Architecture12 Simulation Requirements 5.Model Requirements (continued) Checkout Conveyor: 1.Transport rate ( simulation time per slot ) 2.Maximum capacity ( number of slots ) Checkout Bagger: 1.Open new bag delay ( simulation time ) 2.Item-to-bag delay ( simulation time ) 3.Bag-to-cart delay ( simulation time ) 4.Bin polling delay ( simulation time ) Grocery Bags: 1.Maximum capacity ( number of items ) Grocery Cart: 1.Maximum capacity ( number of items ) 2.Maximum capacity ( number of bags ) Grocery Items: There are two kinds of items: bar-coded and weighed. All grocery items have a name that uniquely distinguishes them from other items. The price of weighed items is computed from the weight of the item in pounds and the price per pound given in cents.
September 24, 2001GSS Architecture13 Simulation Requirements Assumptions and Constraints –The software design may assume the existence of an infinite supply of empty grocery bags, and cash when making change. –Simulation ends when the shopper re-acquires the grocery cart with bagged groceries; this shall be the last event of the simulation.
September 24, 2001GSS Architecture14 CSS Models ShopperConveyorBaggerClerk CartBagReceiptCkout MessageReceiptMsgCkoutMsgMoneyMsg This layer of the design contains all and only the classes that define the behavior of active agents in the simulated world. In the CSS, this layer contains classes for the Shopper, the Clerk, the Conveyor, and the Bagger. All agent classes must communicate by sending messages to one another, that is, by creating and posting an Event that defines the future time at which the interaction event will occur, the identity of the recipient agent, and a Message object that identifies the specific event and provides the necessary data to service the event. Each of these classes must be derived subclasses of Agent. This layer contains all the passive classes of the simulated world. Active agents may direct calls on passive objects. Passive objects make direct calls to each other, if necessary. Passive objects may be passed from one active agent to another as part of a Message. Money CartMsg This layer contains all the derived subclasses of Message. These classes are used to pass data for servicing interaction events between active agents. Only recipient agent classes know the content or use instances of these classes. Methods of a recipient agent designed to service interaction events for that agent will optionally take parameters which are instances of one of these classes. See Notes CSS This class represents the Simulated World. It implements the CSS simulation interface and contains methods for creating and initializing the CSS object and running it. It also contains methods for post simulation review and analysis. Bin Players
September 24, 2001GSS Architecture15 Simulation Dynamics CSS CSS.Simulate() (Continued) Emgr: EventMgr Recip getNext() CSS.Run(): continued If there are Events that have not been processed, Run() gets the next event from the EventMgr and dispatches it to the Recipient agent. CSS.Run(): continued If there are Events that have not been processed, Run() gets the next event from the EventMgr and dispatches it to the Recipient agent. getRecvr() (E:Event) E: Event Repeat until there are no more Events to dispatch. This ends the simulation Run(). Dispatch( Recvr, getMsg(E) ) Recvr: Agent getMsg() M:Message getId() Mid Method [Mid] (M) *Post( Event ) The Recipient agent computes Messages to other agents for future interaction Events – these are posted to the EventMgr See Notes