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