Real-Time Systems
Real-time systems (RTS) are systems, intended for the interaction (in the first
turn, for control) with real physical objects and this interaction must run at a real physical
time, in those temporary scales, in which live these objects. If we speak about control of
fast running processes (for instance, when controlling flying apparatus having speed of
the order 600 km/hour and altitude of 50 m then temporary scales for making and
fulfilling decisions must have order of 0.01 sec). Thus, RTS are usual computing systems
(CS), but intended for functioning in terms of hard temporary restrictions and which must
have developed facilities of the interactions with the external world for the reception of
information on objects of control and for the transferring them worked out control
influences (Fig.1). Such systems must possess increased reliability. There are
distinguished soft RTS (violation of timing restrictions in some range does not lead to the
system failure), hard RTS (violation of timing restrictions leads to the system failure) and
firm RTS (violation of timing restrictions in some range does not lead to the system
failure with certain probability).
Real-time system
RTS
Control stimuli
information
external
stimuli
CO
Controlled object
Fig.1
As an example (Liu J.W.S., Real-Time Systems, p. 2), let’s consider an analog
single-input/single-output PID (Proportional, Integral and Derivative) controller (Fig.2).
The analog sensor reading y(t) gives the measured state of the plant at time t. Let
e(t)=r(t)-y(t) denote the difference between the desired state r(t) and the measured state
y(t) at time t.
Reference input
r(t)
uk
rk
Control-law
computation
A/D
D/A
yk
A/D
u(t)
y(t)
Plant
Sensor
Actuator
Fig.2
The output u(t) of the controller consists of three terms: a term that is proportional
to e(t), to the integral of e(t) and to the derivative of e(t).
In the sampled data version, the inputs to the control-law computation are the
sampled values yk and rk, k=0,1,2,.., which analog-to-digital converters produce by
sampling and digitizing y(t) and r(t) periodically every T units of time. ek=rk-yk is the k-th
sample value of e(t). There are many ways to discretize the derivative and integral of e(t).
For example, we can approximate derivative of e(t) for (k-1)T<=t<=kT by (ek-ek-1)/T and
b
use the right rectangular rule of numerical integration (  f ( x)dx  f (b)(b  a) )to
a
transform a continuous integral into a discrete form. The result is the
kT
k
0
i 1
u k  ek   (ek  ek 1 ) / T    e(t )dt  ek   (ek  ek 1 ) / T    ei
Considering uk-1, we get
k 1
u k 1  ek 1   (ek 1  ek  2 ) / T    ei
i 1
From two last equations, we get
u k  u k 1  aek 2  bek 1  cek
(1)
where a,b,c are some constants; they are chosen at the design time. During the kth sampling period, the RTS computes the output of the controller according to this
expression. Different discretization methods may lead to different expressions for uk, but
they all are simple to compute (10-20 machine instructions).
From (1), we can see that during any sampling period (say k-th), the control
output uk depends on the current and past values yi, i<=k. The future measured values yi
for i>k in turn depend on uk. Such a system is called a (feedback) control loop or simply
a loop. We can implement it as an infinite timed loop:
Set timer to interrupt periodically with period T;
At each timer interrupt, do
Do analog-to-digital conversion to get y
Compute control output u
Make digital-to-analog conversion and output u
End do
The length T of time between any two consecutive instants at which y(t) and r(t)
are sampled is called the sampling period. T is a key design choice. The behavior of the
resultant digital controller critically depends on this parameter. Ideally, we want the
sampled data version behave like the analog version. This can be done by making T
small. However, this will lead to more frequent control-law computation and higher
processor-time demand. We want a sampling period T that achieves a good compromise.
In making this selection we are to consider two factors. The first is the perceived
responsiveness of the overall system (i.e., the plant and the controller). Oftentimes, the
system is operated by a person (driver, pilot). The operator may issue a command at any
time, say at t. The consequent change in the reference input is read and reacted to by the
digital controller at the next sampling instant. This instant can be as late as t+T. Thus,
sampling introduces a delay in a system response. The operator will feel the system
sluggish when the delay exceeds a tenth of a second. Therefore, the sampling period
should be under this limit.
The second factor is the dynamic behavior of the plant (considered earlier).
It is recommended to use sampling frequency twice as highest possible frequency
occurring in the system to be able to reproduce such signals (Nyquist-Kotelnikov
theorem).
Let’s consider software control structure of the flight velocities controller:
Do the following in the 1/180 –second cycle:
Validate sensor data and select data source; in the presence of failures,
reconfigure the system
Do the following 30-Hz avionics tasks, each once every six cycles:
keyboard input and mode selection
data normalization and coordinate transformation
tracking reference update
Do the following 30-Hz computations, each once every six cycles:
control laws of the outer pitch-control loop
control laws of the outer roll-control loop
control laws of the outer yaw- and collective control loop
Do each of the following 90-Hz computations once every two cycles, using
outputs produced by 30-Hz computations and avionics tasks as input:
control laws of the inner pitch-control loop
control laws of the inner roll- and collective-control loop
Compute the control laws of the inner yaw-control loop, using outputs produced
by 90-Hz control-law computations as input
Output commands
Carry out built-in test
Wait until the beginning of the next cycle
Three velocities along axes were called in algorithm collective velocities,
rotational velocities around axes are illustrated below:
Fig. 3
This multirate controller controls only flight dynamics. The control system on
board an aircraft contains many other equally critical subsystems (air inlet, fuel,
hydraulic, brakes, anti-ice controllers, etc.).
In many cases, sensor gives not the value of the state variable, but some
observable attributes of the plant, and state variables should be computed on their basis.
In such more complicated cases controllers may be represented by the following schema
Set timer to interrupt periodically with period T;
At each clock interrupt, do
Sample and digitize sensor readings to get measured values
Compute control output from measured and state-variable values
Convert control output to analog form
Compute and update plant parameters and state variables
End do
Usually, control is made in many levels, hierarchically.
Fig. 4.
Fig. 4 shows example of hierarchy of flight control, flight management and air
traffic control systems. The Air Traffic Control (ATC) system is at the highest level. It
regulates the flow of flights to each destination airport. It does so by assigning to each
aircraft an arrival time at each metering fix (known geographical point, adjacent points
are 40-60 miles apart) in the route to destination. The aircraft is supposed to arrive at the
metering fix at the assigned time. At any time while in flight, the assigned arrival time to
the next metering fix is a reference input to the on-board flight management system. The
flight management system chooses a time-referenced flight path that brings the aircraft to
the next metering fix at the assigned arrival time. The cruise speed, turn radius,
descend/ascend rates and so for required to the chosen time-referenced flight path are the
reference inputs to the flight controller at the lowest level of hierarchy.
Computations made by controllers of low levels may be simple and deterministic
while high-level controller interacting with operator is more complex and variable (for
example, expert system). Period of low-level controller ranges from milliseconds to
seconds, the periods of high-level controllers may be minutes and even hours.
Fig. 5 illustrates architecture of ATC system. The ATC system monitors the
aircraft in its coverage area and generates and presents information needed by the
operators. Outputs from the ATC system include the assigned arrival times to metering
fixes for individual aircraft. These outputs are reference inputs to on-board flight
management systems. Thus, the ATC system indirectly controls the embedded
components in low levels of hierarchy. In addition, the ATC system provides voice and
telemetry links to on-board avionics. The ATC system gathers information on the state of
each aircraft via one or more active radars. Such radar interrogates each aircraft
periodically. When interrogated, an aircraft responds by sending the ATC system its state
variables: identifier, position, altitude, heading and so on (these variables in the figure are
referred to collectively as a track record, and the current trajectory of the aircraft is a
track). The ATC system processes messages from aircraft and stores state information in
the database. This information is picked up and processed by display processors. At the
same time, the surveillance system continuously analyses the scenario and alerts the
operators whenever it detects any potential hazard (e.g., a possible collision). Again, the
rates at which human interfaces operate (keyboards and displays) must be at least 10 Hz.
Fig. 5.
From this example, we can see that a command and control system bears little
resemblance to low-level controllers. In contrast to low-level controller whose workload
is either purely or mostly periodic, a command and control system computes and
communicates in response to sporadic events and operator’s commands. It may process
images and speech, query and update databases, simulate various scenarios, and the like.
The resource and processing times demands can be large and varied.
When designing RTS, as well as for the comparison of existing systems are used
different criteria of their quality, the most important of them are the following:
Performance - an amount of executed operations in the unit of the time. If, for
r
instance, there must be solved batch of tasks z i i1 with computational complexities
(total amount of operations) Qi then performance may be calculated as
r
Р=
Q
i 1
i
,
T
where Т is the time of execution of all the batch tasks. To evaluate current
performance at the time moment t there may be used
Q (t , t   )
P(t)= lim
,
 0

where Q(t1,t2) is complexity of tasks executed by system in the time interval [t1,t2).
System cost С, which must include not only cost of its creation or purchase price
but also cost of maintaining it in the working state
Cost of performance unit (1 operation/sec), calculated as С/Р, or inverse value
Р/С, characterizing performance obtained per dollar of expenditure.
System volume, system mass, energy consumption, intensiveness of system
radiation, working temperature, stability to external affects (radiation, vibration, acid
environment etc.)
RTS are intended to solve definite sets of tasks, for example, simulate moving of
flying apparatus, finding out optimal trajectory of flying, making and transfer of control
stimuli to corresponding mechanical devices. These tasks are to be solved in minimal
possible time or in the time not greater than predefined. In connection with that there may
be considered the following criteria:
Minimization of the total execution time То of the batch having L tasks. If fi is a
moment of the time of termination of i-th task, then total execution time То= max f i , and
i 1, L
it is necessary to find min max f i . This criterion corresponds to maximization of
i 1, L
performance of the system when solving given batch of tasks, because computational
complexity is constant, and denominator is minimized in the expression for performance.
Each task of the batch may have its deadline di – time moment before which it
L
must be solved. There may be used the following criteria:
min
( f
i 1
L
min
 | f i  d i | , min
i 1
L
 max( 0, f
i 1
i
i
 di ) ,
 di )
min max  f i  d i  , min max | f i  d i | , min max | 0, f i  d i | .
i 1, L
i 1, L
i 1, L
The first 3 criterions use mean deviations from deadline terms, and last 3 use
maximal deviations. In the first criterion an excess of deadline term for one task can be
compensated by earlier solution of other tasks, in the second variant are fined both an
excess of deadline term, and early solution, in the third variant is fined only excess of
deadline term. For last three criterions important is maximum deviation. Besides, there
can be introduced weights, characterizing importance of tasks and, accordingly,
violations of deadline terms for the given task.
For server type systems, for instance, phone stations, communication nodes,
headquarters may be important criterion defining mean number of tasks (users) served in
the time unit, i.e. throughput of the system. Here is important not computational
complexity of executed tasks but number of served users standing beyond these tasks,
number of made decisions. Throughput is maximized when mean time of staying tasks in
the system is minimized. Let number of tasks be – L, time moment of i-th task arriving to
the system is si, time moment of i-th task execution finishing is fi, i=1,..,L. Then mean
time of staying tasks in the system is Тс =
L
( f
i 1
i
 si ) / L . If time staying in the system
of i-th task is f i  si , i  1, L , then we may say that for i-th task each unit of time
1 /( f i  si ), i  1, L , part of task leaves the system and in whole the following number of
L
tasks L /  ( f i  s i ) leave system per time unit, i.e. throughput is value inverse to mean
i 1
time of staying tasks in the system. Thus, to maximize throughput it is necessary to
minimize mean time of staying tasks in the system, and for maximization of performance
we need in minimization of maximal time of staying tasks in the system.
Let’s note that minimization of То is NP-hard task /Garey, Johnson, 1982/,
requiring exponentially growing depending on number processors and allocated tasks
number of operations. For solution of such tasks usually are applied polynomial-hard
heuristic algorithms giving not optimal but rather good solutions. So, to optimize То
there may be used algorithm LPT (Largest Processing Time task – first) with time
complexity О(LlogL+Ln), where L is the tasks number, logarithm is binary, n is the
number of identical processors of CS. Essence of that algorithm is to sort tasks in the
descending order of execution times and assigning them in such order to freeing
processors. Main contributor in time complexity of this algorithm is sorting. In /Graham,
1969/ it was proved that when allocating any batch П of independent tasks (order of
assigning may be arbitrary, there is no precedence relation on the tasks set)
То(П,LPT)/То(П,ОPТ)<(4/3-1/(3n)), where То(П, ОPТ) – is optimal execution time of
batch П, i.e. error of produced by algorithm LPT schedule is not more than 33% in worst
case. Practically the same looking task of optimization of Тс is optimally solved by
algorithm SPT (Shortest Processing Time task – first) of the same time complexity as
LPT. In SPT algorithm tasks with less execution time are pushed forward. Let tasks of
the batch П have the following execution times: (3,3,2,2,2). Then in the case of 2processor system (n=2) То(П, ОPТ)=6 (Fig.6,а), То(П, LPT), produced by algorithm
LPT, is equal to 7, Тс(П,LPT)=4.6 (Fig. 6,b), То(П, SPT)=7, Tc(П, SPT)=4 (Fig. 6,c).
P1
P2
1
3
Tо(ОPТ)
=6
2
3
3
a)
P1
3
P2
3
2
3
1
To(SPT)
=7
Tc(SPT)=
4
c)
P1
1
3
P2
2
3
3
To(LPT)
=7
Tc(LPT)
=4.6
Tasks are represented by
their numbers
b)
Fig. 6.
When designing RTS we are to take into account many different criteria, often contradicting
each other (performance – cost, performance – size, etc.). It’s obvious that optimal
solution of this task is extremely hard, because it is necessary to solve make multiple
criteria optimization. Here, as a rule, two simplifying approaches are used:
- usage of one general criterion which is obtained by forming one expression
involving all necessary criteria (usually sum, or weighted sum with weights taken from
(0,1), showing importance of corresponding criterion, sum of weights equal to 1);
- optimization on one criterion using other as restrictions.
So, design of RTS is a complex multiple criteria task in the result of solving
which there must be obtained CS having desired for control of respective objects features.
For achieving such a goal it is necessary to use existing resources in optimal way. As it is
obvious from Fig..6 modification of only order of tasks serving, without modification of
hardware, cost, mass and so on, we can significantly influence on system characteristics
(in our sample it is of order of 10%, but there may be given more strong examples). Main
resources of the system are processors, processor time, RAM, external memory. These
resources are used by processes running program codes. So, we shall consider problems
of control of processes and system resources.
Usually RTS is to control multiple objects simultaneously; therefore even in the
case of uniprocessor systems they are to support multitasking, because it is impossible to
say at first we shall finish to control first object and then start to control second due to
infinite time of existence of controlled objects in many cases (metallurgical stoves are
used during dozens of years). Therefore for RTS it is very important to manage in
optimal way parallel processes responsible for corresponding controlled objects. For the
sake of more rapid response (control outputs) it is widely used parallelizing of
computations between several processors, so we shall consider issues of parallelizing and
related problems.
RTS are dedicated for controlling of real objects and cost of their failure may be
extremely high (for instance, error in controlling of nuclear reactor on Chernobyl nuclear
power station). Therefore there must be used methods for increasing reliability of
software and hardware incorporated in RTS. We shall consider approaches to this issue
starting from design.
RTS are complicated software-hardware products, in which there must be present
model of controlled object, facilities for interaction with external world with the help of
input-output devices. There must be provided known for human operator control
environment (control panel of power station, aircraft, vehicle, etc.), support of parallel
processes, network support, safety facilities, etc. To simplify development of such
systems there were elaborated SCADA systems (Supervisor Control And Data
Acquisition), which we shall briefly consider in our course.
Very important for RTS are issues of communication with external devices, which
is usually organized with the help of drivers. We shall also briefly touch this topic.