Real-time systems are found in many everyday applications,
from appliances, to automotive systems and even toys.
What all of these real-time systems have in common?
Any system, whether biological, electrical, mechanical, software or some combination of these, can be modeled as mapping of a set of inputs into a set of outputs. Typical real-time systems have inputs from sensors and imaging devices, from other systems, or from devices controlled by human operators. These inputs are processed so that the system can produce appropriate control signals to various actuators, motors and displays.
There are several important concepts related to real-time
systems.
·
Response time
The notion of the time needed by a system to respond to some
input. That is, the time between the presentation of a set of inputs to a
system and the realization of the required behavior, including the availability
of all associated outputs is called the response time of the system. The set of
inputs are often called the “stimulus” and the outputs are called the
“response”.
·
Real-time system
A real-time system is a system that must satisfy explicit
(and bounded) response time constraints or risk severe consequences. A
real-time system is one whose logical correctness is based on both the correctness
of the outputs and their timeliness. Therefore, any definition of a real-time
system must incorporate some notion of temporal constraint satisfaction. A
real-time systems fails if it cannot satisfy one or more of the requirements
stipulated in the system requirements specification.
With these concepts in mind, we can finally define a
real-time system as one in which logical correctness is based on both the
correctness of the outputs and their timeliness. But this definition of
“real-time”, while theoretically sound, is too broad to be useful most of the
time. Practically speaking, every system has to produce its results within some
reasonable deadline, whether that deadline is in microseconds, milliseconds,
seconds, minutes, days or months. Therefore we need to specialize the
definition of a real-time system.
·
Failed system
·
Soft real-time system
For example, we define a soft real-time system as one in
which performance is degraded but not destroyed by failure to meet
response-time constraints. Many systems fit this definition from airline
reservation systems to banking systems to even many computer games. In fact,
every practical system is at least, a soft real-time system.
·
Firm real-time system
A firm real-time system is one in which a few missed deadlines
can be tolerated, but missing more than “a few” may lead to complete and
catastrophic system failure. Many process control and telecommunications
systems fall in this category.
·
Hard real-time system
Finally, we define a hard real-time system as one in which
failure to meet a single deadline may lead to complete and catastrophic system
failure. For example, you can imagine the consequences of failing to meet a
critical deadline in the control of a nuclear plant or vehicular control
system.
------------------------------------------------------------------------------------------------------------
Challenge to Real
Time Systems Engineer?
One of the challenges
for the real-time systems engineer is to find ways to transform hard real-time
systems into firm or even soft real-time systems. That is, we want to find ways
that allow critical systems to occasionally miss an important deadline, but not
fail.
------------------------------------------------------------------------------------------------------------
Consider the software applications shown in the table. The
weapons delivery capability, say firing an offensive missile, for some fighter
aircraft, would require a hard real-time system because missing the deadline
between pressing the fire missile button and actually launching the missile
could cause the target to be missed. On the other hand, the navigation control
system for some robotic weed killer might be considered to be firm. Here
missing an occasional deadline might lead to a few weeds being missed, or a
cash crop being accidentally killed. But if the number of these misfires is
small enough, these might be acceptable. Finally, in many applications, say, a
simulated hockey game for amusement, missing more than a few deadlines might
lead to user frustration, but not serious adverse consequences.
------------------------------------------------------------------------------------------------------------
One important
question to consider is, if real-time systems correctness is defined through
meeting deadlines, where do deadlines come from?
They come from a
variety of sources including: The physical laws underlying the dynamics of the
system, Standards, Regulations, statues, and laws and Customer requirements. Sometimes
the deadlines are arbitrary. Whatever the case the source of deadlines should
be documented to help with tradeoff engineering and constraint relaxation
during the systems engineering process and, later , in maintenance engineering.
------------------------------------------------------------------------------------------------------------
In almost every complex software or software intensive
system, however, bounding performance means giving a confidence interval for
some behavior. For example, you might say that upon receiving signal A, the
system will respond with output B within 400 milliseconds, 99% of the
time.
And by relaxing some aspect off the behavior, the confidence
interval could be refined. For example, in the system just mentioned, it might
be possible to respond within 500 milliseconds 99.99% of the time.
These kinds of guarantees can be acceptable, even in the most
critical systems.
Thanks for sharing this post with us.Wikivela
ReplyDelete