Hola todos.

Ahora vamos a pasar a la segunda lección del módulo 4 sobre Principios generales de simulación.
Esta lección solo consiste en un montón de definiciones útiles que necesitaremos para el resto del
semestre. Así que aquí está el resumen. La última vez, discutí a un nivel muy alto todos los pasos en
el llamado estudio de simulación adecuado.

Se puede ver que fue un proceso iterativo real. A pesar de que he enumerado todos los pasos, un
poco va y viene un poco. En esta lección, daré un montón de definiciones fáciles que son relevantes
para todos los modelos de simulación generales.

Estas son cosas que podemos usar para el resto del curso. Especialmente, estos entran en juego
cuando miro el lenguaje de programación porque estos términos son omnipresentes cuando hablo
de cosas en el lenguaje. Así que vamos a empezar con las definiciones. En primer lugar, esto es algo
que puede haber aprendido cuando eran niños pequeños, un sistema, nuestra primera definición,
es una colección de lo que llamaré entidades que interactúan entre sí para lograr algún tipo de
objetivo. Así que las entidades podrían ser personas o máquinas. Entidad es sólo una palabra
elegante para las cosas. Entonces, un sistema es una colección de entidades que trabajan juntas
para lograr algún tipo de objetivo.

Y un modelo es una representación abstracta de un sistema, así que modelamos el sistema. Y, por
lo general, el modelo contiene relaciones matemáticas o lógicas que describen el sistema en
términos de las entidades. ¿Qué son los clientes? ¿Cuáles son las máquinas o recursos que se utilizan
para servir a los clientes?

¿Cuáles son los estados de los sistemas? Conjuntos relevantes, eventos relevantes y hablaremos
sobre todos los términos a continuación, pero un modelo es todas estas cosas. Es una
representación abstracta del sistema. Por lo que podría tener cola de servidor único. Ese es tu
sistema. ¿Cómo modelamos eso? Bueno, tal vez usamos un modelo de colas MM1, algo así. Vamos
a entrar en más detalle en un minuto. Más definiciones. El estado del sistema es simplemente un
conjunto de variables que contienen suficiente información para describir el sistema en cualquier
momento. Así que piense en el estado como una instantánea del sistema. Contiene toda la
información que necesita para describir completamente el sistema, al menos para los fines de su
estudio.

Entonces, por ejemplo, veamos la cola de un solo servidor. Como mínimo, todo lo que podría
necesitar para describir el estado del sistema en cualquier momento podría ser lo siguiente, podría
hacer un seguimiento de la cantidad de personas en la cola del servidor único en el momento t.

Usualmente uso la notación de cola estándar l sub q de t, número de personas en la cola única en el
tiempo t. Entonces, si lo sabe y si el servidor está ocupado o no en el momento t, estableceremos la
variable b de t igual a uno si el tipo está ocupado.

Y estableceríamos b de t igual a cero si el tipo está inactivo, no ocupado en el tiempo t. Y a los efectos
de una simulación simplista, si sabía cuántas personas hay en el q en el momento t y si el servidor
está ocupado o no, eso le da toda la información que necesita. Al menos en el nivel más simplista.
Más Más Más, ¿cómo te gusta, cómo te gusta?
 Entidades ahora. Ya he hablado de esto. Estas son cosas en el sistema. Clientes o recursos o
servidores. Ahora pueden ser permanentes, como lo es una máquina en su sistema, normalmente
está ahí para siempre. Es permanente o temporal, los clientes. Los clientes entran al sistema, se
ponen a trabajar, se van. Pensemos en los clientes por un segundo, los clientes, y supongo que las
máquinas también, pero los clientes pueden tener muchas propiedades. ¿Qué tan alto es usted,
cuánto dinero tiene que gastar, cosas así, cuánto trabajo va a tomar?

Estos son atributos de la entidad, propiedades de los clientes. Un cliente también podría tener una
prioridad, usted podría ser un pez gordo, una peluca grande, y así, ya que tiene alta prioridad, puede
ir al frente de la línea. Eso es una propiedad o un atributo del cliente. Una lista, que usaré
ocasionalmente, o una cola, a veces es, puedo usar de forma anónima. Es sólo una lista ordenada
de entidades. Por ejemplo, la línea que se forma delante de un servidor. Están ordenados según la
hora de llegada o quizás por prioridad, pero es solo una lista que está ordenada para que podamos
hacer un seguimiento de a quién pertenece en la cola, así que la usaremos mucho. Tengo que tener
más, más cencerro. Un evento ahora, esto es un poco complicado, porque la gente usa esta palabra
para definir un par de cosas diferentes, pero seré consistente. Un evento es, literalmente, un punto
en el tiempo en el que ocurre algo interesante, en el que cambia el estado del sistema y que no se
puede predecir con certeza de antemano.

1. So you don't know when the next arrival is but when it happens,

2. when the next guy shows up, that's an event.

3. When the next guy leaves the server, that's an event.

4. And you can't really predict that beforehand,

5. unless the server has a fixed deterministic service time.

6. Usually there's some randomness involved, so

7. an event is typically unpredictable ahead of time, but when it happens, it happens.

8. Now, some people, well, we told you just now, we have an arrival event,

9. departure event, you could also have things like machine breakdown event.

10. Some people regard the event, not only as the time that something happens,

11. but the type of thing that's happening.

12. So for instance, even though I say event technically means the time

13. that a thing happens, I often refer to an event very loosely as what happens.

14. Like the arrival, like the departure, like the machine breakdown.

15. These are all things that happen events.

16. Although technically, it's the time at which they happen is what the event is.
17. And still not done, got some more definitions.

18. An activity is a duration of time of a specified length.

19. In other words, what's called an unconditional wait.

20. So if I can specify how long something's gonna take, that's called an activity, and

21. I use that term every once in awhile.

22. So examples include, well, when I write my simulation I'm gonna say,

23. well the times between customer arrivals, arrival times, are exponential.

24. Or maybe my service times at the server are constant, or they can be exponential,

25. but somewhere in the simulation I have to write exponential.

26. Or I have to write constant to specify the service times or the interarrival times.

27. So, we can explicitly generate those events, so

28. that's why I say they're specified.

29. On the other hand, finally, I might have something that's unspecified.

30. And that's called a conditional wait.

31. That's a duration of time of unspecified length.

32. These a bit interesting ones.

33. These the ones that make you think a little bit.

34. The good news is that a lot of stimulation languages handle these automatically.

35. If you're programming these kinds of things yourself,

36. you kinda gotta think a little bit.

37. So for example, let's look at a customer waiting time.

38. So it turns out we don't know customer waiting time directly.

39. That's why we're simulating.

40. So all we know when we program up our simulation is that

41. we know the arrival times and service times because we can specify those.

42. And then either we or

43. the simulation language has to reverse engineer the waiting times.

44. So you give me the arrival times and

45. service times, I can calculate, takes a lot of work, takes a little thinking, but

46. I can reverse engineer those waiting times.

47. So you've got to e a little careful about that.

48. What's very interesting, a lot of people will go and

49. they'll do projects where they go and observe the waiting times.

50. They kind of forget to look at the arrival times and the service times.

51. Turns out, it's a lot harder to reverse engineer the arrival times and

52. service times.

53. So I always advise people, collect arrival times and service times.

54. You can always reverse engineer waiting times.

55. So here's a summary of what we did in this lesson.

56. This time, we went through a bunch of these easy little definitions that

57. are relevant to general simulation modeling.

58. And I've gotta put emphasis on the word event as in discrete event simulation.

59. Now this leads to what we're gonna do next time.

60. What is the simulation clock and how does it move along?

61. Well the simulation clock,

62. it turns out is gonna move from event to event and we're gonna help it move along.

63. Now I don't want to you to be scared or

64. surprised about this, but we're the people that control the simulation clock.

65. How does it go?

66. How does it jump from time to time as the simulation progresses?

67. And there’s a couple of ways to do this.

68. I'll try not to be scary about it cuz there’s a very easy way to carry it out.

69. That’s why it’s called discrete event simulation.

70. And this is what makes simulation so interesting.

71.