In centralized control models, control decisions are usually determined by the values of some system state variables. By contrast, event-driven control models are driven by externally generated events. The term event in this context does not just mean a binary signal. It may be a signal that can take a range of values or a command input from a menu. The distinction between an event and a simple input is that the timing of the event is outside the control of the process that handles that event.
There are many types of event-driven systems. These include many editors where user interface events signify editing commands, rule-based production systems as used in AI where a condition becoming true causes an action to be triggered, and active objects where changing a value of an object’s attribute triggers some actions. Garlan et al. (1992) discuss these different types of system.
In this section, I discuss two event-driven control models:
- Broadcast models In these models, an event is, in principle, broadcast to all components. Any component that has been programmed to handle that event can respond to it.
- Interrupt-driven models These are exclusively used in real-time systems where external interrupts are detected by an interrupt handler. They are then passed to some other component for processing.
Broadcast models are effective in integrating components distributed across different computers on a network. Interrupt-driven models are used in real-time systems with stringent timing requirements.
In a broadcast model , components register an interest in specific events. When these events occur, control is transferred to the component that can handle the event. The distinction between this model and the centralized model is that the control policy is not embedded in the event and message handler. Components decide which events they require, and the event and message handler ensures that these events are sent to them.
All events could be broadcast to all components, but this imposes a great deal of processing overhead. More often, the event and message handler maintains a register of components and the events of interest to them. Components generate events indicating, perhaps, that some data is available for processing. The event handler detects the events, consults the event register and passes the event to those components who have declared an interest. In simpler systems, such as PC-based systems driven by user interface events, there are explicit ‘event listener’ components that listen for events from the mouse, the keyboard, etc. and translate these into more specific commands.
The event handler also usually supports point-to point communication. A component can explicitly send a message to another component. There have been a number of variations of this model, such as the Field environment (Reiss, 1990) and Hewlett-Packard’s Softbench (Fromme, 1993). Both of these have been used to control tool interactions in software engineering environments. Object Request Brokers (ORBs), as used in CORBA, also support this model of control for distributed object communications.
The advantage of this broadcast approach is that evolution is relatively simple. A new component to handle particular classes of events can be integrated by registering its events with the event handler. Any component can activate any other component without knowing its name or location. The components can be implemented on distributed machines. This distribution is transparent to other components.
The disadvantage of this model is that components don’t know if or when events will be handled. When a component generates an event it does not know which other components have registered an interest in that event. It is quite possible for different components to register for the same events. This may cause conflicts when the results of handling the event are made available.
Real-time systems that require externally generated events to be handled very quickly must be event-driven. For example, if a real-time system is used to control the safety systems in a car, it must detect a possible crash and, perhaps, inflate an airbag before the driver’s head hits the steering wheel. To provide this rapid response to events, you have to use interrupt-driven control.
An interrupt-driven control model is illustrated below. There are a known number of interrupt types with a handler defined for each type. Each type of interrupt is associated with the memory location where its handler’s address is stored. When an interrupt of a particular type is received, a hardware switch causes control to be transferred immediately to its handler. This interrupt handler may then start or stop other processes in response to the event signalled by the interrupt.
This model is mostly used in real-time systems where immediate response to some event is necessary. It may be combined with the centralised management model. The central manager handles the normal running of the system with interrupt-based control for emergencies.
The advantage of this approach is that it allows very fast responses to events to be implemented. Its disadvantages are that it is complex to program and difficult to validate. It may be impossible to replicate patterns of interrupt timing during system testing. It can be difficult to change systems developed using this model if the number of interrupts is limited by the hardware. Once this limit is reached, no other types of events can be handled. You can sometimes get around this limitation by mapping several types of events onto a single interrupt. The handler then works out which event has occurred. However, interrupt mapping may be impractical if a very fast response to individual interrupts is required.
References
Fromme B. and Walker, J. (1993). An Open Architecture for Tool and Process Integration. Proc.6th Conf. on Software Engineering Environments, Reading, UK, IEEE Press.
Reiss S., P. (1990). Connecting Tools Using Message Passing in the Field Environment. IEEE Software, 7(4), 57—66.