SUPERVISORY CONTROL AND DATA

ACQUISITION (SCADA) SYSTEMS

• SCADA system is the first step towards automation.

• The basic functions carried out by a SCADA system are:

➢ Channel scanning

➢ Conversion into engineering units

➢ Data processing
• Channel scanning
There are many ways in which microprocessor can address the various channels
and read the data.
➢Polling
• The microprocessor scans the channels to read the data, and this process is
called polling.
• In polling, the action of selecting a channel and addressing it, is the
responsibility of processor.
• The channel selection may be sequential or in any particular order decided by
the designer.
• It is also possible to assign priority to some channels over others, i.e. some
channels can be scanned more frequently than others.
• It is also possible to offer this facility of selecting the order of channel
addressing and channel priorities to the operator level,
• i.e. make these facilities as dynamic.
• The channel scanning and reading of data requires, the following actions to be
taken:
➢Sending channel address to multiplexer
➢Sending start convert pulse to ADC
➢Reading the digital data
• For reading the digital data at ADC output, the end of conversion signal of ADC
chip can be read by processor and
• when it is ‘ON’, the digital data can be read.
• Alternatively, the microprocessor can execute a group of instructions (which do
not require this data) for the time which is equal to or greater than conversion
time of ADC and then read ADC output.
• Another modification of this approach involves connecting the end of conversion
line to one of the interrupt request pins of the processor.
• In this case the interrupt service routine reads the ADC output and stores at
predefined memory location.
• The channels can be polled sequentially, in which case the channel address in first
step above increases by one every time
• or they may be scanned in some other order. In the later case, a channel Scan
Array can be maintained in memory (Fig 2).

ASCN

• Fig.2.. Channel scan array

• The Scan Array contains the addresses of the channels in the order in which they
should be addressed.
• The ASCN array in Fig.2 has 9, 10, 1, 2 … as entries in sequence.
• Thus, first channel to be scanned will be channel 9, followed by 10, 1, 2… as the
pointer reaches the last entry in the array, the first entry is again taken up (i.e.
channel 9 is scanned).
• If a channel number is repeated in the array, then the particular channel will be
scanned repeatedly.
• Thus it is possible to scan some channels more frequently than others. This gives
them higher priority over others.
• In Fig. 2 the channel 9 is scanned 3 times, channel 2 is scanned 2 times, while
other channels are scanned once during the cycle.
• Fig. 3: Scan cycle flow chart
• Fig. 3 shows the flow chart for one scan cycle.
• The processor may scan the channels continuously in the particular order as
illustrated by the flow chart or the channels may be scanned after every fixed
time period.
• The second approach requires a timer/counter circuit whose output is connected
to interrupt request input.
• The scan routine for one channel is incorporated in ‘Interrupt service routine’.
• It is also possible to make the time gap between to channels as variable.
• This would require a n x 2 dimension scan array as shown in Fig. 4.
• The interrupt service routine fetches the time gap value for next channel, loads
the timer/counter with the value and .
• initiate the timer/counter before returning to main program.
• Fig. 4. Scan array with time
• The scan array may be decided at the design stage of SCADA and fused
permanently in Read Only Memory (ROM). Thus the channels are always
scanned in that particular order.
• However, it may be desirable to offer the facility of changing the sequence at
the operator level.
• The operator may like to take this action depending on the condition of the
plant being monitored.
• As an example, if at any instant, operator finds out that the transducer
connected to channel may has generated some fault, then he might take
decision to bypass the channel 9, as otherwise its data will be taken into analysis
to produce incorrect result.
• In another situation, it may become necessary to scan some channel more
frequently for some time to observe its response to some modifications
incorporated in the system.
• The operator should thus be able to insert new scan array at any time. This
facility may be provided through a key switch which may be connected to
interrupt request input of processor.
• The interrupt servicing routine will accept new scan array and store in place of
the old one.
• Interrupt scanning
• Another way of scanning the channels may be to provide some primitive facility
after transducer to check for violation of limits.
• It sends interrupt request signal to processor when the analog signal from
transducer is not within High and Low limits boundary set by Analog High and
Analog Low signals.
• This is also called Scanning by Exception.
• When any parameter exceeds the limits then the limit checking circuit would
send interrupt request to microprocessor
• which in turn would monitor all parameters till the parameter values come back
within pre-specified limits.
• This allows a detailed analysis of the system and the problems by the SCADA
system.
• Fig. 5. Interrupt request generation on limit violation
• The limit checking circuit for one channel is shown in Fig. 5. Two analog
comparators check whether the input signal is within high and low limits.
• The output is ORed and the final output is used as interrupt request to
microprocessor.
• This limit checking should not be construed as alarm condition,
• but condition for start of any abnormality which may generate alarm condition
or can be controlled by the system before any alarm condition is reached.
• Therefore, the system should be watched closely during this time.
Conversion to Engineering Units
• The data read from the output of ADC should be converted to the equivalent
engineering units before any analysis is done or the data is sent for display or
printing.
• For an 8-bit ADC working in unipolar mode the output ranges between 0 and
255.
• An ADC output value will corresponds to a particular engineering value
based on the following parameters:
1. Calibration of transmitters
2. ADC mode and digital output lines.
• The transmitter output should be in the range of 0-5 V or 4-20 mA range.
• Depending on the input range of measured value for transmitter, a
calibration factor is determined.
• If a transducer is capable of measuring parameter within the input range
X1 to X2 and provides 0-5 V signal at output.

• then calibration factor is

units
• If we are converting this signal to digital through an 8-bit ADC (Input range 0-5 V)
in unipolar mode then:
5 V = 255 and 0 V= 0.
i.e.
• Thus conversion factor is:
engineering units

engineering units
If the ADC output is Y
then the corresponding value in engineering units will be :

Conversion factor is therefore equal to

• The conversion of ADC output to engineering units, therefore, involves
multiplication by conversion factor.

• The conversion factor is based on the ADC type, mode and the transducer
range.

• This multiplication can be achieved by shift and add method in case of 8-

bit microprocessor.
DATA PROCESSING

• The data read from the ADC output for various channels is processed by the
microprocessor to carry out limit checking and performance analysis.

• For limit checking the Highest and Lowest Limits for each channel are stored in
an array (Fig.6).

• When any of the two limits is violated for any channel, appropriate action like
alarm generation, printing, etc. is initiated.

• The limit array shown in Fig. 6, simplifies the limit checking routine.
• Through this, the facility to dynamically change limits for any channel may also be
provided, on the lines similar to scan array.
• In addition to limit checking, the system performance may also be analyzed and report
could be generated for the manager level.
• This report will enable the managers
(a) to visualize the problems in the system
(b) to take decisions regarding system modification
(c) or alternate operational strategy to increase the system performance.
Higher Limit Lower Limit
10 02
20 09

30 07 
 
 
 
 
 
  


• Fig.6 Limit array

• The analysis may include histogram generation, standard deviation calculation,
plotting one parameter with respect to another and so on.

• Software can be written depending on the type of analysis required.

• facilities like scanning, limit checking, etc. could be incorporated in a simple way
using arrays in software.

• If we examine channel scanning, using scan array in memory which contains the
channel numbers in one particular order of scan.

• For two applications using the same hardware, only the scan array will have to
be changed for the scanning.

• The same argument is valid for limit checking.

• Conversion to engineering units can also be achieved by storing the
conversion factors for different channels in any array.

• Conversion factors stored in the array will change with change in transducers
i.e. it will be different for different applications.

• Simple print programme which takes data in particular format from memory

• and sends for printing may also be same for different applications.

• However, designer will have to write specialized routine for arranging the
data in the memory in any particular format required.
• The analysis and report generation programs will be application dependent and
will have to be written separately for different applications.
Distributed SCADA system
• In any application, if the number of channels are quite large then in order to
interface these to processor, one has to use multiplexers at different levels.
• Fig. below shows the interfacing of 256 channels, using 17 multiplexers of 16
channels each.
• The 8 address lines are used to address 256 channels.
• Out of these 8-address lines, upper four are used to select a particular
multiplexer and lower four lines are used to select a particular channel in the
multiplexer.
• The 8-bit channel address thus directly maps into channel number and can be
manipulated in any way. The other parts are same as described earlier.
• Fig. 7 : 256 channel SCADA with single microprocessor
• This approach will be suitable for the process which are basically slow.

• Even if a channel is scanned only once in every scan, it only after 255 channels
have been scanned , limit checking and analysis have been performed , a
particular channel will be addressed again .

• This is not acceptable in many process.

• For the plants where the structure of Fig. 7 does not suit, only alternative is to
use more than one SCADA system and distribute the channels among them.
• But for performance analysis on the process plant , it is mandatory that data
from various channels should reached a central location where it can be
consolidated and analyzed to generate the report on plant performance.
• Figure 8 (a) and (b) show the interfacing of number of SCADA system with
central computer in Star configuration and Daisy chain configuration
respectively.
• Fig. 8 : (a) Distributed SCADA system structure (Star configuration) and (b) Distributed
SCADA system structure (Daisy Chain configuration)
• SCADA system directly connected to transducer are called nodes and are same
as the system described earlier.
• They scan the channel using one of the techniques discussed earlier; convert
the data into engineering units , perform the limit checking , generate alarm if
the data item crosses the limit and generate print out.
• In additional to these function, the data regarding the channel in the node are
transferred to central computer which analysis the system performance and
generated print.
• The print out are generated by exception, i.e. , unnecessary data is not printed
at any point.
• At the node level performance, the print is required for the operator to run
the system .
• Depending on the node performance , operator may decide to monitor any
channel more frequently , change the limits.
• The print out at the central node is required at mangerial level to take a long
term decisions to optimize the performance.
• The details on the channel performance, limit violations are not required at
this level .
• On other hand, the histogram on the input and output material flow and the
fuel consumption etc. may more helpful.

• The concept of local area network or microprocessor interconnection can be

used in case of distributed SCADA system very effectively.
• The distributed SCADA system can be ultimate good solution for complex
process plant monitoring.
REMOTE TERMINAL UNIT (RTU)
• RTU are basically distributed SCADA based system used in remote
locations in application like oil pipelining , irrigation canals, oil drilling
platforms etc.
• They are rugged and should be able to work unattended for a long
duration.
• There are two modes in which RTU works:
1. Under command from central command.
2. Stand alone mode.
• Since these RTU ‘s have to operate for a long duration unattended ,
basic requirement would be that they consume minimum power and
have considerable self –diagnostic facility.
• Following are main parts of a RTU:
(a) Input/ output Modules
• It consist of analog input modules, analog output modules,
digital input modules and digital output modules.
(b) Communication modules:
• The communication module is important part of a RTU and had
the interface available with 2 wire /4 wire communication line.
• Some of the RTU may also have built in transceiver and
modems.
• Following are basic communication strategies that a RTU uses
depending on the application need
Wireline Communications
• The wireline communication may have number of options.
• these options can be selected depending upon the distance
between central computer and RTU or between two RTUs.
• These options are enlisted here:

Option 1- RS-232C/442.
• RTU can support communication via standard RS-232C/442.
The I/O ports can select the average levels as well as the
baud rates.
Option 2- switch line modem.
• When the user wants to use the existing telephone lines
for communication, the switch line modem can be
effective.
• Such RTUs contain the facilities like auto answer, auto
dial and auto select baud rates.
• The modem is ideal for data networks configured in time
or event reporting RTUs and for master station polling
networks.
Option 3- 2-wire or 4-wire communication.
• The modem residents in the RTU can be configured to 2 or 4-wire
communication on dedicated lines.
• The same communication protocol is used for all devices making the actual
network configuration transparent to the user.
Terrestrial UHF/VHF radio with store and forward capability
• The RTU may support a complete line of UHF/VHF terrestrial radios.
• The communication protocol in these RTUs is transparent to the user and
supports CRC intelligence, error checking, packet protocol for error free data
transmission.
• The store and forward capability of the RTU minimizes the required input in
large numbers.
Satellite communications
• In the applications where wireline and terrestrial radio communications are
impossible or cost prohibitive, the satellite communications may be desirable.
• Some of the latest RTUs provide the facility to be interfaced to one-way or two-
way satellite communication using very small aperture terminals (VSATs).
• These terminals use one meter antennas and have data rates from 50 to 60
KBPS (kilo bits per second).
Fibre-optic communications
• For applications where electro-magnetic interferences or hazardous electrical
potentials exists, the RTU can be networked using fiber optic cables.
• The same communication protocols and networking concepts available for
wireline and radio are used for fiber optic communication.
Special software facilities
• The special software facilities which are required in RTUs and are not available
SCADA units mentioned above are given here.
(i) Quiescent mode operation.
• Since the transmitter consumes maximum power in RTU in the communication
especially in terrestrial and satellite communications, it is switched on only when
the RTU has some information packets ready for sending.
• Thus the RTU receives all the information from central computer.
• It may be a polling message or a request to perform certain control functions.
• Since the receiver is kept on all the time, these information are received and
proper action is initiated.
• Only when the RTU has to send some information to central computer, which
may be an urgent message or an acknowledgement of an action taken or
acknowledgement of message received, the transmitter is switched on.
• The quiescent mode saves considerable amount of power for RTUs.
• (ii) Down Loading of limits from central computer.
• Generally the RTUs behave much like standalone SCADA or direct digital control
systems.
• Thus they collect the data from various sensors, perform signal conditioning,
filtering, conversion to engineering units and store them in the memory.
• They also perform the limit checking on these values and inform central
computer on violation of limits, if any, immediately.
• Since these RTUs are at remote locations, it should be possible to change these
limits remotely from central computer.
• This is called down loading of limits.
• The central computer in such cases makes a special request to RTU to change
the limits.
• The RTUs will then enter a special mode for the change of basic parameters and
perform the functions in an interactive way.
• (iii) Exceptional Reporting.
• The microprocessor based RTUs are intelligent enough to perform number of
function independently and may need to conserve power in these remote
locations is paramount.
• This means that the RTUs must communicate to central computer mostly in
receive mode and only exceptionally in transmit mode.
• The RTUs normally have intelligence to perform all the functions including limit
checking and only when the limits are violated, the central computer is
informed.
• The other message that goes regularly is regarding, “all well” condition of RTUs.
• Thus RTUs perform self-diagnosis which must be done by the resident
microprocessors by executing different diagnostic software.
• The block diagram of RTU is shown in Next Slide. The software environment
includes real-time operating systems and real-time language to facilitate the
system development.
• Fig.1 Remote terminal unit (Block diagram)
 REAL-TIME PROGRAMMING
• The most important aspect of real-time programming system is the management of
information flow.
• Fig. in Next Slide shows the various basic modules of real-time system along with
information flow between them.
Input sub-system
• Input sub-systems are used to measure different parameters like temperature, flow,
pressure etc. of status of limit switches, ON/OFF switches, and other binary status
information.
Analog sensor
• Also called transducers or transmitters.
• They present at their output an electrical signal whose value is proportional to the
value of parameter being measured.
Digital sensor
• These sensors have ADC embedded in the same package in addition to analog sensor.
• At their output they present a digital value proportional to the parameter value.
Information Flow in Real Time System
• Binary switches
• They present one bit value corresponding to ON/OFF status, limit switches at various
parts of process.
• Processing sub-system
• The computer and associated modules connected to computer through bus constitute
the processing sub-system.
• Associated modules include analog multiplexer, digital multiplexer, ADC, memory, DAC,
de multiplexer and I/O modules like console, mimic panel etc.
• The computer receives in byte/word from analog sensor to ADC or direct from digital
sensor.
• The binary switches sent information in bit form, which is stored in the computer
memory.
• Depending on the parameter value, set point, control loop configuration and control
algorithm, the correction value is determined and is send to output value through DAC.
• The stepper motor and digital actuators accept control correction value in digital form.
• The alarm annunciators have separate modules for individual alarms. Thus each
requires only one bit information to activate.
 Output sub-system
• The control valve and actuator take analog signal which may come from
computer through DEMUX and DAC.
• The stepper motor needs digital information for each step movement. Similarly
digital actuator takes byte/word for control correction.
• The alarm annunciator may be connected directly and requires only activation
signal which may come in bit form.
Information Processing
• The computer executes the control algorithm on the information received from
analog and digital sensors.
• Thus the processing performed is
INPUT (VALUE)
ERROR=(SET POINT - VALUE)
RUN CONTROL LOOP 1 (ERROR, CORRECTION)
OUTPUT(CORRECTION) TO VALVE (N)
• Thus the information is received, stored, manipulated and the output is given in
byte/word form.
• On the other hand, the status information is in bit form. The type of processing,
required is
If
(SW1 is ‘ON’ AND(SW2 is ‘OFF’ OR SW5 is ‘ON’))
then SEND ALARM 1
else
If (SW1 is ‘ON’ AND SW2 is ‘ON’)
Then RUN CONTROL LOOP-5 (ERROR, CORRECTION)
else Repeat
• Thus computer must be able to read the status of bits directly (bit addressing),
check their status and manipulate (bit manipulation) and take decisions.
 INTERRUPTS
• Interrupt processing is the most important feature of real-time systems which
distinguishes these from on-line systems.
• Interrupt processing is directly related to ‘response time’ of the real-time
systems.
• Too many interrupts and slow processing will ultimately affect the main job result
in sluggish performance of the system.
• At the same time efficient interrupt processing , together with well-defined
priority structure will lead to better performance.
• The priority structure defines the following features:
(i) In case of two or more interrupt requests at the same instant, which one will
have priority and will be processed.
(ii) Whether a higher priority interrupt request can interrupt a lower priority
interrupt?
• The mechanism by which different interrupts can be disabled temporarily or
masked.
• Interrupts which cannot be masked.
• The factors which mainly affect the interrupt processing (Fig. shown in next
slide) are context switching and interrupt latency.
• Context switching is defined as time and overheads to switch between two
tasks or routines when an interrupt has been accepted for processing.
• Fig. 3 Interrupt processing steps
• This includes not only the time to load program counter with new address but
also time to save the status variables.
• This depends on the computer architecture as well as interrupt management
structure.
• Interrupt latency is time lag between the acknowledgement of interrupts in real-
time systems, its careful treatment forms an important and integral part of real-
time systems.
Real-time programming
• A real-time system can be broken into a number of independent sub-systems
called processes.
• Fig. in Next Slide shows 5 independent processes which act independently but
share resources to monitor and control the plant parameters.
• Fig 4. Process and tasks.
• A process may therefore be defined as a hardware or software or
combined sub-system designed to perform defined tasks.
• A process is therefore having local processing capability or local
intelligence.
• The limit checking process performs limit checking and engineering unit
conversion functions and transfers the date to Alarm Generation Process
(C) and Control Algorithm Execution Process (D).
• Alarm generation has been conceived as a separate hardware to which
Limit Checking Process transfers the data on data path.
• Finally control algorithm execution process transfers the data on correction
value to output signal generation process (E) which converts these into
analog, conditions them and then sends to the control valves in the plant.
BASIC REAL-TIME CONCEPTS
• Real-time systems:
(a) are those in which time lines is as important as the correctness of the outputs
(b) do not have to be “fast systems”
(c) its design and analysis is a complex holistic engineering science.
(d) its performance estimation and reduction are crucial.
• Systems in which data need to be processed at a regular and timely rate
• For example (1) : An air craft uses a sequence of accelerometer pulses to determine its
current position.
• Other systems require a rapid response to events that are occurring at non-regular
rates.
• Example(2) : an over-temperature failure in a nuclear plant.
• These events require a real-time processing.
• Example (3): Now consider a situation in which a person approach an airline
reservation counter and request for a Flight from point A to B , leaving in 30 minutes.
• Person at counter enter the request in a computer and a few seconds later produces
boarding pass.
• Is this a real-time system ?
• All three example are real-time systems.
• As they must process information within a specified interval or risk system
failure.
• These example provide an intuitive definition of a real time system.
• There is a need to define a system is real-time and when it is not.
Systems Concepts
• System programs consist of software that interfaces with the underlying
computer hardware, such as schedulers, device drivers, dispatchers, and
programs that act as tools for the development of application programs.
• These tools include compilers, which translate high-order language
programs into assembly code; assemblers,
• which translate the assembly language into a special binary format called
object or machine code; and linkers, which prepare the object code for
execution.
• An operating system is a specialized collection of system programs that
manage the physical resources of the computer.
• As such, a real-time operating system is a systems program.
• Application programs are programs written to solve specific problems, such
as payroll preparation, inventory, navigation etc.
• Certain design considerations play a role in the design of certain systems
programs and application software intended to run in real-time
environments.
• The notion of a “system” is central to software engineering, and indeed to all
engineering and warrants formalization.
• Definition: A system is a mapping of a set of inputs into a set of outputs.
• When the internal details of the system are not of interest, the mapping function
can be considered as a black box with one or more inputs entering and one or
more outputs exiting the system.
• Every real-world entity, whether synthetic or occurring naturally, can be
modeled as a system.
• In computing systems, the inputs represent digital data from hardware devices
and other software systems.
• The inputs are often associated with sensors, cameras, and other devices that
provide analog inputs, which are converted to digital data, or provide direct
digital input.
• The digital output of the computer system can be converted to analog outputs to
control external hardware devices such as actuators and displays (Figure 1).
• Modeling a real-time system, as in Figure 1, is somewhat different from the
more traditional model of the real-time system as a sequence of jobs to be
scheduled and performance to be predicted, which is very similar to that
shown in Figure 2.

• The latter view is simplistic in that it ignores the fact that the input sources and
hardware under control are complex.
• Moreover, there are other, sweeping software engineering considerations that
are hidden by the model shown in Figure 2.
• Note that in its realization of model of a real-time system shown in Figure 1,
there is some delay between presentation of the inputs (stimulus) and
appearance of the outputs (response).
• This fact can be formalized as follows:
• Definition: The time between the presentation of a set of inputs to a system
(stimulus) and the realization of the required behavior (response), including
the availability of all associated outputs, is called the response time of the
system.
Real-Time System Definitions
• The previous definitions set the stage for a formal definition of a real-time
system
• Definition: A real-time system is a system that must satisfy explicit (bounded)
response-time constraints or risk severe consequences, including failure.
What is a “failed” system?
• In the case of the space shuttle or a nuclear plant, it is painfully obvious when a
failure has occurred.
• For other systems, such as an automatic bank teller machine, the notion of failure
is less clear.
• For now, failure will be defined as the “inability of the system to perform according
to system specification,” or, more formally:
• Definition: A failed system is a system that cannot satisfy one or more of the
requirements stipulated in the formal system specification.
• Because of this definition of failure, precise specification of the system operating
criteria, including timing constraints, is important.
• Various other definitions exist for real-time, depending on which source is
consulted.
• Nonetheless, the common theme among all definitions is that the system must
satisfy deadline constraints in order to be correct.
• For example, an alternative definition might be:
• Definition: A real-time system is one whose logical correctness is based on both the
correctness of the outputs and their timeliness.
• by making unnecessary the notion of timeliness, every system becomes a real-time
system.
• Real-time systems are often reactive or embedded systems.
• Reactive systems are those in which scheduling is driven by ongoing interaction with
their environment;
• for example, a fire-control system reacts to buttons pressed by a pilot. Embedded
systems are those that are found in a system that is not itself a computer.
• For example, a modern automobile contains many embedded computers that
control fuel injection, airbag deployment, braking etc.
• Today, many household items such as televisions, stereos, washing machines, even
toys contain embedded computers.
• It is clear that sophisticated systems such as aircraft, spacecraft, and industrial
machines must contain many embedded, reactive computer systems.
• The three systems mentioned earlier satisfy the criteria for a real-time system
precisely.
• An aircraft must process accelerometer data within a certain period that
depends on the specifications of the aircraft; for example, every 10
milliseconds.
• Failure to do so could result in a false position or velocity indication and cause
the aircraft to go off-course at best or crash at worst.
• For a nuclear reactor thermal problem, failure to respond swiftly could result in
a meltdown.
• Finally, an airline reservation system must be able to handle a surge of
passenger requests within the passenger’s perception of a reasonable time (or
before the flights leave the gate).
• In short, a system does not have to process data in microseconds to be
considered real-time; it must simply have response times that are constrained.
When Is a System Real-Time?
• It can be argued that all practical systems are real-time systems.
• Even a batch-oriented system – for example, grade processing at the end of a
semester or a bimonthly payroll run – is real-time.
• Although the system may have response times of days or weeks (e.g., the
time that elapses between submitting the grade or payroll information and
issuance of the report card or check),
• it must respond within a certain time or there could be an academic or
financial disaster.
• Even a word-processing program should respond to commands within a
reasonable amount of time (e.g., 1 second), or it will become torturous to
use.
• Most of the literature refers to such systems as soft real-time systems.
• Definition: A soft real-time system is one in which performance is degraded
but not destroyed by failure to meet response-time constraints.
• Conversely, systems where failure to meet response-time constraints leads
to complete and catastrophic system failure are called hard real-time
systems.
• Definition: A hard real-time system is one in which failure to meet a single
deadline may lead to complete and catastrophic system failure.
• Firm real-time systems are those systems with hard deadlines where some
arbitrarily small number of missed deadlines can be tolerated.
• Definition: A firm real-time system is one in which a few missed deadlines will not
lead to total failure, but missing more than a few may lead to complete and
catastrophic system failure.
• As noted, all practical systems minimally represent soft real-time systems.
• Table 1 gives a sampling of hard, firm, and soft real-time systems.
• Note that there is a great deal of latitude for interpretation of hard, firm, and soft
real-time systems.
• For example, in the automated teller machine, missing too many deadlines will
lead to significant customer dissatisfaction and potentially even enough loss of
business to threaten the existence of the bank.
• This extreme scenario represents the fact that every system can probably be
characterized any way – soft, firm, or hard – real-time by the construction of a
supporting scenario.
• The careful construction of systems requirements (and, hence, expectations) is the
key to setting and meeting realistic deadline expectations.
• In any case, it is a principal goal of real-time systems engineering to find ways to transform
hard deadlines into firm ones, and firm ones into soft ones.
• Since this text is mostly concerned with hard real-time systems, it will use the term real-
time system to mean embedded, hard real-time system, unless otherwise noted.
The Nature of Time
• It is typical, in studying real-time systems, to consider the nature of time, because deadlines
are instants in time.
• But the question arises, “Where do the deadlines come from?”
• deadlines are based on the underlying physical phenomena of the system under control.
• For example, in animated displays, images must be updated at approximately 30 frames
per second to provide continuous motion, because the human eye can resolve updating at
a slower rate.
• In navigation systems, accelerations must be read at a rate that is based on the maximum
velocity of the vehicle.
• In some cases, systems have deadlines that are imposed on them that are based on nothing
less than guessing or on some forgotten and since eliminated requirement.
• The problem in these cases is that the undue constraints may be placed on the systems.
• This is a primary maxim of real-time systems design – to understand the basis and nature of
the timing constraints, so that they can be relaxed if necessary.
• Many real-time systems utilize time-stamping and global clocks
for synchronization, task initiation, and data marking.
• It must be noted, however, that clocks keep inaccurate time.
• Moreover, there is an associated digitization error with clocks,
which may need to be considered when using them for data
time-stamping.
Events and Determinism
• In software systems, a change in state results in a change in the
flow-of-control of the computer program.
• Consider the flowchart in Figure 3.
• The decision block represented by the diamond suggests that
the stream of program instructions, can take one of two paths,
• depending on the response in question. if-then, goto, and case
statements in any language represent a possible change in flow-
of-control.
• Invocation of procedures in C and Ada represent changes in
flow-of-control.
• In object-oriented languages, instantiation of an object or the invocation of a
method causes the change in sequential flow-of-control.
• In general, consider the following definition.
• Definition: Any occurrence that causes the program counter to change non
sequentially is considered a change of flow-of-control, and thus an event.
• In scheduling theory, the “release” time of a “job” is similar to an event.
• Definition: The release time is the time at which an instance of a scheduled
task is ready to run, and is generally associated with an interrupt.
• Events are slightly different from jobs in that events can be caused by
interrupts as well as conditional and unconditional branches.
Synchronous and Asynchronous Events
• An event can be either synchronous or asynchronous.
• Synchronous events are those that occur at predictable times in the flow-of-
control, such as that represented by the decision box in the flowchart of Figure
3.
• The change in flow-of-control, represented by a conditional branch
instruction, or by the occurrence of an internal trap interrupt, can be
anticipated (although it may not always occur).
• Asynchronous events occur at unpredictable points in the flow-of-control and
are usually caused by external sources.
• A clock that pulses “regularly” at 5 milliseconds is not a synchronous event.
• While it represents a periodic event, even if the clock were able to tick at a
perfect 5 milliseconds without drift (which it cannot for physical reasons), the
point where the tick occurs with the flow of-control is subject to many factors.
• These factors include the time at which the clock starts relative to the
program and propagation delays in the computer system itself.
• An engineer can never count on a clock ticking exactly at the rate specified,
and so a clock-driven event must be treated as asynchronous.
• Events that do not occur at regular intervals (or periods) are called aperiodic.
• Aperiodic events that tend to occur very infrequently are called sporadic.
• Table 2 characterizes a sampling of events.

• For example, an interrupt generated by a periodic external clock represents a

periodic but asynchronous event.
• A periodic but synchronous event is one represented by a sequence of invocation
of tasks in a repeated, circular fashion, otherwise known as cyclic code.
• A typical conditional or unconditional branching instruction that is not part of
a code block and that runs repeatedly at a regular rate represents a
synchronous but aperiodic event.
• A branch instruction that happens infrequently, say, on the detection of some
exceptional condition, is both sporadic and synchronous.
• Finally, interrupts that are generated irregularly (randomly) by an external
device are classified as either asynchronous aperiodic or sporadic,
• depending on whether the interrupt is generated frequently or not with
respect to the system clock.