 In this lecture, we review the language and some of the issues in implementing a discrete event simulation model, also known as simulation programming. Welcome to the lecture. The fundamental elements that distinguish discrete event system simulations are time, randomness and output. And each one of those is going to merit its own lecture later on in the course. Here we're going to spend a little time looking at the language of model implementation of simulation model programming. The system, I know you know what that is already, but we'll say it anyway. The system is the real thing that's being modeled. It's the real system. It's the real world. The model is the simulation algorithm, the simulation program. And you can design your conceptual model, but until you actually put together something that can be run using whatever software tool you use, you don't have a real implemented model. So that's what we're talking about here. Our simulation is composed of entities and attributes. Entities move through the system. They can be customers, parts, calls, tax returns, mortgage applications. Entities are the objects whose activities are being modeled, the objects that move through the system. Entities have attributes. An entity can be colored red. It can be colored blue. It can have a name. It can have a time of arrival. These are all attributes. As entities move through the system, they require resources that have constraints. They need servers. They may need some product. And there's not an unlimited amount of whatever it is that the entities need. As they move through the system, they request a resource. An entity might request a resource. It acquires a resource. If there's only one such resource, that means some other entity can't have it just now. And then after the entity is finished with it, that resource is freed. That's a resource. A queue is a waiting line. It's a place where entities go when they are delayed and they have to wait. For whatever it is, their activity that they're trying to do in this system. A delay is a time period during which nothing happens. Maybe. It could also be a time, the entire time that an entity spends in the system doing things and not doing things. MOE stands for measure of effectiveness. It's a performance measure, a performance criterion. It's the metric that you use to decide whether the system is a success or not. It's what you're optimizing. And it's a performance variable. You can be talking about how long entities have to wait for service. You could be talking about the utilization of the system and so on. State variables are variables that describe the state of the system. One typical state variable is the number of entities that are in the system at any one time. The state of the system is the set of values of a collection of state variables at a particular moment in time. The clock or the simulation clock is a variable that contains a value representing time, simulated time, usually starting from zero. A list is a collection of objects in some kind of an order. Simulation model implementation or programs use lots of lists for lots of different reasons. One obvious one is the queue, a list of entities waiting for service. Activity is something that has a start time and a stop time, and it has a duration and it represents an activity in the real world. One example would be service. Events in discrete event system simulation are exactly what it sounds like. These are moments in time, discrete moments in time, at which the system variables change. And this is what the simulation model moves because the events move. We'll see how that happens. Each event preschedules another event. For example, a customer arriving at a bank is going to then cause another customer to be prescheduled according to the known inter-arrival time distribution. The event notice is kind of like a ticket. It's a piece of data, a piece of data with multiple parts that represents the event, either an event that is happening that has happened or that is waiting to happen. And then the event list is a list of those event notices. FEL stands for future events list, and that's the way the timing routine in an event-oriented simulation program works, where it takes all these event notices for events waiting to happen, puts it in a list called the future events list, and in order by, what do you think, time to occur. So when the system then is looking around and saying, okay, I did everything that's in the system now, what's next? Well, what's next would be the event notice that's at the front of the events list because they're in order by time, and nothing will happen until that time. And so you pop it off the front of the events list and do whatever it is that it says. There are two major world views in simulation programming, and it's not a trivial thing. Very often you'll find when you try to use a particular software tool in simulation that it focuses only on one worldview, not on the other. So you have to know what you're doing before you decide what tool you're going to use. The event-driven approach is where the simulation moves forward because one event pulls up another event. The events are scheduled, there's pre-schedule to happen at particular times. And the timing routine finds the very next thing that's supposed to happen in in time, adjust the simulation clock, and then moves forward. Things are being done in this simulation on a very, very microscopic level. The process-driven approach, on the other hand, follows an entity as it moves through the system. The entity engages in activities as it experiences its way through the system. It might have delays. It might have unavoidable delays. It might be delays because of whatever it is that the entity is trying to do. Service, for one, participating in the activity, engaging a resource. So it's a different approach. It doesn't look at individual events. It looks at, well, what happens to a single entity as it moves through the system? And the program is built that way. When you are working in arena or clouds, you're working in the process-driven approach. If you're going to build a simulation model of, let's say, a banking system, you want to identify what are the entities, the attributes, the activities, the events, and the state variables at the very least. The entities are the customers. The customers are what we observe moving through the system. A customer has an attribute, for example, account balance, presumably more attributes than that as well. An activity might be a deposit where the customer needs to go into service to make a deposit. The events are, there's the arrival event, and there's the departure event. The departure event happens when the customer service is complete. And of course, the state variables that could be used are the number of customers in the queue, the number of tellers that are busy. And similarly, if you look at a transportation system, the entities would be travelers. The attributes would be where they come from, where they're going. In production, the entities are machines. A machine could have a speed, a capacity, and a time to break down, the time to the next breakdown, right? The entities in a communication system, like over a communication network, might be messages. And in an inventory system, we are working with products in a warehouse. The warehouse might have a capacity, and we might, the state variable might be, let's say, backlog demand. These are just examples. Again, to place us in context, this is the part of the course where we're looking at model implementation, which means building the actual simulation model, which means writing the simulation program and whatever software tool we're using. The essential distinguishing features in the simulation model for discrete event simulation, managing time, generating the output statistics that we have to collect over time, and anything connected to modeling random phenomena. Those lectures are coming up and I hope you join me. Thank you for joining me in this lecture today, and I hope you enjoy the rest of the series as well.