3
Modeling External Events

3.1 Introduction

As mentioned in Chapter 1 (Essential Modeling Heuristics), the central feature of the environmental model is a specification of the events to which the system must respond. In the following sections we will further explain the concept of an external event and describe methods for formulating an external event list for a system.

3.2 Definition of an External Event

An event in a general sense is a significant occurrence. An external event has three characteristics:

    It occurs in the system’s environment.

    It elicits a preplanned response from the system.

    It occurs at a specific point in time.

Let’s consider each of these characteristics in turn.

For the purposes of defining external events, the system’s environment is represented by the terminators on the context schema. Any occurrence that arises within the transformation representing the system is internal and does not qualify as an external event. Figure 3.1 shows a context schema for the SILLY logic analyzer (Appendix C). Assume that the logic analyzer is in the process of collecting data from the microprocessor. Consider the two candidate events User Requests Termination of Logic Acquisition and Logic States are Displayed. The first of the two originates with the user and thus occurs outside the system boundary; it therefore qualifies as an external event. The second, even though it is a response to the first, originates within the system and thus fails to satisfy the above definition.

To investigate the idea of a preplanned response, imagine that in the situation illustrated in Figure 3.1, while SILLY is collecting data, the microprocessor’s clock suddenly changes frequency and begins emitting pulses at double the previous rate. Sophisticated logic analyzers, in fact, are capable of measuring and recording the intervals between timing pulses in the devices they monitor. SILLY, however, is a simple system and merely responds to the occurrence of the microprocessor clock pulse by capturing the data on the leads. Therefore, it has no preplanned response to a change in the external clock frequency. If the system can “keep up” with the new clock rate, it will not respond in any way to the change, but will simply continue collecting data at each clock pulse. If the faster frequency exceeds the system’s ability to finish collecting one set of data before the next arrives, SILLY will respond, but in an unpredictable, unplanned way – by sporadically missing data collections. Although the speed-up occurs in the system’s environment, it fails to satisfy the definition of an external event on the preplanned response criterion.

Figure 3.1 SILLY Context Schema.

To understand the third criterion – that an external event occurs at a specific point in time – it is necessary to recall the distinction between time-discrete data flows and time-continuous data flows discussed in Volume 1, Chapter 6. Consider the context schema of Figure 3.2, which describes a typical transaction-oriented system. It is easy to picture the external events in this system as coinciding with the arrival of discrete data flows. The events – Customer Makes Deposit and Customer Makes Withdrawal Request – can (at least with regard to the completion of the input) be localized to a point in time.

Figure 3.2 Transaction-Oriented System.

As an alternative, consider the aircraft on-board system illustrated in Figure 3.3. It is tempting to say that Aircraft is Climbing is an event. The climbing certainly occurs in the system’s environment, and the system presumably responds at least by periodically recording the rate of climb. However, the event cannot be localized as occurring at a specific point in time. To be useful for event modeling purposes, an event that involves a continuous data flow must describe a transition from one discrete mode of behavior to another. An event that is relevant in this context and that satisfies the external event definition is Aircraft Stops Climbing, presuming that the system responds in some specific way when the rate of climb reaches zero. It might be argued that, after all, the rate of climb is simply a continuous variable and that a zero rate of climb is simply one value among many others both positive and negative. However, this argument will be singularly unconvincing to a pilot, to whom there is a very significant real-world difference between a positive and a negative rate of climb and thus a great importance attached to the transition. This is another illustration of the basic idea that an essential model describes a system in subject-matter terms.

Figure 3.3 Aircraft On-Board System.

This distinction between time-continuous and time-discrete behaviors is critical to modeling events in real-time systems. Consider the two transformations of Figure 3.4, which describe a part of the Bottle-Filling System (Appendix B). It is possible to think of each possible change in pH value for the Change pH to New Value subsystem as a distinct event. However, if there are N distinct values, even restricting changes to adjacent values results in 2(N-1) possible events. To the person concerned with process control these events are all merged into a continuous behavior called “ramping,” just as all the possible input and output value changes of the Maintain pH at Constant Value subsystem are part of a continuous behavior called “maintaining a setpoint.” In identifying the external events related to the behaviors, it is necessary to ask, What causes these transformations to start operating and stop operating? In the case of Figure 3.4, the event Operator Enters New pH Value might start Change pH to New Value, and the event pH Reaches New Value would stop Change pH to New Value and start Maintain pH at Constant Value.

Figure 3.4 Two Continuous Transformations.

Now that we’ve discussed the definition of an external event, let’s look at the difference between the occurrence of an event and the system’s discovery that an event has occurred.

3.3 Events Versus Event Recognition

Let’s return to our discussion of Figure 3.4 and ask why pH reaches New Value is an external event. After all, the system can’t determine that it needs to make a response before comparing the pH data with a stored internal value (Figure 3.5). We’ll defend our identification first by appealing to the definition. The reaching of the desired new value certainly happens in the system’s environment (the liquid whose pH is being measured isn’t within the embedded system for obvious reasons!), the system must make a response when the event occurs, and reaching the new pH value can be localized to a point in time. Despite the formal applicability of the definition, however, there’s an important distinction to be made. In the SILLY system in Figure 3.1, the acceptance of the Stop event flow is equivalent to the system’s recognition that an event has occurred. Similarly, in Figure 3.2 the arrival of the Deposit and Withdrawal Request flows are all the system needs to determine that the corresponding events have occurred. In both these cases, the event recognition is direct. In the case of pH Reaches New Value, there is an indirect recognition mechanism involving comparison of a continuous input with a value retained in a data store.

Figure 3.5 Event Recognition by Value Comparison.

Comparison with a stored data value is only one of many possible indirect recognition mechanisms. Consider the Defect Inspection System pictured in Appendix D. In order to fulfill its purpose, an embedded system controlling this apparatus must differentiate scanner data belonging to each individual sheet, trigger the cutter at the appropriate time, and operate the router to separate good and bad sheets. One can say that the system must respond to the events Sheet Reaches Scanner, Sheet. Reaches Cutter, and Sheet Reaches Router. However, the only information relating to the sheets that the system receives concerns the motion of the conveyer mechanism. Given an external synchronization signal, which identifies that the first sheet of a roll is at the scanner, the system can then proceed to simulate the arrival of sheets at various points by measuring the motion of the conveyor and thus the metal. The situation is illustrated in Figure 3.6. The relative positions of the scanner, cutter, and routing mechanism must of course be part of the transformations for the simulation to work successfully. If, instead of monitoring conveyer motion, the system were to receive sensor pulses as sheets reached specific points (say by notching the roll at sheet edges and using a contact probe), neither the basic event nor the required response would change – only the recognition mechanism would differ.

Figure 3.6 Event Recognition by Time-Based Simulation.

Another form of external event recognition is through the use of time. Imagine a production control system that produces a management report containing data about each production run and the defects on the products produced. The data required for the report should be entirely available from stored data, and the production of the report could be prompted by the manager requiring it. Alternatively, and more likely, the report might be produced at fixed intervals. In this case, there is no external flow that causes the report to be produced; nevertheless, Management Requires Production Run Report should still be regarded as an external event. Returning to our definition, the event occurs at a specific point in time and it elicits a preplanned response from the system. The remaining question is: Does the event occur in the system’s environment? We argue that the requirement to produce the report is externally imposed on the system. To distinguish this type of event from other events, we call this a temporal event. To illustrate this, let us consider an alternative: each time a defect occurs, the report is produced in response. Unless the plant is running very smoothly this will produce outputs often enough to cause consternation and rapid modification of the system to produce less-frequent outputs: definitely something that occurs in the system’s environment! Please note that there is no necessary distinction in the response between the temporal event described and the event signaled by a prompt type of flow. However, if the manager could request the report by providing a flow that contained a start date for the report’s data the response would be different from that for the periodic report, and so would require another event.

3.4 Identification of Individual Events

In order to create a useful event list, some guidelines are necessary. Imagine, for example, a complex data communications system with a variety of input event flows. To say that there is a single event called Input Signal Arrives is to miss the point entirely. The fundamental guideline, in fact, is that events must be described in subject-matter terminology – a variation on a familiar theme. In the data communications case the events might be Transmission is Requested, Receipt is Acknowledged, and so on.

A useful way to determine whether a candidate event associated with a discrete data flow or event flow is better described as a collection of events is to see whether the flow contains an explicit or implicit “tag” as discussed in Section 2.8 in Chapter 2 (Defining System Context). In the SILLY system the candidate event, User Provides Control Input, cannot be responded to until the system decides whether the input was a Start or a Stop. Therefore there are two events, User Requests Start and User Requests Stop.

In the case of an event associated with a discrete data flow, a useful question is, Do all instances of the event involve the same set of data elements? If a piece of data is present in some instances and absent in others, the response may differ in the two cases and there may be two events involved. This idea also extends to different ranges of a data element that have different significances. The filing of a flight plan that involves crossing a secured military area might evoke a different response from a system than the filing of one that involves only non-sensitive terrain.

Let’s now explore some general strategies for creating a list of events.

3.5 The Active Event Modeling Approach

The existence of a reasonably well-defined context schema suggests an active modeling approach to the problem – in other words, that we visualize the system in action to identify events. In this procedure, the terminators are thought of as transformations that actively send flows to and receive flows from the system. The events are then derived by determining what effects the actions of the terminators can have on the system. Of course some events are identified with the arrival of discrete inputs and can be identified in a straightforward way. Questions that might be asked include: What would cause the system to begin producing that continuous output from this continuous input? What would cause the system to start (or stop) accepting occurrences of this discrete input? What would cause the system to produce an instance of this discrete output? Are there significant values of this input that will cause an event if reached? Do certain occurrences of this input cause different responses from other occurrences?

Returning to the context schema for the SILLY system in Figure 3.1, applying the active modeling approach yields in part:

(1) User starts acquisition

(2) Non-trigger state occurs at clock pulse

(3) Trigger State occurs at clock pulse

(4) 128th state following trigger state occurs at clock pulse

The third event involves a significant value of the Logic State input, and the fourth event causes the system to stop accepting Clock inputs and to display the Logic States. Notice that Clock Pulse Occurs is not a single event, since the system’s response varies according to an indirect recognition mechanism involving checking the trigger word and counting clock pulses.

3.6 The Passive Event Modeling Approach

The method described in the previous section required the system to have well-defined terminators and input/output connections. Suppose that an event list must be built in the absence of a precise context. This is not an unrealistic premise. In fact, a practical way of attacking the problem might require the terminators and flows to be derived from the events. In this case, a passive modeling approach, which involves a search for associations between objects in the system’s environment, can be used.

The starting point is a list that includes at least the sensors and actors used by the embedded system and the objects in the perception/action space that are perceived and acted upon. In the instance of a system that is part of a larger system, the things perceived and acted upon might also be (or contain) sensors and actors, and the list can be expanded by including a broader perception/action space. Consider a communications system for military reconnaissance. The sensors and actors include radio transmitters and receivers, and reconnaissance aircraft and ships are perceived and acted upon. However, the reconnaissance planes and ships themselves contain sensors and actors, such as infrared and optical sensors, which in turn perceive reconnaissance targets such as troop concentrations. Things perceived by a sensor are not restricted to physical objects. A human acting as a sensor can perceive abstract things such as desired situations, requirements, standards, and so on which are legitimate list entries. The list just described is used to build a data schema in which the entries on the list become the object types and the associations among list entries are the relationships. All of the ideas and guidelines provided in Volume 1, Chapter 10 (Modeling Stored Data), can be used in building the schema. A candidate event for passive event modeling is an activity or operation that causes a relationship to be formed or deleted on the data schema.

As an example, let’s look at the Bottle-Filling system. The list items for the sensor/actor technology include Bottle-Filling Valve, Bottle Release Mechanism, and pH Sensor. The perception/action space includes Bottle, Solution, and Bottling-Line Operator. The operator, as a sensor, has a perception/action space that involves Production Requirements and Product Standards. To build the data schema we take these entries pairwise or in small groups and identify the associations among them (Figure 3.7). An association of interest between the bottle and the bottle-filling valve is alignment. The operations that create and delete this association are, respectively, Bottle Comes into Alignment with Valve and Bottle Moves out of Alignment with Valve, which are then potential events to which the system might respond. The Selected relationship between Operator and Product Standard means that the operator has identified one of the instances of Product Standard (that is, a target pH of the solution) as governing the production process. The operation of changing from one standard to another removes the connection to one instance of the standard and adds a new one. Thus Operator Selects New Product Standard is a potential event.

Figure 3.7 Data Schema for Bottling System.

3.7 The Brainstorming Approach to Event Modeling

It should be clear from the preceding two sections that the strategies for building event lists are not precise analytical approaches but simply rough-and-ready aids to the thought process. The identification of a complete set of events is a critical point in the requirements definition process. The failure to identify an important event will not appear as a deficiency in the formal notation for modeling the system – a system model can be perfectly reasonable and technically consistent yet still fail to identify a desirable event response. The end result, however, will be a system that operates correctly (that is, matches the model) but whose behavior does not meet end-user expectations.

The only defense against this potential problem is to take a “brainstorming” approach to building an event list. The list should be created by a group, and the group should not consider its work done until every conceivable event to which the system might respond, no matter how far-fetched, has been examined and accepted or rejected [1].

One class of events frequently missed relates to “failure mode” operations of a system. Although the essential model should not deal with imperfections in the technology used to implement the system transformation, it must deal with potential problems with the technology of the devices and systems shown as terminators. Since the terminators are by definition outside the bounds of the system-building effort represented by the model, the implemented cannot modify the terminator technology at will to improve its reliability. Instead, they must build responses to terminator problems into the essential model of the system. A useful approach to modeling responses to terminator problems is to build a list of “normal” events and then to ask, for each event, Does the system need to respond if this event fails to occur as expected?

As an illustration, let’s return once again to the SILLY system of Figure 3.1. The partial event list given earlier in the chapter lists several events involving a microprocessor clock pulse. But what if an expected clock pulse fails to occur? Should the system have a time-out mechanism that produces a message to the user if a pulse isn’t received within some time interval? Another event mentions the identification of a trigger state. What if the system runs for an extended period of time without a trigger state being found? Such questions are very useful for probing the adequacy of an event list.

3.8 Summary

The identification of the events to which a system must respond is critical to requirements definition. An external event has been defined as something arising in the system’s environment at a specific point in time and requiring a preplanned response. In the next chapter, the identified events will be used to create a detailed model of system behavior.

Chapter 3: References

1. J. Clark, S. Mellor, and P. Ward, “An Application of Event Modeling to the Specification of an Avionics Simulator.” Paper Presented at Structured Development Forum VI, Long Beach, February 1985.