What is Real Time Application (RTAs)?
Real-Time Applications
Truths and myths related to Real-Time Computing are as follows:
1. Myth: Real-Time Computing is equivalent to fast computing.
Truth: Real-Time Computing is equivalent to predictable computing.
2.Myth: Real-Time Computing means higher performance.
Truth: In Real-Time Computing, timeliness is more important than performance.
What exactly mean by the word real-time, which is often used in the context of Real-Time Application (RTA) or Real-Time Operating System (RTOS).
The word real-time signifies that the application or the operating system deals with guarantees, not with raw speed. Whenever you say something is real-time, then timeliness is more important. That is, it promises to meet its deadline for a given timeline instead of just talking about raw speed.
Application developers who think they need a real-time system for better performance of their application can actually get the performance they require by simply upgrading their hardware with faster processors, RAM, high-speed buses, etc. But that doesn’t make a system real-time.
A Real-Time System deals with guarantees, not with promises. If an application with limited hardware, and if it is able to meet a timeliness execution, then that system or application can be called real-time.
A Real-Time System is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints are not met, system failure is said to have occurred.
For example, take a look at the graph shown in Figure 1.
There the red line indicates that it is a Non-Real-Time Application, and the purple line indicates a real-time application. We have just plotted a graph of execution iterations vs. response time.
Here you can see during multiple iterations, the execution time or the response time of a Real-Time Application is almost constant. It is roughly taking around, say, 2.5 seconds for every duration. So, its response time is fairly constant between multiple execution iterations.
But take a look into the Non-Real-Time Application. Its response time is varying. For the first iteration, it took around 4 seconds, then for the next iteration, its response time was around 1.5 seconds, and for the next iteration, it took something around 2.5. The Non-Real-Time Application doesn’t meet the timeliness behavior. So, you can’t trust this application, isn’t it? Because its response time is keeps on varying between multiple iterations.
A Non-Real-Time Application will show this kind of behavior that its response time will always vary as time passes. But a Real-Time Application promises a fairly constant response time no matter in which constraints you execute that application.
For example, one way of looking at this is that for a Non-Real-Time Application, you can speculate that the system load was high for the first iteration, so it took more time.
For the next iteration, you can speculate that the system load may be less, that’s why the Non-Real-Time Application got executed in less time, and for the last iteration, you can predict that the system load was again high. That’s why this application took more time. But a Real-Time Application, no matter what the system load is, it will always take the same response time between multiple execution iterations. This is the meaning of real-time, which is used in the context of Real-Time Application or Real-Time Operating System.
What are Real Time Applications (RTAs)?
- RTAs are not fast executing applications. They need not be fast, but they have to meet the strict given response time deadline.
- RTAs are time deterministic applications. That means their response time to events is almost constant.
- There could be a small deviation in RTAs response time in terms of milliseconds or seconds, which will fall into the category of soft real-time applications.
- Hard real-time functions must complete within a given time limit. Failure to do so will result in absolute failure of the whole system. For example, the airbag triggering mechanism in a car is an example of a hard real-time function. The airbag must be deployed within a given time limit of an impact (Figure 2). A response falling outside of this time limit can result in the driver sustaining injuries that could otherwise have been avoided.
Soft real-time requirements (Figure 3) are those that state a time deadline but reaching the deadline would not render the system useless. There could be a small deviation in terms of milliseconds or seconds in terms of the response time of soft real requirements. They are not as strict as Hard Real-Time Systems.
Some more examples of Real Time applications:
1. Missile guidance and control system:
This is indeed a Hard Real-Time System because timeliness and response time is always strict, and the deviation in the response time can cause chaos. So, all the control system requirements are usually Hard Real-Time Systems.
2. Anti-Lock Braking System in a car:
It is truly a hard real-time scenario, and airbag deployment in a four-wheeler can also be considered a Hard Real-Time Application. Because of the timeliness, the response time from detecting a crash to the deployment of an airbag is very, very important. So, airbag deployment can be considered as a Hard Real-Time Application.
3. VOIP:
That is, Voice Over Internet, can be considered as a soft real-time. During communication, there could always be a delay while transmitting packets because there a hard real-time scenario cannot be maintained, and there could be a dropping of a couple of packets. All these missing deadlines and dropping of packets cannot be perceived by the user. Sometimes the user will not be able to notice it. So, the VOIP can be considered as a Soft Real-Time system.
4. Other than this, aircraft control, ATMs, robotics, MRI, and there are hundreds of thousands of other applications (Figure 7) where Real-Time Applications play an important role.
FastBit Embedded Brain Academy Courses
click here: https://fastbitlab.com/course1
