 | This articleneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Real-time computing" – news ·newspapers ·books ·scholar ·JSTOR(April 2014) (Learn how and when to remove this message) |
Real-time computing (RTC) is thecomputer science term forhardware andsoftware systems subject to a "real-time constraint", for example fromevent tosystem response.[1] Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".[2]
The term "real-time" is also used insimulation to mean that the simulation's clock runs at the same speed as a real clock.
Real-time responses are often understood to be in the order of milliseconds, and sometimes microseconds. A system not specified as operating in real time cannot usuallyguarantee a response within any timeframe, althoughtypical orexpected response times may be given. Real-time processingfails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless ofsystem load.
A real-time system has been described as one which "controls an environment by receiving data, processing them, and returning the results sufficiently quickly to affect the environment at that time".[3] The term "real-time" is used inprocess control andenterprise systems to mean "without significant delay".
Real-time software may use one or more of the following:synchronous programming languages,real-time operating systems (RTOSes), and real-time networks. Each of these provide essential frameworks on which to build a real-time software application.
Systems used for manysafety-critical applications must be real-time, such as for control offly-by-wire aircraft, oranti-lock brakes, both of which demand immediate and accurate mechanical response.[4]
The termreal-time derives from its use in earlysimulation, where a real-world process is simulated at a rate which matched that of the real process (now calledreal-time simulation to avoid ambiguity).Analog computers, most often, were capable of simulating at a much faster pace than real-time, a situation that could be just as dangerous as a slow simulation if it were not also recognized and accounted for.
Minicomputers, particularly in the 1970s onwards, when built into dedicatedembedded systems such as DOG (Digital on-screen graphic) scanners, increased the need for low-latency priority-driven responses to important interactions with incoming data. Operating systems such asData General'sRDOS (Real-Time Disk Operating System) and RTOS withbackground and foreground scheduling as well asDigital Equipment Corporation'sRT-11 date from this era. Background-foreground scheduling allowed low priority tasks CPU time when no foreground task needed to execute, and gave absolute priority within the foreground to threads/tasks with the highest priority. Real-time operating systems would also be used fortime-sharing multiuser duties. For example,Data General Business Basic could run in the foreground or background of RDOS and would introduce additional elements to the scheduling algorithm to make it more appropriate for people interacting viadumb terminals.
Early personal computers were sometimes used for real-time computing. The possibility of deactivating other interrupts allowed for hard-coded loops with defined timing, and the lowinterrupt latency allowed the implementation of a real-time operating system, giving the user interface and the disk drives lower priority than the real-time thread. Compared to these theprogrammable interrupt controller of the Intel CPUs (8086..80586) generates a very large latency and the Windows operating system is neither a real-time operating system nor does it allow a program to take over the CPU completely and use its ownscheduler, without using native machine language and thus bypassing all interrupting Windows code. However, several coding libraries exist which offer real time capabilities in a high level language on a variety of operating systems, for exampleJava Real Time. Later microprocessors such as theMotorola 68000 and subsequent family members (68010, 68020,ColdFire etc.) also became popular with manufacturers of industrial control systems. This application area is one where real-time control offers genuine advantages in terms of process performance and safety.[citation needed]
A system is said to bereal-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed.[5] Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:[6]
Thus, the goal of ahard real-time system is to ensure that all deadlines are met, but forsoft real-time systems the goal becomes meeting a certain subset of deadlines in order to optimize some application-specific criteria. The particular criteria optimized depend on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high priority tasks meeting their deadlines.
Hard real-time systems are used when it is imperative that an event be reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). Some examples of hard real-time systems:
In the context ofmultitasking systems thescheduling policy is normally priority driven (pre-emptive schedulers). In some situations, these can guarantee hard real-time performance (for instance if the set of tasks and their priorities is known in advance). There are other hard real-time schedulers such asrate-monotonic which is not common in general-purpose systems, as it requires additional information in order to schedule a task: namely a bound or worst-case estimate for how long the task must execute. Specific algorithms for scheduling such hard real-time tasks exist, likeearliest deadline first, which, ignoring the overhead ofcontext switching, is sufficient for system loads of less than 100%.[7] New overlay scheduling systems, such as anadaptive partition scheduler assist in managing large systems with a mixture of hard real-time and non real-time applications.
Firm real-time systems are more nebulously defined, and some classifications do not include them, distinguishing only hard and soft real-time systems. Some examples of firm real-time systems:
Soft real-time systems are typically used to solve issues of concurrent access and the need to keep a number of connected systems up-to-date through changing situations. Some examples of soft real-time systems:
In a real-timedigital signal processing (DSP) process, the analyzed (input) and generated (output) samples can be processed (or generated) continuously in the time it takes to input and output the same set of samplesindependent of the processing delay.[9] It means that the processing delay must be bounded even if the processing continues for an unlimited time. Themean processing time per sample, includingoverhead, is no greater than the sampling period, which is the reciprocal of thesampling rate. This is the criterion whether the samples are grouped together in large segments and processed as blocks or are processed individually and whether there are long, short, or non-existentinput and output buffers.
Consider anaudio DSP example; if a process requires 2.01 seconds toanalyze,synthesize, or process 2.00 seconds of sound, it is not real-time. However, if it takes 1.99 seconds, it is or can be made into a real-time DSP process.
A common life analogy is standing in a line orqueue waiting for the checkout in a grocery store. If the line asymptotically grows longer and longer without bound, the checkout process is not real-time. If the length of the line is bounded, customers are being "processed" and output as rapidly, on average, as they are being inputted then that processis real-time. The grocer might go out of business or must at least lose business if they cannot make their checkout process real-time; thus, it is fundamentally important that this process is real-time.
A signal processing algorithm that cannot keep up with the flow of input data with output falling further and further behind the input, is not real-time. If the delay of the output (relative to the input) is bounded regarding a process which operates over an unlimited time, then that signal processing algorithm is real-time, even if the throughput delay may be very long.
Real-time signal processing is necessary, but not sufficient in and of itself, for live signal processing such as what is required inlive event support. Live audio digital signal processing requires both real-time operation and a sufficient limit to throughput delay so as to be tolerable to performers usingstage monitors orin-ear monitors and not noticeable aslip sync error by the audience also directly watching the performers. Tolerable limits to latency for live, real-time processing is a subject of investigation and debate, but is estimated to be between 6 and 20 milliseconds.[10]
Real-time bidirectionaltelecommunications delays of less than 300 ms ("round trip" or twice the unidirectional delay) are considered "acceptable" to avoid undesired "talk-over" in conversation.
Real-time computing is sometimes misunderstood to behigh-performance computing, but this is not an accurate classification.[11] For example, a massivesupercomputer executing a scientific simulation may offer impressive performance, yet it is not executing a real-time computation. Conversely, once the hardware and software for an anti-lock braking system have been designed to meet its required deadlines, no further performance gains are obligatory or even useful. Furthermore, if a network server is highly loaded with network traffic, its response time may be slower, but will (in most cases) still succeed before it times out (hits its deadline). Hence, such a network server would not be considered a real-time system: temporal failures (delays, time-outs, etc.) are typically small and compartmentalized (limited in effect), but are notcatastrophic failures. In a real-time system, such as theFTSE 100 Index, a slow-down beyond limits would often be considered catastrophic in its application context. The most important requirement of a real-time system is consistent output, not high throughput.
Some kinds of software, such as manychess-playing programs, can fall into either category. For instance, a chess program designed to play in a tournament with a clock will need to decide on a move before a certain deadline or lose the game, and is therefore a real-time computation, but a chess program that is allowed to run indefinitely before moving is not. In both of these cases, however, high performance is desirable: the more work a tournament chess program can do in the allotted time, the better its moves will be, and the faster an unconstrained chess program runs, the sooner it will be able to move. This example also illustrates the essential difference between real-time computations and other computations: if the tournament chess program does not make a decision about its next move in its allotted time it loses the game—i.e., it fails as a real-time computation—while in the other scenario, meeting the deadline is assumed not to be necessary. High-performance is indicative of the amount of processing that is performed in a given amount of time, whereas real-time is the ability to get done with the processing to yield a useful output in the available time.
The term "near real-time" or "nearly real-time" (NRT), intelecommunications andcomputing, refers to the timedelay introduced, by automateddata processing ornetwork transmission, between the occurrence of an event and the use of the processed data, such as for display orfeedback and control purposes. For example, a near-real-time display depicts an event or situation as it existed at the current time minus the processing time, as nearly the time of the live event.[12]
The distinction between the terms "near real time" and "real time" is somewhat nebulous and must be defined for the situation at hand. The term implies that there are no significant delays.[12] In many cases, processing described as "real-time" would be more accurately described as "near real-time".
Near real-time also refers to delayed real-time transmission of voice and video. It allows playing video images, in approximately real-time, without having to wait for an entire large video file to download. Incompatible databases can export/import to common flat files that the other database can import/export on a scheduled basis so they can sync/share common data in "near real-time" with each other.
Several methods exist to aid the design of real-time systems, an example of which isMASCOT, an old but very successful method that represents theconcurrent structure of the system. Other examples areHOOD, Real-Time UML,AADL, theRavenscar profile, andReal-Time Java.
Appropriate A/V sync limits have been established and the range that is considered acceptable for film is +/- 22 ms. The range for video, according to the ATSC, is up to 15 ms lead time and about 45 ms lag time
[...] set of notes which will hopefully point up problem areas which should be considered in real time design.
