What is an Event?

In GoldSim, a discrete event is something that occurs instantaneously (as opposed to continuously or gradually) in time. It represents a “spike”, a discontinuity, a command, or a discrete change of state for the system.

For example, through continuous compounding of interest, the money in a bank account continuously increases, but the account can also increase and decrease instantaneously due to discrete events (i.e., deposits and withdrawals).

Such events are particularly important for the Reliability Module because the systems being modeling are controlled primarily by discrete occurrences (such as failures and repairs).

Of course, “instantaneous” and “gradual” are relative terms. That is, whether something is treated as instantaneous or gradual is a function of the time scale of interest, and hence you must differentiate between the two based on the context of your model. Typically, the distinction will be obvious. For example, if the time scale of interest is 10 years, something happening over the span of a day can be considered to be “instantaneous”. If the time scale of interest is several days, however, something happening over the span of a day would in most cases need to be treated in a continuous manner.

GoldSim handles “instantaneous” changes to a model by providing a mechanism for a model to generate and respond to discrete events. This is accomplished by providing the ability to instantaneously trigger an element to take a particular action (e.g., instantaneously change its value) in response to an event.  Hence, in GoldSim, an event is specifically defined as an instantaneous occurrence that subsequently triggers a particular action.

In GoldSim, an event can be generated in one of four ways:

   The event occurs when a specified condition (e.g., X > Y) becomes true or false;

   The event occurs when a specified output in the model changes;

   The event occurs at a specified calendar or elapsed time; or

   The event occurs based on a specified rate of occurrence, which can be treated as regular or random ("occur exactly once a week" or "occur, on average, once a week").

In addition, some elements can respond to an event generated via one of the mechanisms above, and generate a new event.

In some cases, an event will occur (e.g., X becoming greater than Y) which triggers a particular action in a single element (exercise an option). In such a case, the event is internal to that element, and it does not directly impact other elements. In other cases, however, an event may impact multiple elements, or one element may respond to an event by triggering other elements to take a particular action. In these cases, it is necessary for discrete signals to propagate between elements.

In order to propagate events (and their consequences) between elements in a model, it is necessary to send information between elements intermittently as a "spike" or discrete "packet" of information. To facilitate this, GoldSim allows certain elements to emit and receive (i.e., produce as outputs and/or accept as inputs) a discrete signal. Discrete signals are a special category of outputs that emit information discretely, rather than continuously.

Within GoldSim, there are actually two types of discrete signals that can be passed from one element to another: discrete event signals and discrete change signals.

A discrete event signal is a discrete signal indicating that something (e.g., a purchase or a sale) has occurred. It does not describe the consequence of that occurrence; it simply emits a signal between elements indicating that an event has occurred.

A discrete change signal, on the other hand, emits information regarding the response to an event. In particular, a discrete change signal contains two pieces of information: a value (e.g., 10 dollars) and an instruction (e.g., Add). A discrete change signal can only be generated in response to an event. It can only be received by a few select elements (e.g., a Reservoir or a Pool) which understand how to process it.

Within the Reliability Module, discrete event modeling is a fundamental feature of the elements used to model reliability and risk, and is utilized in the following ways:

   Reliability elements (which are used to model system components such as pumps, engines, relays, and switches) can be triggered to turn on and off.  They can also be triggered to be replaced or repaired.

   One class of Reliability elements (Action elements) are used to model components which must respond to a control command or condition (e.g., switches, relays).  Events provide the command or condition that tells the element to carry out its action.

   Reliability elements output discrete event signals to mark a number of occurrences, such as whether or not a requested action was successful and when a component starts or stops operating.  These events can then be used to subsequently trigger other elements.

Related Topics…