Reading, Short Answer And Discussion (400 Words) The first two questions are short answer and require reading. The third question is the discussion questi

Reading, Short Answer And Discussion (400 Words) The first two questions are short answer and require reading.

The third question is the discussion question.

No cited needed Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 1

Beyond Objects:
A Software Design Paradigm Based on Process Control

Mary Shaw
Carnegie Mellon University

Pittsburgh PA 15213

mary.shaw@cs.cmu.edu

Abstract

A standard demonstration problem in object-oriented programming is the design of an automobile cruise
control. This design exercise demonstrates object-oriented techniques well, but it does not ask whether the
object-oriented paradigm is the best one for the task. Here we examine the alternative view that cruise
control is essentially a control problem. We present a new software organization paradigm motivated b y
process control loops. The control view leads us to an architecture that is dominated by analysis of a
classical feedback loop rather than by the identification of discrete stateful components to treat as objects.
The change in architectural model calls attention to important questions about the cruise control task that
aren’t addressed in an object-oriented design.

1 . Design Idioms for Software Architectures

Explicit organization patterns, or idioms, increasingly guide the composition of modules into complete systems.
This stage of the design is usually called the architecture, and a number of common patterns are in general, though
quite informal, use [Garlan and Shaw 93]. One of these, the object-oriented architecture [Booch 86], is the subject
of much current attention. Although several architectural idioms have strong advocates, no single paradigm domi-
nates. The choice of an architecture should instead depend on the computational character of the application.

Here we explore a software idiom based on process control loops. This system organization is not widely
recognized in the software community; nevertheless it seems to quietly appear within designs dominated by other
models. Unlike object-oriented or functional design, which are characterized by the kinds of components that
appear, control loop designs are characterized both by the kinds of components and the special relations that must
hold among the components.

The paper first explains process control models and derives a software paradigm for control loop organizations.
Then it applies the result to a well-known problem, the design of a cruise control system. The differences between
the control-loop-based and the object-oriented designs reveal relative strengths of the models for problems of this
kind. The control view clarifies the different roles played by various problem inputs; further, it helps the designer
recognize a safety problem and a system limitation. Drawing on the knowledge of process control also offers
prospects for design guidance and quantitative analysis of system response characteristics.

1 . 1 . Process control paradigms

Continuous processes of many kinds convert input materials to products with specific properties by performing
operations on the inputs and on intermediate products. The values of measurable properties of system state
(materials, equipment settings, etc.) are called the variables of the process. Process variables that measure the
output materials are called the controlled variables of the process. The properties of the input materials,
intermediate products, and operations are captured in other process variables. In particular, the manipulated
variables are associated with things that can be changed by the control system in order to regulate the process.
Process variables must not be confused with program variables; this error can lead to disaster [Åström and
Wittenmark 84, Leveson 86, Perry 84, Seborg et al 89].

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 2

Process Control Definitions
Process variables: properties of the process that can be measured; several specific kinds are

often distinguished. Do not confuse process variables with program variables.
Controlled variable: process variable whose value the system is intended to control
Input variable: process variable that measures an input to the process
Manipulated variable: process variable whose value can be changed by the controller
Set point: the desired value for a controlled variable
Open loop system: system in which information about process variables is not used to

adjust the system.
Closed loop system: system in which information about process variables is used to ma-

nipulate a process variable to compensate for variations in process variables and
operating conditions.

Feedback control system: the controlled variable is measured and the result is used to
manipulate one or more of the process variables

Feedforward control system: some of the process variables are measured and disturbances
are compensated for without waiting for changes in the controlled variable to be visible.

The purpose of a control system is to maintain specified properties of the outputs of the process at (sufficiently
near) given reference values called the set points. If the input materials are pure, if the process is fully-defined, and
if the operations are completely repeatable, the process can simply run without surveillance. Such a process is
called an open loop system. Figure 1 shows such a system, a hot-air furnace that uses a constant burner setting to
raise the temperature of the air that passes through. A similar furnace that uses a timer to turn the burner off and
on at fixed intervals is also an open loop system.

Furnace Hot Air

Return Air

Figure 1: Open loop temperature control

The open-loop assumptions are rarely valid for physical processes in the real world. More often, properties such
as temperature, pressure and flow rates are monitored, and their values are used to control the process by changing
the settings of apparatus such as valves, heaters, and chillers. Such systems are called closed loop systems. A
home thermostat is a common example: the air temperature at the thermostat is measured, and the furnace is turned
on and off as necessary to maintain the desired temperature (the set point). Figure 2 shows the addition of a
thermostat to convert Figure 1 to a closed-loop system.

Furnace Hot Air

Return Air

Thermostat

Temperature-setting control

Temperature sensor

Gas valve control

Figure 2: Closed loop temperature control

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 3

There are two general forms of closed loop control. Feedback control, illustrated in Figure 3, adjusts the process
based on measurements of the controlled variable. The important components of a feedback controller are the
process definition, the process variables (including designated input and controlled variables), a sensor to obtain the
controlled variable from the physical output, the set point (target value for the controlled variable), and a control
algorithm. Figure 2 corresponds to Figure 3 in the following ways: The furnace with burner is the process; the
thermostat is the controller; the return air temperature is the input variable; the hot air temperature is the con-
trolled variable; the thermostat setting is the set point; and the temperature sensor is the sensor.

Set Point

Process
Controller

Controlled
Variable

∆ s to
Manipulated

Variables

Input Variables

Figure 3: Feedback Control

Feedforward control, shown in Figure 2, anticipates future effects on the controlled variable by measuring other
process variables whose values may be more timely; it adjusts the process based on these variables. The
important components of a feedforward controller are essentially the same as for a feedback controller except that
the sensor(s) obtain values of input or intermediate variables. It is valuable when lags in the process delay the
effect of control changes.

Set Point

Process

Controller

Controlled
Variable

∆ s to
Manipulated

Variables

Input Variables

Figure 4: Feedforward Control

These are simplified models. They do not deal with complexities such as properties of sensors, transmission
delays, and calibration issues. They ignore the response characteristics of the system such as gain, lag, and
hysteresis. They don’t show how to combine feedforward and feedback or choose which process variables to
manipulate. Chemical engineering provides excellent quantitative models for predicting how processes will react
to various control algorithms; indeed there are a number of standard strategies [Perry 84, Section 22]. These are
mentioned in Section 3.4, but detailed discussion is beyond the scope of this paper.

1 . 2 . Software paradigm for process control

We usually think of software as algorithmic: we compute outputs (or execute continuous systems) solely on the
basis of the inputs. This normal model does not allow for external perturbations; if non-input values of a
computation change spontaneously, this is regarded as a hardware error. The normal software model corresponds to
an open loop system; in most cases it is entirely appropriate. However, when the operating conditions of a
software system are not completely predictable—especially when the software is operating a physical system—the
purely algorithmic model breaks down. When the execution of a software system is affected by external

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 4

disturbances—forces or events that are not directly visible to or controllable by the software—this is an indication
that a control paradigm should be considered for the software architecture.

We can now establish a paradigm for software that controls continuous processes. The elements of this pattern
incorporate the essential parts of a process control loop, and the methodology requires explicit identification of
these parts:

Computational elements: separate the process of interest from the control policy.

Process definition, including mechanisms for manipulating some process variables.

Control algorithm to decide how to manipulate process variables, including a model for how the
process variables reflect the true state.

Data elements: continuously updated process variables and sensors that collect them.

Process variables, including designated input, controlled, and manipulated variables and knowledge
of which can be sensed.

Set point, or reference value for controlled variable.

Sensors to obtain values of process variables pertinent to control.

The control loop paradigm establishes the relation that the control algorithm exercises surveillance:
it collects information about the actual and intended states of the process and tunes the process
variables to drive the actual state toward the intended state.

The two computational elements separate issues about desired functionality from issues about responses to
external disturbances. For a software system, we can bundle the process and the process variables; that is we can
regard the process definition together with the process variables and sensors as a single subsystem whose input and
controlled variables are visible in the subsystem interface. We can then bundle the control algorithm and the set
point as a second subsystem; this controller has continuous access to current values of the set point and the
monitored variables; for a feedback system, this will be the controlled variable. There are two interactions between
these major systems: the controller receives values of process variables from the process, and the controller
supplies continuous guidance to the process about changes to the manipulated variables.

The result is a particular kind of dataflow architecture. The primary characteristic of dataflow architectures is that
the components interact by providing data to each other, each component executing when data is available. Most
dataflow architectures involve independent (often concurrent) processes and pacing that depends on the rates at
which the processes provide data for each other. The control loop paradigm assumes further that data related to
process variables is updated continuously.

Other, perhaps more familiar, members of the dataflow family are batch sequential processing and pipe-and-filter
architectures. Both are largely linear: data enters the system and is processed progressively by a number of distinct
computations. In batch sequential architectures each phase runs to completion and delivers the result (historically
as a magnetic tape!) to the next. In pipe-and-filter architectures, on the other hand, each filter processes its input
stream incrementally (in unix, by characters or lines) so the filters can operate concurrently, at least in principle.
The control loop architecture described here differs from both by the commitment to a dataflow loop and in the
intrinsic asymmetry of the control element from the process element.

It is appropriate to consider a control loop design when:

• the task involves continuing action, behavior, or state

• the software is embedded; that is, it controls a physical system

• uncontrolled, or open loop, computation does not suffice, usually because of external perturbations
or imprecise knowledge of the external state

2 . Cruise control

2 . 1 . The cruise control problem

Disciplines often work out the details of their methods through type problems, common examples used by many
different people to compare their models and methods [Shaw et al nd]. Booch and others have used the cruise
control problem to explore the differences between object-oriented and functional (traditional procedural)
programming [Atlee and Gannon 91, Booch 86, Ward 84]. As given by Booch, this problem is:

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 5

A cruise control system exists to maintain the speed of a car, even over varying terrain. In Figure 5 we see
the block diagram of the hardware for such a system.

System on/off

Engine on/off

Pulses from wheel

Accelerator

Brake

Increase/decrease speed

Resume speed

Clock

Throttle
Cruise
Control
System

Figure 5: Booch block diagram for cruise control

There are several inputs:

• System on/off If on, denotes that the cruise-control system should maintain the car
speed.

• Engine on/off If on, denotes that the car engine is turned on; the cruise-control
system is only active if the engine is on.

• Pulses from wheel A pulse is sent for every revolution of the wheel.

• A c c e l e r a t o r Indication of how far the accelerator has been pressed.

• B r a k e On when the brake is pressed; the cruise-control system temporarily
reverts to manual control if the brake is pressed.

• Increase/Decrease Speed Increase or decrease the maintained speed; only applicable if the
cruise-control system is on.

• R e s u m e Resume the last maintained speed; only applicable if the cruise-
control system is on.

• C l o c k Timing pulse every millisecond.

There is one output from the system:

• T h r o t t l e Digital value for the engine throttle setting.

The problem does not clearly state the rules for deriving the output from the set of inputs. Booch provides a
certain amount of elaboration in the form of a data flow diagram, but some questions remain unanswered. In the
design below, missing details are supplied to match the apparent behavior of the cruise control on the author’s car.
Moreover, the inputs provide two kinds of information: whether the cruise control is active, and if so what speed it
should maintain.

The problem statement says the output is a value for the engine throttle setting. In classical process control the
corresponding signal would be a change in the throttle setting; this avoids calibration and wear problems with the
sensors and engine. A more conventional cruise control requirement would thus specify control of the current
speed of the vehicle. However, current speed is not explicit in the problem statement, though it does appear
implicitly as “maintained speed” in the descriptions of some of the inputs. If the requirement addresses current
speed, throttle setting remains an appropriate output from the control algorithm. To avoid unnecessary changes
in the problem we assume accurately calibrated digital control and achieve the effect of incremental signals by
retaining the previous throttle value in the controller.

The problem statement also specifies a millisecond clock. In the object-oriented solution, the clock is used
only in combination with the wheel pulses to determine the current speed. Presumably the process that
computes the speed will count the number of clock pulses between wheel pulses. A typical automobile tire has a
circumference of about 6 feet, so at 60 mph (88 ft/sec) there will be about 15 wheel pulses per second. The
problem is overspecified in this respect: a slower clock or one that delivered current time on demand with sufficient
precision would also work and would require less computing. Further, a single system clock is not required by the
problem, though it might be convenient for other reasons.

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 6

These considerations lead to a restatement of the problem: Whenever the system is active, determine the desired
speed and control the engine throttle setting to maintain that speed.

2 . 2 . Object view of cruise control

Booch structures an object-oriented decomposition of the system around objects that exist in the task description.
This yields a decomposition whose elements correspond to important quantities and physical entities in the
system. The result appears in Figure 6, where the blobs represent objects and the directed lines represent
dependencies among objects. Although the target speed did not appear explicitly in the problem statement, it does
appear in Figure 6 as “Desired Speed”.

Throttle

Desired
Speed

Accelerator

Engine

Brake

Driver

Clock

Current
Speed

Wheel

Figure 6: Booch’s object-oriented design for cruise control

2 . 3 . Process control view of cruise control

Section 1.2 suggests the selection of a control loop architecture when the software is embedded in a physical
system that involves continuing behavior, especially when the system is subject to external perturbations. These
conditions hold in the case of cruise control: the system is supposed to maintain constant speed in an automobile
despite variations in terrain, vehicle load, air resistance, fuel quality, etc. To develop a control loop architecture
for this system, we begin by identifying the essential system elements as described in Section 1.2:

Computational elements
• Process definition: Since the cruise control software is driving a mechanical device (the engine), the

details are not relevant. For our purposes, the process receives a throttle setting and turns the car’s
wheels. There may in fact be more computers involved, for example in controlling the fuel-injection
system. From the standpoint of the cruise control subsystem, however, the process takes a throttle
setting as input and controls the speed of the vehicle.

• Control algorithm: This algorithm models the current speed based on the wheel pulses,
compares it to the desired speed, and changes the throttle setting. The clock input is needed to
model current speed based on intervals between wheel pulses. Since the problem requires an
exact throttle setting rather than a change, the current throttle setting must be maintained by the
control algorithm. The policy decision about how much to change the throttle setting for a given
discrepancy between current speed and current speed is localized in the control algorithm.

Data elements
• Controlled variable: For the cruise control, this is the current speed of the vehicle.
• Manipulated variable: For the cruise control, this is the throttle setting.
• Set point: The desired speed is set and modified by the accelerator input and the

increase/decrease speed input, respectively. Several other inputs help control whether the cruise
control is currently controlling the car: System on/off, engine on/off, brake, and resume.

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 7

These interact: resume restores automatic control, but only if the entire system is on. These inputs
are provided by the human driver (the operator, in process terms).

• Sensor for controlled variable: For cruise control, the current state is the current speed, which is
modeled on data from a sensor that delivers wheel pulses using the clock. However, see
discussion below about the accuracy of this model.

The restated control task was, “Whenever the system is active determine the desired speed and control the engine
throttle setting to maintain that speed.” Note that only the current speed output, the wheel pulses input, and
the throttle manipulated variable are used outside the set point and active/inactive determination. This leads
immediately to two subproblems: the interface with the driver, concerned with “whenever the system is active
determine the desired speed” and the control loop, concerned with “control the engine throttle setting to maintain
that speed.”

The latter is the actual control problem; we’ll examine it first. Figure 7 shows a suitable architecture for the
control system. The first task is to model the current speed from the wheel pulses; the designer should
validate this model carefully. The model could fail if the wheels spin; this could affect control in two ways. If the
wheel pulses are being taken from a drive wheel and the wheel is spinning, the cruise control would keep the
wheel spinning (at constant speed) even if the vehicle stops moving. Even worse, if the wheel pulses are being
taken from a non-drive wheel and the drive wheels are spinning, the controller will be misled to believe that the
current speed is too slow and will continually increase the throttle setting. The designer should also consider
whether the controller has full control authority over the process. In the case of cruise control, the only
manipulated variable is the throttle ; the brake is not available. As a result, if the automobile is coasting faster
than the desired speed, the controller is powerless to slow it down.

The controller also receives two inputs from the set point computation: the active/inactive t o g g l e, which
indicates whether the controller is in charge of the throttle , and the desired speed, which only needs to be valid
when the vehicle is under automatic control. All this information should be either state or continuously updated
data, so all lines in the diagram represent data flow. The controller is implemented as a continuously-evaluating
function that matches the dataflow character of the inputs and outputs. Several implementations are possible,
including variations on simple on/off control, proportional control, and more sophisticated disciplines. Each of
these has a parameter that controls how quickly and tightly the control tracks the set point; analysis of these
characteristics is discussed in Section 3.4. As noted above, the engine is of little interest here; it might very well
be implemented as an object or as a collection of objects.

Desired
Speed

Engine

Controller

Pulses From Wheel

Throttle
Setting

Active/Inactive
Toggle

Wheel Rotation

Figure 7: Control Architecture for Cruise Control

The set point calculation divides naturally into two parts: (a) determining whether or not the automatic system is
active—in control of the throttle and (b) determining the desired speed for use by the controller in automatic
mode.

Some of the inputs in the original problem definition capture state (system on/off, engine on/off,
accelerator, brake) and others capture events (wheel pulses, increase/decrease speed, resume, clock).
We will treat accelerator as state, specifically as a continuously-updated value. However, the determination of
whether the automatic cruise control is actively controlling the car is cleaner if everything it depends on is of the

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 8

same kind. We will therefore use transitions between states for system on/off, engine on/off, and brake.
For simplicity we assume brake application is atomic so other events are blocked when the brake is on. A more
detailed analysis of the system states would relax this assumption [Atlee and Gannon 91].

The active/inactive toggle is triggered by a variety of events, so a state transition design is natural. It’s shown in
Figure 8. The system is completely off whenever the engine is off. Otherwise there are three inactive and one
active states. In the first inactive state no set point has been established. In the other two, the previous set point
must be remembered: When the driver accelerates to a speed greater than the set point, the manual accelerator
controls the throttle through a direct linkage (note that this is the only use of the accelerator position in this
design, and it relies on relative effect rather than absolute position); when the driver uses the brake the control
system is inactivated until the resume signal is sent. The active/inactive t o g g l e input of the control system
is set to active exactly when this state machine is in state Active.

OFF Inactive
nil

Inactive
fast

Inactive
slow

ACTIVE
Engine On System On

All states

Accel ↑ Set Point
Accel ↓ Set Point

Brake Resume
Engine Off

All states
except OFF

System Off

Figure 8: State Machine for Activation

Determining the desired speed is simpler, since it does not require state other than the current value of desired
speed (the set point). Any time the system is off, the set point is undefined. Any time the system on signal
is given (including when the system is already on) the set point is set to the current speed as modeled by w h e e l
pulses. The driver also has a control that increases or decreases the set point by a set amount. This, too, can be
invoked at any time (define arithmetic on undefined values to yield undefined values). Figure 9 summarizes the
events involved in determining the set point. Note that this process requires access to the clock in order to
estimate the current speed based on the pulses from the wheel.

Event Effect on desired speed

Engine off, system off Set to “undefined”
System on Set to current speed as estimated from wheel pulses
Increase speed Increment desired speed by constant
Decrease speed Decrement desired speed by constant

Figure 9: Event Table for Determining Set Point

We can now (Figure 10) compose the control architecture, the state machine for activation, and the event table for
determining the set point into an entire system. Although there is no need for the control unit and set point
determination to use the same clock, we do so to minimize changes to the original problem statement. Then,
since current speed is used in two components, it would be reasonable for the next elaboration of the design to
encapsulate that model in a reusable object; this would encapsulate the clock.

All of the objects in Booch’s design (Figure 6) have clear roles in the resulting system. It is entirely reasonable to
look forward to a design strategy in which the control loop architecture is used for the system as a whole and a
number of other architectures, including objects and state machines, are used in the elaborations of the elements of
the control loop architecture.

Mary Shaw Beyond Objects: A Software Design Paradigm Based on Process Control 9

The shift from an object-oriented view to a control view of the cruise control architecture raised a number of design
questions that had previously been slighted: The separation of process from control concerns led to explicit choice
of the control discipline. The limitations of the control model also became clear, including possible inaccuracies
in the current speed model and incomplete control at high speed. The dataflow character of the model showed
irregularities in the way the input was specified, for example mixture of state and event inputs and the
inappropriateness of absolute position of the accelerator.

Desired
Speed

Wheel Rotation Control
Unit

Active/Inactive
Toggle

State
Machine

for Toggle

Event Table
for Set
Point

Clock

Figure 10: Complete cruise control system

3 . Analysis and Discussion

3 . 1 . Correspondence between architecture and problem

The selection of an architecture commits the designer to a particular view of a problem. Like any abstraction, this
emphasizes some aspects of the problem and suppresses others. Booch [Booch 86] characterizes the views inherent
in object-oriented and functional architectures:

Simply stated, object-oriented development is an approach to software design in which the decomposition
of a system is based upon the concept of an object. An object is an entity whose behavior is characterized
by the actions that it suffers and that it requires of other objects. Object-oriented development i s
fundamentally different from traditional functional methods, for which the primary criteria for
decomposition is that each module in the system represents a major step in the overall process.

The issue, of course, is deciding which abstractions are most useful for any particular problem. We have argued
that the control view is particularly appropriate for a certain class of problems. In this case, the control view
clarifies the design in several ways:

• The control view leads us to respecify the output as the actual speed …