In a centralized control model, one component is designated as the controller and is responsible for managing the execution of other components. Centralized control models fall into two classes, depending on whether the controlled components execute sequentially or in parallel.
- The call–return model This is the familiar top-down subroutine model where control starts at the top of a subroutine hierarchy and, through subroutine calls, passes to lower levels in the tree. The subroutine model is only applicable to sequential systems.
- The manager model This is applicable to concurrent systems. One system component is designated as a system manager and controls the starting, stopping, coordination and scheduling of other system processes. A process is a component or module that can execute in parallel with other processes. A form of this model may also be applied in sequential systems where a management routine calls particular components depending on the values of some state variables. This is usually implemented as a case statement.
The call–return model is illustrated in the following diagram. The main program can call Routines 1, 2 and 3; Routine 1 can call Routines 1.2 or 1.2; Routine 3 can call Routines 3.1 or 3.2; and so on. This is a model of the program dynamics. It is not a structural model; there is no need for Routine 1.1, for example, to be part of Routine 1.
This familiar model is embedded in programming languages such as C, Ada and Pascal. Control passes from a higher-level routine in the hierarchy to a lower-level routine. It then returns to the point where the routine was called. The currently executing subroutine has responsibility for control and can either call other routines or return control to its parent. It is poor programming style to return to some other point in the program.
This call–return model may be used at the module level to control functions or objects. Subroutines in a programming language that are called by other subroutines are naturally functional. However, in many object-oriented systems, operations on objects (methods) are implemented as procedures or functions. For example, when a Java object requests a service from another object, it does so by calling an associated method.
The rigid and restricted nature of this model is both a strength and a weakness. It is a strength because it is relatively simple to analyse control flows and work out how the system will respond to particular inputs. It is a weakness because exceptions to normal operation are awkward to handle.
The diagram below is an illustration of a centralised management model of control for a concurrent system. This model is often used in ‘soft’ real-time systems which do not have very tight time constraints. The central controller manages the execution of a set of processes associated with sensors and actuators. The building monitoring system discussed in Chapter 21 uses this model of control.
The system controller process decides when processes should be started or stopped depending on system state variables. It checks if other processes have produced information to be processed or to pass information to them for processing. The controller loops continuously, polling sensors and other processes for events or state changes. For this reason, this model is sometimes called an event-loop model.