Page 19 - DCAP608_REAL TIME SYSTEMS

Real Time Systems

Notes Thus, the control system now contains not only wired components but also algorithms, which
must be programmed, i.e. software is now included in the control loop. This leads to new aspects
to take into account by designing control systems:
1. Errors due to A/D and D/A conversion as well as due to limited length word calculations.
This subject is well-treated in the literature. It is not meaningful to talk about guarantying
real-time performance. It is true that occasionally time constraints can be relaxed without
introducing additional problems in the control loop. This particularly applies to nice
designed laboratory experiments. However, this actually depends on the application, and
the time criticality should be proved for each individual case. On the other hand, real-time
performance cannot be 100% guaranteed while hardware and software failures cannot be
avoided at all.

2. Software developing is prone to errors. Thus, a new concept has to be introduced to
consider this aspect, the verification, i.e. a mechanism to test if the software is doing
exactly what it is expected. Here it is necessary to remark that in general a high per cent of
errors in digital control systems are caused by programming mistakes. Hence, digital
control projects need not only control engineers but also engineers with skills in software
engineering and computer programming. We do not care about real-time in our digital
control system and even though it works. This statement is similar to the previous one.
The problem here is that you are not able to know when your system can fail.
3. Standard textbooks on digital control systems normally assume that sampling is uniform,
periodic and synchronous. This leads to a case of “zero-time-execution” for the control
law. However, that is not realistic since the control algorithm also consumes some time
producing a control or feedback delay (control or feedback latency), i.e. a delay between
a sampling instant and the instant at which a control-signal value is applied to the actuator.

Did u know? Real-time programming is assembly coding, priority interrupt programming
and device driver writing.
It is true that some code is still writing in assembler. However, high programming
languages like C, Ada 95, Modula 2 and Real-time Java are normally used to develop real-
time software. Device driver programming is necessary for real-time as well as non-real-
time systems but they should be provided by the operating system or by the device
manufacturer. Interrupt programming should be in principle avoided as much as possible.
If the controller design is based on a model and the delay is constant and known, it could
be helpful to use a tool for the description of the inter-sample behaviour (e.g. modified
z-transform) in order to obtain a discrete time model more approximated to the real case.
4. The computational time of control algorithms can change from one sampling instant to
other (e.g. hybrid controller with controller switching mechanism, event based controllers,
adaptive controllers with on-line parameter update, etc.). This variation in the delay is
called control jitter (according to the IEEE, jitter is “the time-related abrupt, spurious
variation in the duration of any specified related interval”). Moreover, value calculation
for the control signal is usually carried out using multitasking defining a set of control
tasks with respective priorities. Thus, a task can be pre-empted by higher priority tasks. In
general, it can be said that the control system is also affected by several kind of jitter
depending on context: sampling jitter, control latency jitter, input jitter, output jitter, etc.

Finally, real-time issues are often ignored in the implementation of digital control systems.
This is in part a consequence of erroneous definitions and false interpretations. Popular
misconceptions from the control engineering community about real-time systems are for
example:

14 LOVELY PROFESSIONAL UNIVERSITY