SOFTWARE ARCHITECTURE

Unit II
 Process Control Architecture
• Process Control /Process Control Paradigms:

• Usually associated with real-time control of physical processes.

• The system maintaints specified properties of the output process near a

reference value.

• The flow of data comes from a set of variables called process variable , which

controls the execution of process.

• It decomposes the entire system into subsystems or modules and connects

them.
Process Control Architecture
Process Control Architecture
 Types of Subsystems
A process control architecture would have a processing unit for changing the process

control variables and a controller unit for calculating the amount of changes.

A controller unit must have the following elements −

Controlled Variable − Controlled Variable provides values for the underlying system and

should be measured by sensors. For example, speed in cruise control system.

Input Variable − Measures an input to the process. For example, temperature of return air

in temperature control system

Manipulated Variable − Manipulated Variable value is adjusted or changed by the

controller.
Process variables − It includes mechanisms for manipulating some process variables.

Sensor − Obtains values of process variables pertinent to control and can be used as a feedback

reference to recalculate manipulated variables.

Set Point − It is the desired value for a controlled variable.

Control Algorithm − It is used for deciding how to manipulate process variables.

Open Loop Systems: If the process is completely defined, repeatable, and the process runs

without surveillance

Space Heater

Closed Loop Systems: Output is used to control the inputs to maintain a monitored value

Speed Control, etc. Feed back and Feed Forward controller.

 Application Areas
Process control architecture is suitable in the following domains −

Embedded system software design, where the system is manipulated by process control
variable data.

Applications, which aim is to maintain specified properties of the outputs of the process
at given reference values.

Applicable for car-cruise control and building temperature control systems.

Real-time system software to control automobile anti-lock brakes, nuclear power plants,
car-cruise control System
Temperature control System
 A software Paradigm for Process Control

Compute outputs (or execute continuous systems) solely on the basis of the inputs.

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 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.

14
 A software Paradigm for Process Control

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

Data Elements

Control Loop Paradigm

15
 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.

16
 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.

17
• 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.

18
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.

19
 Other Familiar Architectures
Distributed processes: Distributed systems have developed a number of

common organizations for multi-process systems [37]. Some can be

characterized primarily by their topological features, such as ring and star

organizations.

Main program/subroutine organizations: The primary organization of many

systems mirrors the programming language in which the system is written. For

languages without support for modularization this often results in a system

organized around a main program and a set of subroutines. The main program

acts as the driver for the subroutines, typically providing a control loop for

sequencing through the subroutines in some order.

20
 Other Familiar Architectures
Domain-specific software architectures: Recently there has been considerable

interest in developing “reference” architectures for specific domains [39].

These architectures provide an organizational structure tailored to a family of

applications, such as avionics, command and control, or vehicle management

systems.

State transition systems: A common organization for many reactive systems is

the state transition system . These systems are defined in terms a set of states

and a set of named transitions that move a system from one state to another.

21
 Heterogeneous Architectures
most systems typically involve some combination of several styles.

There are different ways in which architectural styles can be combined. One

way is through hierarchy.

A component of a system organized in one architectural style may have an

internal structure that is developed a completely different style.

For example, in a Unix pipeline the individual components may be represented

internally using virtually any style— including, of course, another pipe and

filter, system.

22
 Heterogeneous Architectures
mixture of architectural connectors.

For example, a pipe connector may be implemented internally as a FIFO queue

accessed by insert and remove operations.

For example, a component might access a repository through part of its interface,

but interact through pipes with other components in a system, and accept control

information through another part of its interface.

23