# Systems

A system can be defined as:

```     A collection of entities that interact with a common purpose according to sets of
laws and policies.
```

The system may already exist, or it may be proposed. Using simulation, even theoretical systems can be studied. We intentionally do not define a system by the specific entities in it. Rather, we define a system by its purpose. Thus, we speak of a communications system, a health care system, a production system, etc. Using a functional definition of a system helps us avoid thinking of a system as having a fixed structure. Consequently, we view a system in terms of how it ought to function rather than how it has traditionally worked in the past. To design a new system it is necessary to free our thinking from the status quo.

The entities making up the system may be either physical or mathematical. A physical entity might be a patient in a hospital or a part in a factory; a mathematical entity might be a variable in an equation.

When developing simulation models of systems, it is useful to classify entities as being either resident entities or transient entities. Resident entities remain part of the system for long intervals of time, whereas transient entities enter into and depart from the system with relative frequency. In a factory, a resident entity might be a machine; a transient entity might be a part. Depending on the level of detail desired, a factory worker might be regarded as a transient entity in one model and a resident entity in another.

In describing a particular aspect of the dynamic behavior of a system, it is often useful to focus on the cycles of the resident entities. For example, we might describe the busy-idle cycles of machines or workers. Alternatively, we might focus on the paths along which transient entities flow as they pass through the system (e.g., parts moving through a factory). Transient entity system descriptions tend to be more detailed (and more informative) than resident entity descriptions. Each type of modeling has advantages: modeling resident entity cycles tends to be easy and efficient, while modeling the details of transient entity flow gives more information. Typically, a mixture of both viewpoints is used, but one or the other predominates.

In systems where there are relatively few resident entities and a great many transient entities, it is usually most efficient to study the cycles of the resident entities. Examples include semiconductor factories with thousands of wafers, communication systems with millions of messages, and transportation systems with tens of thousands of vehicles. In simulating such systems, the cycles of resident entities might be described by the values of only a few variables, while the flow of transient entities might require a great many variables to describe. On the other hand, systems where there are only a few transient entities and many resident entities (a power line inspection system or an airline maintenance facility) may be efficiently studied by examining the flow of transient entities.

It will often be the case that an initial model consisting only of resident entities is appropriate. Thus, first-cut system experiments can be done with a simple and efficient model. After a design has been roughed out and more details are desired, the model can be enriched into a transient entity flow model. Enriching the model to explicitly include transient entities generally makes the model larger, more complex, more prone to errors, and slower to execute. It may be wiser to use detailed transient entity models only for final refinements of a design. A well-designed simulation may have some sections that model only resident entity cycles and other sections that model the detailed flow of transient entities.

Entities are described by their characteristics (referred to as attributes). Attributes can be quantitative or qualitative. Moreover, they can be static and never change (the speed of a machine), or they can be dynamic and change over time (the length of a waiting line). Dynamic attributes can further be classified as deterministic or stochastic depending on whether or not the changes in their values can be predicted with certainty. It is sometimes useful to think of entities as belonging in sets owned by other entities. For example, in a factory a set of parts might be waiting in a line (queue) for a particular machine. Also, a set of machines (routing) might be required to process each part. Thus, each machine owns a set of parts, and each part owns a set of machines.

The Entity/Attribute Hierarchy for a Health Care System

The level of detail with which we choose to describe a system determines whether a particular system component is thought of as an entity or an attribute of some entity. For example, we can examine regional health care systems at various levels. We might think of the number of hospitals in the region as an attribute of the region. For greater detail, we might want to consider each hospital as a separate entity with the clinics offered as attributes. At an even finer level of detail, we might think of the clinics in the hospitals as distinct entities, with the physicians and patients as attributes of each clinic. Still greater detail is obtained by thinking of individual physicians and patients as entities described by their attributes of specialty, schedule, affliction, etc. The level of detail desired depends on our reasons for studying the system. It would not make sense to model a nationwide health care system at the level of individual patients; likewise, it would not be meaningful to model the laundry at a particular hospital from a national viewpoint.

The rules that govern the interaction of entities in a system that are not under our control are called laws. Similar laws are grouped in families, members of which are distinguished by parameters. Rules that are under our control are called policies; a family of similar policies may be distinguished by the values of their factors. When we experiment to determine the effects of changes in parameters, we are doing sensitivity analysis. When we experiment with changes in factors, we are doing optimization or design. Sensitivity analysis might examine changes in the rate of patient demand for an emergency room. Optimization in the same setting might focus on adjusting nurses' schedules to provide adequate coverage during peak periods. Unlike the real world, in simulation studies both types of experiments are conducted in much the same manner.

Often throughout this book we will use examples of simple, random systems consisting of a waiting line with one or more servers. (Notable exceptions are the financial risk analysis model, the critical path model, and the continuous time simulation of an aquatic ecosystem found in Chapter 5.) These stochastic, dynamic queues are found in many of the systems we are interested in studying: parts waiting for a machine, patients waiting for a doctor, jobs waiting for a computer, messages waiting for transmission, etc. The resident entities in the system are the machines, doctors, computers, data busses, . . . generically referred to as servers. The transient entities are the parts, patients, jobs, messages, . . . generically referred to as customers. Although not as obvious, the waiting lines, buffers, and queues are also resident entities in a queueing system. Laws describing the system might include the probability distribution of the time between successive customer arrivals. Policies might include the number of servers, the amount of waiting space, and the priority level different types of customers receive for service.

The state of a system is a complete description of the system and includes values of all attributes of entities, parameters of laws, factors for its policies, time, and what might be known about the future. The state space is the set of all possible system states. A process is an indexed sequence of system states; typically the index is time, but it might be a count of customers or some other system characteristic.