Embedded System

Concurrent Process Model

and Control Systems
 State Machine and
Concurrent Process Model
 Outline

Models vs. Languages

State Machine Model
 FSM/FSMD
 HCFSM and Statecharts Language
 Program-State Machine (PSM) Model
Concurrent Process Model
 Communication
 Synchronization
 Implementation
Dataflow Model
Real-Time Systems

- 3-
 Introduction

Describing embedded system’s processing behavior

 Can be extremely difficult
• Complexity increasing with increasing IC capacity
• Past: washing machines, small games, etc.
» Hundreds of lines of code
• Today: TV set-top boxes, Cell phone, etc.
» Hundreds of thousands of lines of code
• Desired behavior often not fully understood in beginning
• Many implementation bugs due to description
mistakes/omissions
 English (or other natural language) common starting point
• Precise description difficult to impossible
• Example: Motor Vehicle Code – thousands of pages
long...

- 4-
 An example of trying to be precise in English

California Vehicle Code

 Right-of-way of crosswalks
• 21950. (a) The driver of a vehicle shall yield the right-of-way to a pedestrian
crossing the roadway within any marked crosswalk or within any unmarked
crosswalk at an intersection, except as otherwise provided in this chapter.
• (b) The provisions of this section shall not relieve a pedestrian from the duty of
using due care for his or her safety. No pedestrian shall suddenly leave a curb or
other place of safety and walk or run into the path of a vehicle which is so close as
to constitute an immediate hazard. No pedestrian shall unnecessarily stop or delay
traffic while in a marked or unmarked crosswalk.
• (c) The provisions of subdivision (b) shall not relieve a driver of a vehicle from the
duty of exercising due care for the safety of any pedestrian within any marked
crosswalk or within any unmarked crosswalk at an intersection.
 All that just for crossing the street (and there’s much more)!

- 5-
 Models and languages

How can we (precisely) capture behavior?

 We may think of languages (C, C++), but computation model is the
key
Common computation models:
 Sequential program model
• Statements, rules for composing statements, semantics for executing
them
 Communicating process model
• Multiple sequential programs running concurrently
 State machine model
• For control dominated systems, monitors control inputs, sets control
outputs
 Dataflow model
• For data dominated systems, transforms input data streams into output
streams
 Object-oriented model
• For breaking complex software into simpler, well-defined pieces

- 6-
 Models vs. languages

Poetry Recipe Story State Sequent. Data-

Models machine program flow

Languages English Spanish Japanese C C++ Java

Recipes vs. English Sequential programs vs. C

Computation models describe system behavior

 Conceptual notion, e.g., recipe, sequential program
Languages capture models
 Concrete form, e.g., English, C
Variety of languages can capture one model
 E.g., sequential program model  C,C++, Java
One language can capture variety of models
 E.g., C++ → sequential program model, object-oriented model, state machine model
Certain languages better at capturing certain computation models

- 7-
 Text versus Graphics

Models versus languages not to be confused with text versus

graphics
 Text and graphics are just two types of languages
• Text: letters, numbers
• Graphics: circles, arrows (plus some letters, numbers)

X = 1; X=1
Y = X + 1;

Y=X+1

- 8-
 Introductory example: An elevator controller

Partial English description System interface

Simple elevator “Move the elevator either up or down Unit up

controller to reach the requested floor. Once at Control down

the requested floor, open the door for open
 Request Resolver at least 10 seconds, and keep it open
floor
until the requested floor changes.
resolves various floor Ensure the door is never open while req

moving. Don’t change directions Request

requests into single unless there are no higher requests Resolver
b1 buttons

requested floor when moving up or no lower requests

when moving down…”
... b2
inside
elevator

 Unit Control moves bN

up1 up/down
elevator to this up2 buttons
dn2 on each
requested floor up3
dn3
floor

Try capturing in C... ...

dnN

- 9-
 Elevator controller using a sequential program
model

System interface
Sequential program model
Partial English description
Inputs: int floor; bit b1..bN; up1..upN-1; dn2..dnN;
Unit up
Outputs: bit up, down, open;
Global variables: int req; “Move the elevator either up or down Control down
void UnitControl() void RequestResolver() to reach the requested floor. Once at open
{ { the requested floor, open the door for
up = down = 0; open = 1; while (1) floor
while (1) { ...
at least 10 seconds, and keep it open
until the requested floor changes. req
while (req == floor); req = ...
open = 0; ... Ensure the door is never open while Request
if (req > floor) { up = 1;} } Resolver
else {down = 1;}
moving. Don’t change directions b1 buttons
void main()
while (req != floor); unless there are no higher requests b2
inside
{ ... elevator
up = down = 0; Call concurrently: when moving up or no lower requests bN
open = 1; UnitControl() and when moving down…”
delay(10); RequestResolver() up1
} up/down
} up2 buttons
}
dn2 on each
up3 floor
dn3
You might have come up with something having ...
even more if statements. dnN

- 10 -
 Finite-state machine (FSM) model

Trying to capture this behavior as sequential program is a bit

awkward
Instead, we might consider an FSM model, describing the
system as:
 Possible states
• E.g., Idle, GoingUp, GoingDn, DoorOpen
 Possible transitions from one state to another based on input
• E.g., req > floor
 Actions that occur in each state
• E.g., In the GoingUp state, u,d,o,t = 1,0,0,0 (up = 1, down, open, and
timer_start = 0)
Try it...

- 11 -
 Finite-state machine (FSM) model

UnitControl process using a state machine

req > floor

u,d,o, t = 1,0,0,0 GoingUp !(req > floor)

req > floor timer < 10

u,d,o,t = 0,0,1,0 !(timer < 10)
Idle DoorOpen
req == floor u,d,o,t = 0,0,1,1
req < floor

u,d,o,t = 0,1,0,0 !(req<floor)

GoingDn

u is up, d is down, o is open

req < floor
t is timer_start

- 12 -
 Formal definition

An FSM is a 6-tuple F<S, I, O, F, H, s0>

 S is a set of all states {s0, s1, …, sl}
 I is a set of inputs {i0, i1, …, im}
 O is a set of outputs {o0, o1, …, on}
 F is a next-state function (S x I → S)
 H is an output function (S → O)
 s0 is an initial state
Moore-type
 Associates outputs with states (as given above, H maps S → O)
Mealy-type
 Associates outputs with transitions (H maps S x I → O)
Shorthand notations to simplify descriptions
 Implicitly assign 0 to all unassigned outputs in a state
 Implicitly AND every transition condition with clock edge (FSM is synchronous)

- 13 -
Finite-state machine with datapath model (FSMD)

FSMD extends FSM: complex data types and variables for storing data
 FSMs use only Boolean data types and operations, no variables
FSMD: 7-tuple <S, I , O, V, F, H, s0>
 S is a set of states {s0, s1, …, sl} We described UnitControl as an FSMD
 I is a set of inputs {i0, i1, …, im} req > floor
 O is a set of outputs {o0, o1, …, on}
u,d,o, t = 1,0,0,0 GoingUp !(req > floor)
 V is a set of variables {v0, v1, …, vn} req > floor timer < 10
 F is a next-state function (S x I x V → S) u,d,o,t = 0,0,1,0
Idle
!(timer < 10)
DoorOpen
 H is an action function (S → O + V) req == floor
req < floor
u,d,o,t = 0,0,1,1

 s0 is an initial state u,d,o,t = 0,1,0,0 !(req<floor)

GoingDn
u is up, d is down, o is open
req < floor t is timer_start

I,O,V may represent complex data types (i.e., integers, floating point, etc.)
F,H may include arithmetic operations
H is an action function, not just an output function
 Describes variable updates as well as outputs
Complete system state now consists of current state, si, and values of all variables

- 14 -
 Describing a system as a state machine

1. List all possible states 2. Declare all variables (none in this example)
3. For each state, list possible transitions, with conditions, to other states
4. For each state and/or transition, req > floor
list associated actions
5. For each state, ensure exclusive u,d,o, t = 1,0,0,0 GoingUp !(req > floor)
and complete exiting transition
conditions req > floor timer < 10

• No two exiting conditions can

u,d,o,t = 0,0,1,0
Idle !(timer < 10) DoorOpen
be true at same time req == floor
req < floor
u,d,o,t = 0,0,1,1

– Otherwise nondeterministic
state machine u,d,o,t = 0,1,0,0
!(req<floor)

• One condition must be true at

GoingDn

any given time u is up, d is down, o is open

– Reducing explicit transitions

req < floor
t is timer_start

should be avoided when first

learning

- 15 -
 State machine vs. sequential program model

Different thought process used with each model

State machine:
 Encourages designer to think of all possible states and transitions among
states based on all possible input conditions
Sequential program model:
 Designed to transform data through series of instructions that may be iterated
and conditionally executed
State machine description excels in many cases
 More natural means of computing in those cases
 Not due to graphical representation (state diagram)
• Would still have same benefits if textual language used (i.e., state table)
• Besides, sequential program model could use graphical representation (i.e.,
flowchart)

- 16 -
 Try Capturing Other Behaviors with an FSM

E.g., Answering machine blinking light when there are

messages
E.g., A simple telephone answering machine that answers
after 4 rings when activated
E.g., A simple crosswalk traffic control light
Others

- 17 -
 Capturing state machines in
sequential programming language
Despite benefits of state machine model, most popular development tools use
sequential programming language
 C, C++, Java, Ada, VHDL, Verilog, etc.
 Development tools are complex and expensive, therefore not easy to adapt or replace
• Must protect investment
Two approaches to capturing state machine model with sequential programming
language
 Front-end tool approach
• Additional tool installed to support state machine language
• Graphical and/or textual state machine languages
• May support graphical simulation
• Automatically generate code in sequential programming language that is input to main development tool
• Drawback: must support additional tool (licensing costs, upgrades, training, etc.)
 Language subset approach
• Most common approach...

- 18 -
 Language subset approach

Follow rules (template) for capturing

state machine constructs in #define IDLE0
#define GOINGUP1
equivalent sequential language #define GOINGDN2
#define DOOROPEN3
constructs void UnitControl() {
int state = IDLE;
Used with software (e.g.,C) and while (1) {
hardware languages (e.g.,VHDL) switch (state) {
IDLE: up=0; down=0; open=1; timer_start=0;
Capturing UnitControl state machine in if (req==floor) {state = IDLE;}
if (req > floor) {state = GOINGUP;}
C if (req < floor) {state = GOINGDN;}
 Enumerate all states (#define) break;
GOINGUP: up=1; down=0; open=0; timer_start=0;
 Declare state variable initialized to if (req > floor) {state = GOINGUP;}
if (!(req>floor)) {state = DOOROPEN;}
initial state (IDLE) break;
 Single switch statement branches to GOINGDN: up=1; down=0; open=0; timer_start=0;
if (req < floor) {state = GOINGDN;}
current state’s case if (!(req<floor)) {state = DOOROPEN;}
 Each case has actions break;
DOOROPEN: up=0; down=0; open=1; timer_start=1;
• up, down, open, timer_start if (timer < 10) {state = DOOROPEN;}
 Each case checks transition conditions if (!(timer<10)){state = IDLE;}
break;
}
to determine next state }
}
• if(…) {state = …;}
UnitControl state machine in sequential programming language

- 19 -
 General template

#define S0 0
#define S1 1
...
#define SN N
void StateMachine() {
int state = S0; // or whatever is the initial state.
while (1) {
switch (state) {
S0:
// Insert S0’s actions here & Insert transitions Ti leaving S0:
if( T0’s condition is true ) {state = T0’s next state; /*actions*/ }
if( T1’s condition is true ) {state = T1’s next state; /*actions*/ }
...
if( Tm’s condition is true ) {state = Tm’s next state; /*actions*/ }
break;
S1:
// Insert S1’s actions here
// Insert transitions Ti leaving S1
break;
...
SN:
// Insert SN’s actions here
// Insert transitions Ti leaving SN
break;
}
}
}

- 20 -
 HCFSM and the Statecharts language

Hierarchical/concurrent state machine model

(HCFSM)
 Extension to state machine model to support Without hierarchy With hierarchy
hierarchy and concurrency
 States can be decomposed into another state A1 z
A
A1 z
machine x w
• y B x
With hierarchy has identical functionality as Without y
w B
hierarchy, but has one less transition (z) A2 z
A2
• Known as OR-decomposition
 States can execute concurrently
• Known as AND-decomposition
Statecharts
Concurrency
 Graphical language to capture HCFSM
 timeout: transition with time limit as condition B
 history: remember last substate OR-decomposed C D

state A was in before transitioning to another state C1 D1

B x y u v
• Return to saved substate of A when returning from B
C2 D2
instead of initial state

- 21 -
 UnitControl with FireMode

req>floor UnitControl

u,d,o = 1,0,0 GoingUp

FireMode
req>floor
!(req>floor)  When fire is true, move elevator to
u,d,o = 0,0,1
Idle timeout(10) DoorOpen u,d,o = 0,0,1 1st floor and open door
req==floor fire
u,d,o = 0,1,0
req<floor !(req<floor)
fire
fire
u,d,o = 0,1,0
– w/o hierarchy: Getting messy!
GoingDn FireGoingDn
fire
floor==1 u,d,o = 0,0,1 – w/ hierarchy: Simple!
req<floor floor>1 FireDrOpen
!fire fire With hierarchy
Without hierarchy UnitControl
req>floor NormalMode

u,d,o = 1,0,0 GoingUp

!(req>floor)
req>floor
ElevatorController u,d,o = 0,0,1 u,d,o = 0,0,1
Idle DoorOpen
UnitControl RequestResolver req==floor timeout(10)
req<floor !(req>floor)
NormalMode u,d,o = 0,1,0 GoingDn
...
!fire fire req<floor
FireMode FireMode
fire
FireGoingDn u,d,o = 0,1,0
!fire
floor==1 u,d,o = 0,0,1
floor>1
With concurrent RequestResolver FireDrOpen
fire

- 22 -
Program-state machine model (PSM): HCFSM plus
sequential program model

Program-state’s actions can be FSM or ElevatorController

int req;
sequential program UnitControl RequestResolver
 Designer can choose most appropriate NormalMode
up = down = 0; open = 1; ...
Stricter hierarchy than HCFSM used in while (1) {
while (req == floor);
req = ...
...
Statecharts open = 0;
if (req > floor) { up = 1;}
 transition between sibling states only, single else {down = 1;}
entry while (req != floor);
open = 1;
 Program-state may “complete” delay(10);
• Reaches end of sequential program code, OR }
}
• FSM transition to special complete substate !fire fire
FireMode
• PSM has 2 types of transitions up = 0; down = 1; open = 0;
• Transition-immediately (TI): taken regardless of while (floor > 1);
source program-state up = 0; down = 0; open = 1;
• Transition-on-completion (TOC): taken only if
condition is true AND source program-state is
complete • NormalMode and FireMode described as
 SpecCharts: extension of VHDL to capture PSM sequential programs
model • Black square originating within FireMode
 SpecC: extension of C to capture PSM model indicates !fire is a TOC transition
– Transition from FireMode to NormalMode
only after FireMode completed

- 23 -
 Role of appropriate model and language

Finding appropriate model to capture embedded system is an important step

 Model shapes the way we think of the system
• Originally thought of sequence of actions, wrote sequential program
• First wait for requested floor to differ from target floor
• Then, we close the door
• Then, we move up or down to the desired floor
• Then, we open the door
• Then, we repeat this sequence
• To create state machine, we thought in terms of states and transitions among states
• When system must react to changing inputs, state machine might be best model
» HCFSM described FireMode easily, clearly
Language should capture model easily
 Ideally should have features that directly capture constructs of model
 FireMode would be very complex in sequential program
• Checks inserted throughout code
 Other factors may force choice of different model
• Structured techniques can be used instead
• E.g., Template for state machine capture in sequential program language

- 24 -
 Concurrent process model

Describes functionality of system in terms of two or more

concurrently executing subtasks
ConcurrentProcessExample() { Many systems easier to describe with concurrent process model
x = ReadX()
y = ReadY() because inherently multitasking
Call concurrently:
PrintHelloWorld(x) and
E.g., simple example:
PrintHowAreYou(y)  Read two numbers X and Y
}
PrintHelloWorld(x) {
 Display “Hello world.” every X seconds
while( 1 ) {  Display “How are you?” every Y seconds
print "Hello world."
delay(x); More effort would be required with sequential program or state
}
} machine model
PrintHowAreYou(x) {
while( 1 ) {
print "How are you?"
delay(y);
} Enter X: 1
} Enter Y: 2
Hello world. (Time = 1 s)
PrintHelloWorld
Hello world. (Time = 2 s)
Simple concurrent process example ReadX ReadY How are you? (Time = 2 s)
Hello world. (Time = 3 s)
PrintHowAreYou
How are you? (Time = 4 s)
Hello world. (Time = 4 s)
time ...

Subroutine execution over time Sample input and output

- 25 -
 Dataflow model

Derivative of concurrent process model Z = (A + B) * (C - D)

Nodes represent transformations
 May execute concurrently A B C D
Edges represent flow of tokens (data) from one node to another
 May or may not have token at any given time + –

When all of node’s input edges have at least one token, node t1 t2

may fire *

When node fires, it consumes input tokens processes

Z
transformation and generates output token
Nodes with arithmetic
Nodes may fire simultaneously transformations
Several commercial tools support graphical languages for
A B C D
capture of dataflow model
 Can automatically translate to concurrent process model for
modulate convolve
implementation t1 t2
 Each node becomes a process
transform

Z
Nodes with more complex
transformations

- 26 -
 Synchronous dataflow

With digital signal-processors (DSPs), data flows at fixed rate

Multiple tokens consumed and produced per firing
Synchronous dataflow model takes advantage of this
 Each edge labeled with number of tokens consumed/produced A B C D

each firing mA mB mC mD
 Can statically schedule nodes, so can easily use sequential
program model modulate convolve

• Don’t need real-time operating system and its overhead mt1 t1 t2 ct2
How would you map this model to a sequential programming tt1 tt2

language? Try it... transform

Algorithms developed for scheduling nodes into “single- tZ

appearance” schedules Z
 Only one statement needed to call each node’s associated
procedure Synchronous dataflow
• Allows procedure inlining without code explosion, thus reducing
overhead even more

- 27 -
Concurrent processes and
real-time systems
 Concurrent processes

Consider two examples Heartbeat Monitoring System

having separate tasks B[1..4]

Task 1:
Read pulse
Task 2:
If B1/B2 pressed then

running independently but If pulse < Lo then

Activate Siren
Lo = Lo +/– 1
If B3/B4 pressed then
If pulse > Hi then Hi = Hi +/– 1
sharing data Heart-beat Activate Siren
Sleep 1 second
Sleep 500 ms
Repeat
pulse
Difficult to write system using Repeat

sequential program model

Concurrent process model
easier
 Separate sequential Set-top Box
programs (processes) for Task 1:
Read Signal
Task 2:
Wait on Task 1
Video
each task Separate Audio/Video
Send Audio to Task 2
Decode/output Audio
Repeat
 Programs communicate with Input
Signal
Send Video to Task 3
Repeat Task 3: Audio
each other Wait on Task 1
Decode/output Video
Repeat

- 29 -
 Process

A sequential program, typically an infinite loop

 Executes concurrently with other processes
 We are about to enter the world of “concurrent programming”
Basic operations on processes
 Create and terminate
• Create is like a procedure call but caller doesn’t wait
• Created process can itself create new processes
• Terminate kills a process, destroying all data
• In HelloWord/HowAreYou example, we only created processes
 Suspend and resume
• Suspend puts a process on hold, saving state for later execution
• Resume starts the process again where it left off
 Join
• A process suspends until a particular child process finishes execution

- 30 -
 Communication among processes

Processes need to communicate data and Encoded video

packets
signals to solve their computation problem
 Processes that don’t communicate are just
processA() {
// Decode packet
// Communicate packet
independent programs solving separate problems to B
}
Basic example: producer/consumer }

 Process A produces data items, Process B

consumes them Decoded video
 E.g., A decodes video packets, B display decoded packets

packets on a screen void processB() {

// Get packet from A

How do we achieve this communication? }

// Display packet

 Two basic methods

• Shared memory
• Message passing
To display

- 31 -
 Shared Memory

Processes read and write shared variables 01: data_type buffer[N];

 No time overhead, easy to implement 02:
03:
int count = 0;
void processA() {
 But, hard to use – mistakes are common 04:
05:
int i;
while( 1 ) {
Example: Producer/consumer with a mistake 06: produce(&data);
07: while( count == N );/*loop*/
 Share buffer[N], count 08: buffer[i] = data;
• count = # of valid data items in buffer 09: i = (i + 1) % N;
 processA produces data items and stores in buffer 10: count = count + 1;
• If buffer is full, must wait 11: }
 12: }
processB consumes data items from buffer 13: void processB() {
• If buffer is empty, must wait 14: int i;
 Error when both processes try to update count concurrently (lines 10 and 15: while( 1 ) {
19) and the following execution sequence occurs. Say “count” is 3. 16: while( count == 0 );/*loop*/
• 17: data = buffer[i];
A loads count (count = 3) from memory into register R1 (R1 = 3)
18: i = (i + 1) % N;
• A increments R1 (R1 = 4) 19: count = count - 1;
• B loads count (count = 3) from memory into register R2 (R2 = 3) 20: consume(&data);
• B decrements R2 (R2 = 2) 21: }
• A stores R1 back to count in memory (count = 4) 22: }
• B stores R2 back to count in memory (count = 2) 23: void main() {
 count now has incorrect value of 2 24: create_process(processA);
25: create_process(processB);
26: }

- 32 -
 Message Passing

Message passing
 Data explicitly sent from one process to void processA() {
while( 1 ) {
another produce(&data)
send(B, &data);
• Sending process performs special operation, /* region 1 */
receive(B, &data);
send }
consume(&data);

• Receiving process must perform special }

operation, receive, to receive the data void processB() {

• Both operations must explicitly specify which while( 1 ) {
receive(A, &data);

process it is sending to or receiving from transform(&data)

send(A, &data);
• Receive is blocking, send may or may not be }
/* region 2 */

blocking }

 Safer model, but less flexible

- 33 -
 Back to Shared Memory: Mutual Exclusion

Certain sections of code should not be performed concurrently

 Critical section
• Possibly noncontiguous section of code where simultaneous updates, by multiple
processes to a shared memory location, can occur
When a process enters the critical section, all other processes must be
locked out until it leaves the critical section
 Mutex
• A shared object used for locking and unlocking segment of shared data
• Disallows read/write access to memory it guards
• Multiple processes can perform lock operation simultaneously, but only one process
will acquire lock
• All other processes trying to obtain lock will be put in blocked state until unlock
operation performed by acquiring process when it exits critical section
• These processes will then be placed in runnable state and will compete for lock
again

- 34 -
Correct Shared Memory Solution to the Consumer-
Producer Problem

The primitive mutex is used to ensure critical sections 01: data_type buffer[N];
02: int count = 0;
are executed in mutual exclusion of each other 03: mutex count_mutex;
Following the same execution sequence as before: 04:
05:
void processA() {
int i;
 A/B execute lock operation on count_mutex 06: while( 1 ) {
 Either A or B will acquire lock 07: produce(&data);
• Say B acquires it 08: while( count == N );/*loop*/
09: buffer[i] = data;
• A will be put in blocked state 10: i = (i + 1) % N;
 B loads count (count = 3) from memory into register R2 (R2 11: count_mutex.lock();
= 3) 12:
13:
count = count + 1;
count_mutex.unlock();
 B decrements R2 (R2 = 2) 14: }
 B stores R2 back to count in memory (count = 2) 15: }
 B executes unlock operation 16:
17:
void processB() {
int i;
• A is placed in runnable state again 18: while( 1 ) {
 A loads count (count = 2) from memory into register R1 (R1 19: while( count == 0 );/*loop*/
20: data = buffer[i];
= 2) 21: i = (i + 1) % N;
 A increments R1 (R1 = 3) 22: count_mutex.lock();
 A stores R1 back to count in memory (count = 3) 23: count = count - 1;
24: count_mutex.unlock();
Count now has correct value of 3 25: consume(&data);
26: }
27: }
28: void main() {
29: create_process(processA);
30: create_process(processB);
31: }

- 35 -
 Process Communication

Try modeling “req” value of our elevator System interface

controller Unit up

 Using shared memory Control down

open
 Using shared memory and mutexes floor

 Using message passing req

Request
Resolver
b1 buttons
inside
... b2 elevator
bN

up1 up/down
up2 buttons
dn2 on each
up3 floor
dn3
...
dnN

- 36 -
A Common Problem in Concurrent Programming:
Deadlock

Deadlock: A condition where 2 or more processes are

blocked waiting for the other to unlock critical sections
of code
 Both processes are then in blocked state
 Cannot execute unlock operation so will wait forever 01:
02:
mutex mutex1, mutex2;
void processA() {
Example code has 2 different critical sections of code that 03:
04:
while( 1 ) {
…
can be accessed simultaneously 05:
06:
mutex1.lock();
/* critical section 1 */
 2 locks needed (mutex1, mutex2) 07: mutex2.lock();
 Following execution sequence produces deadlock 08: /* critical section 2 */
09: mutex2.unlock();
• A executes lock operation on mutex1 (and acquires it) 10: /* critical section 1 */
• B executes lock operation on mutex2( and acquires it) 11: mutex1.unlock();
• A/B both execute in critical sections 1 and 2, respectively 12: }
13: }
• A executes lock operation on mutex2 14: void processB() {
• A blocked until B unlocks mutex2 15: while( 1 ) {
• B executes lock operation on mutex1 16: …
• 17: mutex2.lock();
B blocked until A unlocks mutex1 18: /* critical section 2 */
• DEADLOCK! 19: mutex1.lock();
One deadlock elimination protocol requires locking of 20:
21:
/* critical section
mutex1.unlock();
1 */

numbered mutexes in increasing order and two-phase 22:

23:
/* critical section
mutex2.unlock();
2 */

locking (2PL) 24:

25: }
}
 Acquire locks in 1st phase only, release locks in 2nd phase

- 37 -
 Synchronization among processes

Sometimes concurrently running processes must synchronize their

execution
 When a process must wait for:
• another process to compute some value
• reach a known point in their execution
• signal some condition
Recall producer-consumer problem
 processA must wait if buffer is full
 processB must wait if buffer is empty
 This is called busy-waiting
• Process executing loops instead of being blocked
• CPU time wasted
More efficient methods
 Join operation, and blocking send and receive discussed earlier
• Both block the process so it doesn’t waste CPU time
 Condition variables and monitors

- 38 -
 Condition variables

Condition variable is an object that has 2 operations, signal and wait

When process performs a wait on a condition variable, the process is
blocked until another process performs a signal on the same
condition variable
How is this done?
 Process A acquires lock on a mutex
 Process A performs wait, passing this mutex
• Causes mutex to be unlocked
 Process B can now acquire lock on same mutex
 Process B enters critical section
• Computes some value and/or make condition true
 Process B performs signal when condition true
• Causes process A to implicitly reacquire mutex lock
• Process A becomes runnable

- 39 -
 Condition variable example:
consumer-producer

2 condition variables Consumer-producer using condition variables

 buffer_empty 01: data_type buffer[N];
• Signals at least 1 free location available in buffer 02: int count = 0;
03: mutex cs_mutex;
 buffer_full 04: condition buffer_empty, buffer_full;
• Signals at least 1 valid data item in buffer 06: void processA() {
07: int i;
processA: 08: while( 1 ) {
09: produce(&data);
 produces data item 10: cs_mutex.lock();
 acquires lock (cs_mutex) for critical section 11: if( count == N ) buffer_empty.wait(cs_mutex);
13: buffer[i] = data;
 checks value of count 14: i = (i + 1) % N;
 if count = N, buffer is full 15: count = count + 1;
16: cs_mutex.unlock();
• performs wait operation on buffer_empty 17: buffer_full.signal();
• this releases the lock on cs_mutex allowing 18: }
19: }
processB to enter critical section, consume data 20: void processB() {
item and free location in buffer 21: int i;
22: while( 1 ) {
• processB then performs signal 23: cs_mutex.lock();
 if count < N, buffer is not full 24: if( count == 0 ) buffer_full.wait(cs_mutex);
26: data = buffer[i];
• processA inserts data into buffer 27: i = (i + 1) % N;
• increments count 28: count = count - 1;
29: cs_mutex.unlock();
• signals processB making it runnable if it has 30: buffer_empty.signal();
performed a wait operation on buffer_full 31: consume(&data);
32: }
33: }
34: void main() {
35: create_process(processA); create_process(processB);
37: }

- 40 -
 Monitors

Collection of data and methods or subroutines that

operate on data similar to an object-oriented Monitor
paradigm Monitor

Monitor guarantees only 1 process can execute DATA Waiting DATA

inside monitor at a time CODE
CODE

(a) Process X executes while Process Y has to wait

(b) Process X performs wait on a condition Process Process

Process
 Process Y allowed to enter and execute X Y
X
Process
Y
(a) (b)
(c) Process Y signals condition Process X waiting
on Monitor Monitor
 Process Y blocked DATA Waiting
 Process X allowed to continue executing DATA
CODE CODE
(d) Process X finishes executing in monitor or waits
on a condition again
 Process Y made runnable again
Process Process Process Process
X Y X Y
(c) (d)

- 41 -
 Monitor example: consumer-producer

Single monitor encapsulates both 01: Monitor {

processes along with buffer and count 02:
03:
data_type buffer[N];
int count = 0;
One process will be allowed to begin 04: condition buffer_full, condition buffer_empty;
06: void processA() {
executing first 07: int i;
If processB allowed to execute first 08:
09:
while( 1 ) {
produce(&data);
 Will execute until it finds count = 0 10: if( count == N ) buffer_empty.wait();
 Will perform wait on buffer_full condition 12: buffer[i] = data;
13: i = (i + 1) % N;
variable 14: count = count + 1;
 processA now allowed to enter monitor 15: buffer_full.signal();
and execute 16:
17: }
}
 processA produces data item 18: void processB() {
 finds count < N so writes to buffer and 19: int i;
20: while( 1 ) {
increments count 21: if( count == 0 ) buffer_full.wait();
 processA performs signal on buffer_full 23: data = buffer[i];
condition variable 24:
25:
i = (i + 1) % N;
count = count - 1;
 processA blocked 26: buffer_empty.signal();
 processB reenters monitor and continues 27: consume(&data);
28: buffer_full.signal();
execution, consumes data, etc. 29: }
30: }
31: } /* end monitor */
32: void main() {
33: create_process(processA); create_process(processB);
35: }

- 42 -
 Implementation

Mapping of system’s functionality

The choice of
onto hardware processors: computational
 captured using computational State
machine
Sequent.
program
Data-
flow
Concurrent
processes
model(s) is based
on whether it
model(s) allows the designer
to describe the
 written in some language(s) system.
Implementation choice independent
from language(s) choice The choice of
language(s) is
Implementation choice based on Pascal C/C++ Java VHDL
based on whether it
captures the
power, size, performance, timing computational
and cost requirements model(s) used by
the designer.
Final implementation tested for
feasibility The choice of
implementation is
 Also serves as blueprint/prototype for based on whether it
mass manufacturing of final product Implementation A Implementation
B
Implementation
C
meets power, size,
performance and
cost requirements.

- 43 -
 Concurrent process model:
implementation

Can use single and/or general-purpose processors

(a) Multiple processors, each executing one process Processor A

Communication Bus
 True multitasking (parallel processing) Process1
Processor B
 General-purpose processors Process2
• Use programming language like C and compile to (a) Process3 Processor C
instructions of processor Process4
Processor D
• Expensive and in most cases not necessary
 Custom single-purpose processors
• More common Process1
(b) One general-purpose processor running all Process2
General Purpose
processes (b) Process3 Processor
Process4
 Most processes don’t use 100% of processor time
 Can share processor time and still achieve necessary
execution rates
Processor A

Communication Bus
(c) Combination of (a) and (b)
Process1
 Multiple processes run on one general-purpose Process2 General
processor while one or more processes run on own (c) Process3 Purpose
single_purpose processor Process4 Processor

- 44 -
 Implementation:
multiple processes sharing single processor

Can manually rewrite processes as a single sequential program

 Ok for simple examples, but extremely difficult for complex examples
 Automated techniques have evolved but not common
 E.g., simple Hello World concurrent program from before would look like:
I = 1; T = 0;
while (1) {
Delay(I); T = T + 1;
if X modulo T is 0 then call PrintHelloWorld
if Y modulo T is 0 then call PrintHowAreYou
}
Can use multitasking operating system
 Much more common
 Operating system schedules processes, allocates storage, and interfaces to peripherals, etc.
 Real-time operating system (RTOS) can guarantee execution rate constraints are met
 Describe concurrent processes with languages having built-in processes (Java, Ada, etc.) or a
sequential programming language with library support for concurrent processes (C, C++, etc.
using POSIX threads for example)
Can convert processes to sequential program with process scheduling right in code
 Less overhead (no operating system)
 More complex/harder to maintain

- 45 -
 Processes vs. threads

Different meanings when operating system terminology

Regular processes
 Heavyweight process
 Own virtual address space (stack, data, code)
 System resources (e.g., open files)
Threads
 Lightweight process
 Subprocess within process
 Only program counter, stack, and registers
 Shares address space, system resources with other threads
• Allows quicker communication between threads
 Small compared to heavyweight processes
• Can be created quickly
• Low cost switching between threads

- 46 -
 Implementation:
suspending, resuming, and joining

Multiple processes mapped to single-purpose processors

 Built into processor’s implementation
 Could be extra input signal that is asserted when process suspended
 Additional logic needed for determining process completion
• Extra output signals indicating process done

Multiple processes mapped to single general-purpose processor

 Built into programming language or special multitasking library like
POSIX
 Language or library may rely on operating system to handle

- 47 -
 Implementation: process scheduling

Must meet timing requirements when multiple concurrent processes

implemented on single general-purpose processor
 Not true multitasking
Scheduler
 Special process that decides when and for how long each process is executed
 Implemented as preemptive or nonpreemptive scheduler
 Preemptive
• Determines how long a process executes before preempting to allow another
process to execute
• Time quantum: predetermined amount of execution time preemptive scheduler allows
each process (may be 10 to 100s of milliseconds long)
• Determines which process will be next to run
 Nonpreemptive
• Only determines which process is next after current process finishes execution

- 48 -
 Scheduling: priority

Process with highest priority always selected first by scheduler

 Typically determined statically during creation and dynamically during
execution
FIFO
 Runnable processes added to end of FIFO as created or become runnable
 Front process removed from FIFO when time quantum of current process is up
or process is blocked
Priority queue
 Runnable processes again added as created or become runnable
 Process with highest priority chosen when new process needed
 If multiple processes with same highest priority value then selects from them
using first-come first-served
 Called priority scheduling when nonpreemptive
 Called round-robin when preemptive

- 49 -
 Priority assignment

Period of process
 Repeating time interval the process must complete one execution within
• E.g., period = 100 ms
• Process must execute once every 100 ms Rate monotonic
 Usually determined by the description of the system
• E.g., refresh rate of display is 27 times/sec Process Period Priority
• Period = 37 ms
A 25 ms 5
Execution deadline B 50 ms 3
 Amount of time process must be completed by after it has started C 12 ms 6
• E.g., execution time = 5 ms, deadline = 20 ms, period = 100 ms D 100 ms 1
• Process must complete execution within 20 ms after it has begun regardless of its period E 40 ms 4
• F 75 ms 2
Process begins at start of period, runs for 4 ms then is preempted
• Process suspended for 14 ms, then runs for the remaining 1 ms
• Completed within 4 + 14 + 1 = 19 ms which meets deadline of 20 ms Deadline monotonic
• Without deadline process could be suspended for much longer
Rate monotonic scheduling Process Deadline Priority
 Processes with shorter periods have higher priority G 17 ms 5
 Typically used when execution deadline = period H 50 ms 2
I
Deadline monotonic scheduling J
32 ms
10 ms
3
6
 Processes with shorter deadlines have higher priority K 140 ms 1
 Typically used when execution deadline < period L 32 ms 4

- 50 -
 Real-time systems

Systems composed of 2 or more cooperating, concurrent processes with

stringent execution time constraints
 E.g., set-top boxes have separate processes that read or decode video and/or
sound concurrently and must decode 20 frames/sec for output to appear
continuous
 Other examples with stringent time constraints are:
• digital cell phones
• navigation and process control systems
• assembly line monitoring systems
• multimedia and networking systems
• etc.
 Communication and synchronization between processes for these systems is
critical
 Therefore, concurrent process model best suited for describing these systems

- 51 -
 Real-time operating systems (RTOS)

Provide mechanisms, primitives, and guidelines for building real-time embedded systems
Windows CE
 Built specifically for embedded systems and appliance market
 Scalable real-time 32-bit platform
 Supports Windows API
 Perfect for systems designed to interface with Internet
 Preemptive priority scheduling with 256 priority levels per process
 Kernel is 400 Kbytes
QNX
 Real-time microkernel surrounded by optional processes (resource managers) that provide POSIX
and UNIX compatibility
• Microkernels typically support only the most basic services
• Optional resource managers allow scalability from small ROM-based systems to huge multiprocessor systems
connected by various networking and communication technologies
 Preemptive process scheduling using FIFO, round-robin, adaptive, or priority-driven scheduling
 32 priority levels per process
 Microkernel < 10 Kbytes and complies with POSIX real-time standard

- 52 -
 Summary

Computation models are distinct from languages

Sequential program model is popular
 Most common languages like C support it directly
State machine models good for control
 Extensions like HCFSM provide additional power
 PSM combines state machines and sequential programs
Concurrent process model for multi-task systems
 Communication and synchronization methods exist
 Scheduling is critical
Dataflow model good for signal processing

- 53 -
Control Systems
 Control System

Control physical system’s output

 By setting physical system’s input
Tracking
E.g.
 Cruise control
 Thermostat control
 Disk drive control
 Aircraft altitude control
Difficulty due to
 Disturbance: wind, road, tire, brake; opening/closing door…
 Human interface: feel good, feel right…

- 55 -
Tracking

- 56 -
 Open-Loop Control Systems

Plant
 Physical system to be controlled
• Car, plane, disk, heater,…
Actuator
 Device to control the plant
• Throttle, wing flap, disk motor,…
Controller
 Designed product to control the plant

- 57 -
 Open-Loop Control Systems

Output
 The aspect of the physical system we are interested in
• Speed, disk location, temperature
Reference
 The value we want to see at output
• Desired speed, desired location, desired temperature
Disturbance
 Uncontrollable input to the plant imposed by environment
• Wind, bumping the disk drive, door opening

- 58 -
 Other Characteristics of open loop

Feed-forward control
Delay in actual change of the output
Controller doesn’t know how well thing goes
Simple
Best use for predictable systems

- 59 -
 Close Loop Control Systems

Sensor
 Measure the plant output
Error detector
 Detect Error
Feedback control systems
Minimize tracking error

- 60 -
 Designing Open Loop Control System

Develop a model of the plant

Develop a controller
Analyze the controller
Consider Disturbance
Determine Performance
Example: Open Loop Cruise Control System

- 61 -
 Model of the Plant

May not be necessary

 Can be done through experimenting and tuning
But,
 Can make it easier to design
 May be useful for deriving the controller
Example: throttle that goes from 0 to 45 degree
 On flat surface at 50 mph, open the throttle to 40 degree
 Wait 1 “time unit”
 Measure the speed, let’s say 55 mph
 Then the following equation satisfy the above scenario
• vt+1=0.7*vt+0.5*ut
• 55 = 0.7*50+0.5*40
 IF the equation holds for all other scenario
• Then we have a model of the plant

- 62 -
 Designing the Controller

Assuming we want to use a simple linear function

 ut=F(rt)= P * rt
 rt is the desired speed
Linear proportional controller
vt+1=0.7*vt+0.5*ut = 0.7*vt+0.5P*rt
Let vt+1=vt at steady state = vss
vss=0.7*vss+0.5P*rt
At steady state, we want vss=rt
P=0.6
 I.e. ut=0.6*rt

- 63 -
 Analyzing the Controller

Let v0=20mph, r0=50mph

vt+1=0.7*vt+0.5(0.6)*rt =0.7*vt+0.3*50=
0.7*vt+15
Throttle position is 0.6*50=30 degree

- 64 -
 Considering the Disturbance

Assume road grade can

affect the speed
 From –5mph to +5 mph
 vt+1=0.7*vt+10
 vt+1=0.7*vt+20

- 65 -
 Determining Performance

Vt+1=0.7*vt+0.5P*r0-w0
v1=0.7*v0+0.5P*r0-w0
v2=0.7*(0.7*v0+0.5P*r0-w0) +0.5P*r0-w0 =0.7*0.7*v0+(0.7+1.0)*0.5P*r0-
(0.7+1.0)w0
vt=0.7t*v0+(0.7t-1+0.7t-2+…+0.7+1.0)(0.5P*r0-w0)
Coefficient of vt determines rate of decay of v0
 >1 or <-1, vt will grow without bound
 <0, vt will oscillate

- 66 -
Designing Close Loop Control System

- 67 -
 Stability

ut = P * (rt-vt)
vt+1 = 0.7vt+0.5ut-wt = 0.7vt+0.5P*(rt-vt)-w
=(0.7-0.5P)*vt+0.5P*rt-wt
vt=(0.7-0.5P)t*v0+((0.7-0.5P)t-1+(0.7-0.5P)t-2+…+0.7-0.5P+1.0)(0.5P*r0-
w 0)

Stability constraint (I.e. convergence) requires

|0.7-0.5P|<1
-1<0.7-0.5P<1
-0.6<P<3.4

- 68 -
 Reducing effect of v0

ut = P * (rt-vt)
vt+1 = 0.7vt+0.5ut-wt = 0.7vt+0.5P*(rt-vt)-w
=(0.7-0.5P)*vt+0.5P*rt-wt
vt=(0.7-0.5P)t*v0+((0.7-0.5P)t-1+(0.7-0.5P)t-2+…+0.7-0.5P+1.0)(0.5P*r0-
w 0)

To reduce the effect of initial condition

 0.7-0.5P as small as possible
 P=1.4

- 69 -
 Avoid Oscillation

ut = P * (rt-vt)
vt+1 = 0.7vt+0.5ut-wt = 0.7vt+0.5P*(rt-vt)-w
=(0.7-0.5P)*vt+0.5P*rt-wt
vt=(0.7-0.5P)t*v0+((0.7-0.5P)t-1+(0.7-0.5P)t-2+…+0.7-0.5P+1.0)(0.5P*r0-
w 0)
To avoid oscillation
 0.7-0.5P >=0
 P<=1.4

- 70 -
 Perfect Tracking

ut = P * (rt-vt)
vt+1 = 0.7vt+0.5ut-wt = 0.7vt+0.5P*(rt-vt)-w
=(0.7-0.5P)*vt+0.5P*rt-wt
vss=(0.7-0.5P)*vss+0.5P*r0-w0
(1-0.7+0.5P)vss=0.5P*r0-w0
vss=(0.5P/(0.3+0.5P)) * r0 - (1.0/(0.3+0.5P)) * wo
To make vss as close to r0 as possible
 P should be as large as possible

- 71 -
 Close-Loop Design

ut = P * (rt-vt)
Finally, setting P=3.3
 Stable, track well, some oscillation
 ut = 3.3 * (rt-vt)

- 72 -
 Analyze the controller

v0=20 mph, r0=50 mph, w=0

vt+1 = 0.7vt+0.5P*(rt-vt)-w
= 0.7vt+0.5*3.3*(50-vt)
ut = P * (rt-vt)
= 3.3 * (50-vt)

But ut range from 0-45

Controller saturates

- 73 -
 Analyze the controller

v0=20 mph, r0=50 mph, w=0

vt+1 = 0.7vt+0.5*ut
ut = 3.3 * (50-vt)
 Saturate at 0, 45
Oscillation!
 “feel bad”

- 74 -
 Analyze the controller

Set P=1.0 to void

oscillation
 Terrible SS
performance

- 75 -
Analyzing the Controller

- 76 -
 Minimize the effect of disturbance

vt+1 = 0.7vt+0.5*3.3*(rt-
vt)-w
 w=-5 or +5

39.74
 Close to 42.31
 Better than
• 33
• 66
Cost
 SS error
 oscillation

- 77 -
 General Control System

Objective
 Causing output to track a reference even in the presence of
• Measurement noise
• Model error
• Disturbances
Metrics
 Stability
• Output remains bounded
 Performance
• How well an output tracks the reference
 Disturbance rejection
 Robustness
• Ability to tolerate modeling error of the plant

- 78 -
 Performance (generally speaking)

Rise time
 Time it takes form
10% to 90%
Peak time
Overshoot
 Percentage by which
Peak exceed final
value
Settling time
 Time it takes to reach
1% of final value

- 79 -
 Plant modeling is difficult

May need to be done first

Plant is usually on continuous time
 Not discrete time
• E.g. car speed continuously react to throttle position, not at discrete
interval
 Sampling period must be chosen carefully
• To make sure “nothing interesting” happen in between
• I.e. small enough
Plant is usually non-linear
 E.g. shock absorber response may need to be 8th order differential

Iterative development of the plant model and controller

 Have a plant model that is “good enough”

- 80 -
 Controller Design: P

Proportional controller
 A controller that multiplies the tracking error by a constant
• ut = P * (rt-vt)
 Close loop model with a linear plant
• E.g. vt+1 = (0.7-0.5P)*vt+0.5P*rt-wt
P affects
 Transient response
• Stability, oscillation
 Steady state tacking
• As large as possible
 Disturbance rejection
• As large as possible

- 81 -
 Controller Design: PD

Proportional and Derivative control

• ut = P * (rt-vt) + D * ((rt-vt)-(rt-1-vt-1)) = P * et+ D * (et-et-1)
Consider the size of error over time
Intuitively
 Want to “push” more if the error is not reducing fast enough
 Want to “push” less if the error is reducing really fast

- 82 -
 PD Controller

Need to keep track of error derivative

E.g. Cruise controller example
 vt+1 = 0.7vt+0.5ut-wt
 Let ut = P * et + D * (et-et-1), et=rt-vt
 vt+1=0.7vt+0.5*(P*(rt-vt)+D*((rt-vt)-(rt-1-vt-1)))-wt
 vt+1=(0.7-0.5*(P+D))*vt+0.5D*vt-1+0.5*(P+D)*rt-0.5D*rt-1-wt
 Assume reference input and distribance are constant, the steady-
state speed is
• Vss=(0.5P/(1-0.7+0.5P)) * r
• Does not depend on D!!!
P can be set for best tracking and disturbance control
Then D set to control oscillation/overshoot/rate of
convergence

- 83 -
PD Control Example

- 84 -
 PI Control

Proportional plus integral control

 ut=P*et+I*(e0+e1+…+et)
Sum up error over time
 Ensure reaching desired output, eventually
 vss will not be reached until ess=0
Use P to control disturbance
Use I to ensure steady state convergence and convergence rate

- 85 -
 PID Controller

Combine Proportional, integral, and derivative control

 ut=P*et+I*(e0+e1+…+et)+D*(et-et-1)
Available off-the shelf

- 86 -
 Software Coding

Main function loops forever, during each iteration

 Read plant output sensor
• May require A2D
 Read current desired reference input
 Call PidUpdate, to determine actuator value
 Set actuator value
• May require D2A

- 87 -
 Software Coding (continue)

Pgain, Dgain, Igain are constants

sensor_value_previous
 For D control
error_sum
 For I control

- 88 -
 Computation

ut=P*et+I*(e0+e1+…+et)+D*(et-et-1)

- 89 -
 PID tuning

Analytically deriving P, I, D may not be possible

 E.g. plant not is not available, or to costly to obtain
Ad hoc method for getting “reasonable” P, I, D
 Start with a small P, I=D=0
 Increase D, until seeing oscillation
• Reduce D a bit
 Increase P, until seeing oscillation
• Reduce D a bit
 Increase I, until seeing oscillation
Iterate until can change anything without excessive
oscillation

- 90 -
Practical Issues with Computer-Based Control

Quantization
Overflow
Aliasing
Computation Delay

- 91 -
 Quantization & Overflow

Quantization
 Can’t store 0.36 as 4-bit fractional number
 Can only store 0.75, 0.59, 0.25, 0.00, -0.25, -050,-0.75, -1.00
 Choose 0.25
• Result in quantization error of 0.11
Sources of quantization error
 Operations, e.g. 0.50*0.25=0.125
• Can use more bits until input/output to the environment/memory
 A2D converters

Overflow
 Can’t store 0.75+0.50 = 1.25 as 4-bit fractional number

Solutions:
 Use fix-point representation/operations carefully
• Time-consuming
 Use floating-point co-processor
• Costly

- 92 -
 Aliasing

Quantization/overflow
 Due to discrete nature of computer data
Aliasing
 Due to discrete nature of sampling

- 93 -
 Aliasing Example

Sampling at 2.5 Hz, period of 0.4, the following are indistinguishable

 y(t)=1.0*sin(6πt), frequency 3 Hz
 y(t)=1.0*sin(πt), frequency of 0.5 Hz
In fact, with sampling frequency of 2.5 Hz
 Can only correctly sample signal below Nyquist frequency 2.5/2 = 1.25 Hz

- 94 -
 Computation Delay

Inherent delay in processing

 Actuation occurs later than expected
Need to characterize implementation delay to make sure it is
negligible
Hardware delay is usually easy to characterize
 Synchronous design
Software delay is harder to predict
 Should organize code carefully so delay is predictable and
minimized
 Write software with predictable timing behavior (be like
hardware)
• Time Trigger Architecture
• Synchronous Software Language

- 95 -
 Benefit of Computer Control

Cost!!!
 Expensive to make analog control immune to
• Age, temperature, manufacturing error
 Computer control replace complex analog hardware with complex
code
Programmability!!!
 Computer Control can be “upgraded”
• Change in control mode, gain, are easy to do
 Computer Control can be adaptive to change in plant
• Due to age, temperature, …etc
 “future-proof”
• Easily adapt to change in standards,..etc

- 96 -