Jump to content

Real-time computing: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
No edit summary
No edit summary
 
(319 intermediate revisions by more than 100 users not shown)
Line 1: Line 1:
{{short description|Study of hardware and software systems that have a "real-time constraint"}}
{{Refimprove|date=May 2008}}
{{distinguish|text=[[Real-time communication]] or [[Real-time clock]], closely related technologies that are also often abbreviated to RTC}}
{{Refimprove|date=April 2014}}


In [[computer science]], '''real-time computing''' ('''RTC'''), or '''reactive computing''', is the study of [[Computer hardware|hardware]] and [[computer software|software]] systems that are subject to a "real-time constraint"— e.g. operational deadlines from event to system response. Real-time programs must guarantee response within strict time constraints.<ref name="Ben-Ari-pg164">Ben-Ari, M., "Principles of Concurrent and Distributed Programming", Prentice Hall, 1990. ISBN 0-13-711821-X. Ch16, Page 164.</ref> Often real-time response times are understood to be in the order of milliseconds and sometimes microseconds. In contrast, a ''non-real-time system'' is one that cannot guarantee a response time in any situation, even if a fast response is the usual result.
'''Real-time computing''' ('''RTC''') is the [[computer science]] term for [[Computer hardware|hardware]] and [[software]] systems subject to a "real-time constraint", for example from [[Event (synchronization primitive)|event]] to [[Event (computing)|system response]].<ref>{{Cite web |title=FreeRTOS – Open Source RTOS Kernel for small embedded systems – What is FreeRTOS FAQ? |url=https://www.freertos.org/FAQWhat.html#WhyUseRTOS |access-date=2021-03-08 |website=FreeRTOS |language=en-US}}</ref> Real-time programs must guarantee response within specified time constraints, often referred to as "deadlines".<ref name="Ben-Ari-pg164">[[Mordechai Ben-Ari|Ben-Ari, Mordechai]]; "Principles of Concurrent and Distributed Programming", ch. 16, Prentice Hall, 1990, {{ISBN|0-13-711821-X}}, p. 164</ref>


The term "real-time" is also used in [[Computer simulation|simulation]] to mean that the simulation's clock runs at the same speed as a real clock.
The use of this word should not be confused with the two other legitimate uses of real-time, which in the domain of simulations, means ''real-clock synchronous'', and in the domain of data transfer, media processing and enterprise systems, the term is intended to mean ''without perceivable delay''.


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 usually ''guarantee'' a response within any timeframe, although ''typical'' or ''expected'' response times may be given. Real-time processing ''fails'' if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of [[Load (computing)|system load]].
The needs of real-time software requires the use of one or more [[synchronous programming language]]s, [[real-time operating system]]s, and real-time networks which provide the essential frameworks on which to build a real-time software application.


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".<ref>{{cite book |last=Martin |first=James |url=https://archive.org/details/programmingrealt0000mart |title=Programming Real-time Computer Systems |date=1965 |publisher=Prentice-Hall Incorporated |isbn=978-0-13-730507-0 |location=Englewood Cliffs, New Jersey |page=[https://archive.org/details/programmingrealt0000mart/page/4 4] |language=en-us |url-access=registration}}</ref> The term "real-time" is used in [[Industrial control system|process control]] and [[enterprise system]]s to mean "without significant delay".
A real-time system may be one where its application can be considered (within context) to be [[mission critical]]. The [[anti-lock brakes]] on a car are a simple example of a real-time computing system &mdash; the real-time constraint in this system is the time in which the brakes must be released to prevent the wheel from locking. Real-time computations can be said to have ''failed'' if they are not completed before their deadline, where their deadline is relative to an event. A real-time deadline must be met, regardless of [[Load (computing)|system load]].

Real-time software may use one or more of the following: [[synchronous programming language]]s, [[real-time operating system]]s (RTOSes), and real-time networks. Each of these provide essential frameworks on which to build a real-time software application.

Systems used for many [[Safety-critical system|safety-critical]] applications must be real-time, such as for control of [[fly-by-wire]] aircraft, or [[anti-lock brakes]], both of which demand immediate and accurate mechanical response.<ref>{{cite book
| url = https://books.google.com/books?id=3714jIryozYC&pg=PA356
| title = Computer-Based Industrial Control
| date = May 2010 | access-date = 2015-01-17
| first=Krishna |last=Kant | publisher = PHI Learning
| page = 356
| isbn = 9788120339880
}}</ref>


== History ==
== History ==
The term ''real-time'' derives from its use in early [[simulation]], where a real-world process is simulated at a rate that matched that of the real process (now called [[Real-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. <!-- What does this mean? Where did "dangerous" become an issue? -->
The term ''real-time'' derives from its use in early [[simulation]], where a real-world process is simulated at a rate which matched that of the real process (now called [[real-time simulation]] to avoid ambiguity). [[Analog computer]]s, 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. <!-- What does this mean? Where did "dangerous" become an issue? --><!-- The historical origins of the term has no bearing on its current, correct, technical definition. ''Real-time'' does not refer to either fast or slow processing. In fact, the speed of processing is independent of whether it is considered ''real-time'' or not. For a system to be defined as ''real-time'' it must meet its time constraints — whether those constraints require extremely fast processing or can be met at a more leisurely pace has no bearing on the matter. -->


Minicomputers, particularly in the 1970s onwards, when built into dedicated [[embedded system]]s 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 as [[Data General]]'s [[Data General RDOS|RDOS (Real-Time Disk Operating System)]] and RTOS with [[Foreground-background|background and foreground scheduling]] as well as [[Digital Equipment Corporation]]'s [[RT-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 for [[time-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 via [[dumb terminal]]s.
<!-- The historical origins of the term has no bearing on its current, correct, technical definition. ''Real-time'' does not refer to either fast or slow processing. In fact, the speed of processing is independent of whether it is considered ''real-time'' or not. For a system to be defined as ''real-time'' it must meet its time constraints &mdash; whether those constraints require extremely fast processing or can be met at a more leisurely pace has no bearing on the matter. -->


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 low [[interrupt 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 the [[programmable 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 own [[Scheduling (computing)|scheduler]], 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 example [[Real time Java|Java Real Time]]. Later microprocessors such as the [[Motorola 68000]] and subsequent family members (68010, 68020, [[NXP ColdFire|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|date=September 2013|reason=This whole paragraph contains several questionable statements in regard to MOS, AMD and Motorola CPUs and their interrupt handling, and therefore needs to be rewritten and sourced by reliable sources.}}
== Criteria for real-time computing ==
A system is said to be ''real-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. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline.
<dl>
<dt>Hard</dt>
<dd>Missing a deadline is a total system failure.</dd>
<dt>Firm</dt>
<dd>Infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.</dd>
<dt>Soft</dt>
<dd>The usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.</dd>
</dl>


== {{anchor|Hard|Firm|Require|Soft}}Criteria for real-time computing ==
Thus, the goal of a '''hard real-time system''' is to ensure that all deadlines are met, but for '''soft real-time systems''' the goal becomes meeting a certain subset of deadlines in order to optimize some application specific criteria. The particular criteria optimized depends 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.
A system is said to be ''real-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.<ref>{{cite journal | last1 = Shin | first1 = Kang G. |author-link=Kang G. Shin | last2 = Ramanathan | first2 = Parameswaran | title = Real-time computing: a new discipline of computer science and engineering | journal = Proceedings of the IEEE | volume = 82 | issue = 1 | pages = 6–24 | date = Jan 1994 | issn = 0018-9219 | doi = 10.1109/5.259423| url = http://kabru.eecs.umich.edu/papers/publications/1994/ramanathan-shin-ieee-proceedings.pdf | citeseerx = 10.1.1.252.3947 }}</ref> Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline:<ref>Kopetz, Hermann; ''Real-Time Systems: Design Principles for Distributed Embedded Applications'', Kluwer Academic Publishers, 1997</ref>
* ''Hard''{{snd}} missing a deadline is a total system failure.
* ''Firm''{{snd}} infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
* ''Soft''{{snd}} the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.


Thus, the goal of a ''hard real-time system'' is to ensure that all deadlines are met, but for ''soft 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 is 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). For example, a [[automobile|car]] [[engine]] control system is a hard real-time system because a delayed signal may cause engine failure or damage. Other examples of hard real-time embedded systems include medical systems such as heart [[artificial pacemaker|pacemaker]]s and industrial process controllers. Hard real-time systems are typically found interacting at a low level with physical hardware, in [[embedded system]]s. Early video game systems such as the [[Atari 2600]] and [[Cinematronics]] vector graphics had hard real-time requirements because of the nature of the graphics and timing hardware.


'''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 of [[Computer multitasking|multitasking]] systems the scheduling policy is normally priority driven ([[Preemptive multitasking|pre-emptive]] schedulers). Other scheduling algorithms include [[Earliest deadline first scheduling|Earliest Deadline First]], which, ignoring the overhead of [[context switch]]ing, is sufficient for system loads of less than 100%.<ref>C. Liu and J. Layland. Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment. Journal of the ACM, 20(1):46--61, Jan. 1973. http://citeseer.ist.psu.edu/liu73scheduling.html</ref> New overlay scheduling systems, such as an [[Adaptive Partition Scheduler]] assist in managing large systems with a mixture of hard real-time and non real-time applications.
* A [[automobile|car]] [[internal combustion engine|engine]] control system is a hard real-time system because a delayed signal may cause engine failure or damage.
* Medical systems such as heart [[artificial pacemaker|pacemaker]]s. Even though a pacemaker's task is simple, because of the potential risk to human life, medical systems like these are typically required to undergo thorough testing and certification, which in turn requires hard real-time computing in order to offer provable guarantees that a failure is unlikely or impossible.
* Industrial process controllers, such as a machine on an [[assembly line]]. If the machine is delayed, the item on the assembly line could pass beyond the reach of the machine (leaving the product untouched), or the machine or the product could be damaged by activating the robot at the wrong time. If the failure is detected, both cases would lead to the assembly line stopping, which slows production. If the failure is not detected, a product with a defect could make it through production, or could cause damage in later steps of production.
* Hard real-time systems are typically found interacting at a low level with physical hardware, in [[embedded system]]s. Early video game systems such as the [[Atari 2600]] and [[Cinematronics]] vector graphics had hard real-time requirements because of the nature of the graphics and timing hardware.
* [[Softmodem]]s replace a hardware modem with software running on a computer's [[Central processing unit|CPU]]. The software must run every few milliseconds to generate the next audio data to be output. If that data is late, the receiving modem will lose synchronization, causing a long interruption as synchronization is reestablished or causing the connection to be lost entirely.
* Many types of [[Printer (computing)|printers]] have hard real-time requirements, such as [[inkjet]]s (the ink must be deposited at the correct time as the printhead crosses the page), [[laser printer]]s (the laser must be activated at the right time as the beam scans across the rotating drum), and dot matrix and various types of [[line printer]]s (the impact mechanism must be activated at the right time as the print mechanism comes into alignment with the desired output). A failure in any of these would cause either missing output or misaligned output.


In the context of [[Computer multitasking|multitasking]] systems the [[scheduling policy]] is normally priority driven ([[Preemptive multitasking|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 as [[Rate-monotonic scheduling|rate-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, like [[Earliest deadline first scheduling|earliest deadline first]], which, ignoring the overhead of [[context switch]]ing, is sufficient for system loads of less than 100%.<ref>Liu, Chang L.; and Layland, James W.; "Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment", ''Journal of the ACM'', 20(1):46-61, January 1973, http://citeseer.ist.psu.edu/liu73scheduling.html</ref> New overlay scheduling systems, such as an [[adaptive partition scheduler]] assist in managing large systems with a mixture of hard real-time and non real-time applications.
Soft real-time systems are typically used where there is some issue of concurrent access and the need to keep a number of connected systems up to date with changing situations; for example software that maintains and updates the flight plans for commercial [[airline]]rs. The flight plans must be kept reasonably current but can operate to a latency of seconds. Live audio-video systems are also usually soft real-time; violation of constraints results in degraded quality, but the system can continue to operate.


'''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:
=== Real-time in Digital Signal Processing ===
* The assembly line machine described earlier as ''hard'' real-time could instead be considered ''firm'' real-time. A missed deadline still causes an error which needs to be dealt with: there might be machinery to mark a part as bad or eject it from the assembly line, or the assembly line could be stopped so an operator can correct the problem. However, as long as these errors are infrequent, they may be tolerated.
In a real-time [[Digital 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 samples ''independent'' of the processing delay.<ref name="Kuo-Lee-Tian">S.M. Kuo, B.H. Lee, and W. Tian, "Real-Time Digital Signal Processing: Implementations and Applications", Wiley, 2006. ISBN 0470014954. Section 1.3.4: ''Real-Time Constraints''.[http://media.wiley.com/product_data/excerpt/54/04700149/0470014954.pdf]</ref> It means that the processing delay must be bounded even if the processing continues for an unlimited time. That means that the average processing time per sample is no greater than the sampling period, which is the reciprocal of the [[sampling rate]]. This is the criterion whether the samples are grouped together in large segments and processed in blocks or are processed individually and whether there are long, short, or non-existent [[data buffer|input and output buffers]].


'''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:
Consider an [[Audio signal processing|audio DSP]] example: if a process requires 2.01 seconds to [[Audio analysis|analyze]], [[Sound synthesis|synthesize]], or process 2.00 seconds of sound, it is not real-time. If it takes 1.99 seconds, it is or can be made into, a real-time DSP process.
* Software that maintains and updates the flight plans for commercial [[airline]]rs. The flight plans must be kept reasonably current, but they can operate with the latency of a few seconds.
* Live audio-video systems are also usually soft real-time. A frame of audio which is played late may cause a brief audio glitch (and may cause all subsequent audio to be delayed correspondingly, causing a perception that the audio is being played slower than normal), but this may be better than the alternatives of continuing to play silence, static, a previous audio frame, or estimated data. A frame of video that is delayed typically causes even less disruption for viewers. The system can continue to operate and also recover in the future using workload prediction and reconfiguration methodologies.<ref>{{cite journal | title = Real-time reconfiguration for guaranteeing QoS provisioning levels in Grid environments | journal = Future Generation Computer Systems | volume = 25 | issue = 7 | pages = 779–784 | date = July 2009 | doi = 10.1016/j.future.2008.11.001| last1 = Menychtas | first1 = Andreas | last2 = Kyriazis | first2 = Dimosthenis | last3 = Tserpes | first3 = Konstantinos }}</ref>
* Similarly, video games are often soft real-time, particularly as they try to meet a target [[frame rate]]. As the next image cannot be computed in advance, since it depends on inputs from the player, only a short time is available to perform all the computing needed to generate a frame of video before that frame must be displayed. If the deadline is missed, the game can continue at a lower frame rate; depending on the game, this may only affect its graphics (while the gameplay continues at normal speed), or the gameplay itself may be slowed down (which was common on older [[Third generation of video game consoles|third-]] and [[Fourth generation of video game consoles|fourth-generation consoles]]).


=== Real-time in digital signal processing ===
A common life analog is standing in a line or [[Queue area|queue]] 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 outputted as rapidly, on average, as they are being inputted and that process '''is''' real-time. The grocer might go out of business or must at least lose business if he/she cannot make his/her checkout process real-time (so it's fundamentally important that this process be real-time).
In a real-time [[digital 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 samples ''independent'' of the processing delay.<ref name="Kuo-Lee-Tian">Kuo, Sen M.; Lee, Bob H.; and Tian, Wenshun; "Real-Time Digital Signal Processing: Implementations and Applications", Wiley, 2006, {{ISBN|0-470-01495-4}}, [http://media.wiley.com/product_data/excerpt/54/04700149/0470014954.pdf Section 1.3.4: ''Real-Time Constraints''].</ref> It means that the processing delay must be bounded even if the processing continues for an unlimited time. The [[arithmetic mean|mean]] processing time per sample, including [[Overhead (computing)|overhead]], is no greater than the sampling period, which is the reciprocal of the [[sampling 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-existent [[data buffer|input and output buffers]].


Consider an [[Audio signal processing|audio DSP]] example; if a process requires 2.01 seconds to [[Audio analysis|analyze]], [[Sound synthesis|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 signal processing algorithm that cannot keep up with the flow of input data with output getting farther and farther behind the input is not real-time. But if the delay is bounded during a process that operates over an unlimited time, then that signal processing algorithm is real-time, even if the throughput delay may be very long.

A common life analogy is standing in a line or [[Queue area|queue]] 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 process ''is'' 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.

==== Live vs. real-time ====

Real-time signal processing is necessary, but not sufficient in and of itself, for live signal processing such as what is required in [[live 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 using [[stage monitor]]s or [[in-ear monitor]]s and not noticeable as [[lip 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.<ref>{{cite journal|last1=Kudrle|first1=Sara|last2=Proulx|first2=Michel|last3=Carrieres|first3=Pascal|last4=Lopez|first4=Marco|title=Fingerprinting for Solving A/V Synchronization Issues within Broadcast Environments|journal=SMPTE Motion Imaging Journal|date=July 2011|volume=120|issue=5|pages=36–46|doi=10.5594/j18059XY|quote=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|display-authors=etal}}</ref>

Real-time bidirectional [[G.114|telecommunications 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 and high-performance ==
== Real-time and high-performance ==
Real-time computing is sometimes misunderstood to be [[high-performance computing]], but this is not always the case. For example, a massive [[supercomputer]] 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 has been designed to meet its required deadlines, no further performance gains are obligatory. 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 not catastrophic failures. In a real-time system, such as the [[FTSE 100 Index]], a slow-down beyond limits would often be considered catastrophic in its application context. Therefore, the most important requirement of a real-time system is predictability and not performance.
Real-time computing is sometimes misunderstood to be [[high-performance computing]], but this is not an accurate classification.<ref name="Stankovic1988">{{Citation |title=Misconceptions about real-time computing: a serious problem for next-generation systems |first=John |last=Stankovic |year=1988 |periodical=Computer |volume=21 |issue=10 |publisher=IEEE Computer Society |doi=10.1109/2.7053 |page=11|s2cid=13884580 }}</ref> For example, a massive [[supercomputer]] 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 not [[catastrophic failure]]s. In a real-time system, such as the [[FTSE 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 many [[Computer chess|chess-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.
Some kinds of software, such as many [[Computer chess|chess-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.

== {{Anchor|Near real-time}}Near real-time ==
The term "near real-time" or "nearly real-time" (NRT), in [[telecommunications]] and [[computing]], refers to the time [[Network delay|delay]] introduced, by automated [[data processing]] or [[telecommunications network|network]] transmission, between the occurrence of an event and the use of the processed data, such as for display or [[feedback]] 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.<ref name=1037C>{{cite web|url=http://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm |title=Federal Standard 1037C: Glossary of Telecommunications Terms |publisher=Its.bldrdoc.gov |access-date=2014-04-26}}</ref>

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.<ref name=1037C /> 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.


==Design methods==
==Design methods==
Several methods exist to aid the design of real-time systems, an example of which is [[Modular Approach to Software Construction Operation and Test|MASCOT]], an old but very successful method which represents the [[Concurrency (computer science)|concurrent]] structure of the system. Other examples are [[HOOD method|HOOD]], Real-Time UML, [[AADL]] the [[Ravenscar profile]], [[Real time Java|Real-Time Java]], WIMS Engine Server (a [[real-time web|true-realtime web]] implementation).
Several methods exist to aid the design of real-time systems, an example of which is [[Modular Approach to Software Construction Operation and Test|MASCOT]], an old but very successful method that represents the [[Concurrency (computer science)|concurrent]] structure of the system. Other examples are [[HOOD method|HOOD]], Real-Time UML, [[Architecture Analysis & Design Language|AADL]], the [[Ravenscar profile]], and [[Real time Java|Real-Time Java]].


==See also==
==See also==
{{Div col|colwidth=25em}}
*[[Synchronous programming language]]
* [[Autonomous peripheral operation]]
*[[Ptolemy Project]]
*[[DSOS]]
* [[Control system]]
* [[Failure detector]]
*[[Worst-case execution time]]
* [[Nodal architecture]]
* [[Processing modes]]
* [[Ptolemy Project]]
* [[Real-time data]]
* [[Real-time computer graphics]]
* [[Real-time operating system]]
* [[Real-time testing]]
* [[Remote diagnostics]]
* [[Scheduling analysis real-time systems]]
* [[Synchronous programming language]]
* [[Time-utility function]]
* [[Stephen J. Mellor|Ward–Mellor method]]
* [[Worst-case execution time]]
{{Div col end}}


==References==
==References==
{{reflist}}
{{Reflist}}

==Further reading==
*{{citation|first1=Alan |last1=Burns |first2=Andy |last2=Wellings|title=Real-Time Systems and Programming Languages|year=2009|publisher=Addison-Wesley|edition=4th|isbn=978-0-321-41745-9}}
*{{citation |last=Buttazzo |first=Giorgio |title=Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications |publisher=Springer |location=New York, New York |year=2011 |isbn=9781461406761 |url=https://books.google.com/books?id=h6q-e4Q_rzgC&q=%22real-time%22 |via=[[Google Books]]}}.
*{{citation |last=Liu |first=Jane W. S. |author-link=Jane Liu |title=Real-time systems |publisher=Prentice Hall |location=Upper Saddle River, New Jersey |year=2000}}.
*[https://www.springer.com/journal/11241 The International Journal of Time-Critical Computing Systems]


==External links==
==External links==
* [https://cmte.ieee.org/tcrts/ IEEE Technical Committee on Real-Time Systems]
=== Technical committees ===
*[http://cs-www.bu.edu/pub/ieee-rts/ IEEE Technical Committee on Real-Time Systems]
* [http://www.ecrts.org Euromicro Technical Committee on Real-time Systems]
* [https://web.archive.org/web/20121128161655/http://www.opal-rt.com/technical-document/what-where-and-why-real-time-simulation The What, Where and Why of Real-Time Simulation]
*[http://www.ecrts.org Euromicro Technical Committee on Real-time Systems]
* {{cite web |last1=Johnstone |first1=R.L. |title=RTOS—Extending OS/360 for real time spaceflight control |url=http://bitsavers.trailing-edge.com/pdf/ibm/360/nasa_rtos/RTOS_AFIPS_1969.pdf |website=Bitsavers |access-date=February 24, 2023}}

*{{cite journal |last1=Coyle |first1=R. J. |last2=Stewart |first2=J. K. |date=September 1963 |title=Design of a Real-time Programming System |journal=Computers and Automation |volume=XII |issue=9 |pages=26–34 |url=https://archive.org/details/bitsavers_computersA_7555012/page/n25?q=%22DESIGN+OF+A+REAL-TIME+PROGRAMMING+SYSTEM%22 |publisher=Datatrol Corporation |place=Silver Spring, Maryland |quote=[...] set of notes which will hopefully point up problem areas which should be considered in real time design.}}
=== Scientific conferences ===
*[http://www.ecrts.org/ ECRTS - Euromicro Conference on Real-time Systems]
*[http://www.rtss.org/ IEEE Real-time Systems Symposium]
*[http://www.rtas.org/ IEEE Real-time Technology and Applications Symposium]
*[http://www.informatik.uni-trier.de/~ley/db/conf/isorc/index.html International Symposium on Object-oriented Real-time distributed Computing]
*[http://www.rtcsa.org/ IEEE International Conference on Embedded and Real-Time Computing Systems and Applications]
*[http://rtecc.com/home/ Real-Time & Embedded Computing Conference]

=== Journals ===
* [http://www.inderscience.com/ijccbs International Journal of Critical Computer-Based Systems]
* [http://www.springer.com/computer/communication+networks/journal/11241 International Journal of Real-Time Systems]

=== Research groups ===
*[http://www.cister.isep.ipp.pt/ CISTER Research Unit, ISEP, Polytechnic Institute of Porto (IPP), Portugal]
*[http://www.loria.fr/equipes/TRIO/english/index.html Real-Time Systems Research Group,INRIA,LORIA NANCY, France]
*[http://www.cs.virginia.edu/~control/ Real-Time & Embedded Computing Laboratory (USMAN SHARIF BCS-SP03-37)]
*[http://www.mrtc.mdh.se/ Mälardalen Real-Time research Centre]
*[http://www.eecs.umich.edu/RTCL Real-Time Computing Laboratory]
*[http://www.ida.liu.se/~rtslab/ Real-Time Systems Laboratory]
*[http://rtselab.org/ RTSE Laboratory]
*[http://www.rts.uni-hannover.de/en Institute for Systems Engineering - Real Time systems Group]
*[http://retis.sssup.it/ Real-Time Systems Laboratory at Scuola Superiore Sant'Anna, Pisa, Italy]
*[http://rts.eit.uni-kl.de/ Technical University of Kaiserslautern - Institute for Electrical Engineering and Information Technology - Real-Time Systems Group]
*[http://www.vmars.tuwien.ac.at/ Vienna University of Technology - Institute for Computer Engineering - Real-Time Systems Group]
*[http://www.cs.york.ac.uk/rts/ Real-Time Systems Research Group at the University of York, UK]
*[http://www.chalmers.se/cse/EN/research/research-groups/dependable-real-time Chalmers University of Technology - Dependable Real-Time Systems research group]
*[http://www.artes.uu.se/ ARTES: a national Swedish strategic research initiative in Real-Time Systems supported by the Swedish Foundation for Strategic Research (SSF), SE]
*[http://www.cs.unc.edu/~anderson/real-time/ Real-Time Systems at the University of North Carolina at Chapel Hill]
*[http://www.real-time.ece.vt.edu/ Real-time Systems Laboratory at Virginia Polytechnic and State University, Blacksburg]
*[http://www.mc2labs.com/ mc2labs.com - ICT Research&Development, Mogliano Veneto IT - Realtime Internet programming infrastructures]

=== Technical Papers ===
*[http://www.opal-rt.com/technical-document/what-where-and-why-real-time-simulation The What, Where and Why of Real-Time Simulation]


{{Computer science}}
{{DEFAULTSORT:Real-Time Computing}}
{{DEFAULTSORT:Real-Time Computing}}
[[Category:Real-time computing| ]]
[[Category:Real-time computing| ]]
[[Category:Real-time technology|*]]

[[ca:Computació en temps real]]
[[de:Echtzeitsystem]]
[[es:Computación en tiempo real]]
[[fa:رایانش بی‌درنگ]]
[[fr:Système temps réel]]
[[id:Real-time]]
[[he:מערכת זמן אמת]]
[[ms:Pengkomputeran masa-sebenar]]
[[nl:Real-time]]
[[ja:リアルタイムシステム]]
[[no:Sanntidssystem]]
[[pl:System czasu rzeczywistego]]
[[pt:Tempo real]]
[[ru:Системы реального времени]]
[[simple:Real-time computing]]
[[th:ระบบเวลาจริง]]
[[vi:Hệ thống thời gian thực]]

Latest revision as of 06:56, 18 December 2024

Not to be confused with Real-time communication or Real-time clock, closely related technologies that are also often abbreviated to RTC.

Real-time computing (RTC) is the computer science term for hardware and software systems subject to a "real-time constraint", for example from event to system 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 in simulation 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 usually guarantee a response within any timeframe, although typical or expected response times may be given. Real-time processing fails if not completed within a specified deadline relative to an event; deadlines must always be met, regardless of system 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 in process control and enterprise 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 many safety-critical applications must be real-time, such as for control of fly-by-wire aircraft, or anti-lock brakes, both of which demand immediate and accurate mechanical response.[4]

History

[edit]

The term real-time derives from its use in early simulation, where a real-world process is simulated at a rate which matched that of the real process (now called real-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 dedicated embedded 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 as Data General's RDOS (Real-Time Disk Operating System) and RTOS with background and foreground scheduling as well as Digital Equipment Corporation's RT-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 for time-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 via dumb 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 low interrupt 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 the programmable 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 own scheduler, 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 example Java Real Time. Later microprocessors such as the Motorola 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]

Criteria for real-time computing

[edit]

A system is said to be real-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]

  • Hard – missing a deadline is a total system failure.
  • Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.
  • Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

Thus, the goal of a hard real-time system is to ensure that all deadlines are met, but for soft 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:

  • A car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage.
  • Medical systems such as heart pacemakers. Even though a pacemaker's task is simple, because of the potential risk to human life, medical systems like these are typically required to undergo thorough testing and certification, which in turn requires hard real-time computing in order to offer provable guarantees that a failure is unlikely or impossible.
  • Industrial process controllers, such as a machine on an assembly line. If the machine is delayed, the item on the assembly line could pass beyond the reach of the machine (leaving the product untouched), or the machine or the product could be damaged by activating the robot at the wrong time. If the failure is detected, both cases would lead to the assembly line stopping, which slows production. If the failure is not detected, a product with a defect could make it through production, or could cause damage in later steps of production.
  • Hard real-time systems are typically found interacting at a low level with physical hardware, in embedded systems. Early video game systems such as the Atari 2600 and Cinematronics vector graphics had hard real-time requirements because of the nature of the graphics and timing hardware.
  • Softmodems replace a hardware modem with software running on a computer's CPU. The software must run every few milliseconds to generate the next audio data to be output. If that data is late, the receiving modem will lose synchronization, causing a long interruption as synchronization is reestablished or causing the connection to be lost entirely.
  • Many types of printers have hard real-time requirements, such as inkjets (the ink must be deposited at the correct time as the printhead crosses the page), laser printers (the laser must be activated at the right time as the beam scans across the rotating drum), and dot matrix and various types of line printers (the impact mechanism must be activated at the right time as the print mechanism comes into alignment with the desired output). A failure in any of these would cause either missing output or misaligned output.

In the context of multitasking systems the scheduling 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 as rate-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, like earliest deadline first, which, ignoring the overhead of context switching, is sufficient for system loads of less than 100%.[7] New overlay scheduling systems, such as an adaptive 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:

  • The assembly line machine described earlier as hard real-time could instead be considered firm real-time. A missed deadline still causes an error which needs to be dealt with: there might be machinery to mark a part as bad or eject it from the assembly line, or the assembly line could be stopped so an operator can correct the problem. However, as long as these errors are infrequent, they may be tolerated.

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:

  • Software that maintains and updates the flight plans for commercial airliners. The flight plans must be kept reasonably current, but they can operate with the latency of a few seconds.
  • Live audio-video systems are also usually soft real-time. A frame of audio which is played late may cause a brief audio glitch (and may cause all subsequent audio to be delayed correspondingly, causing a perception that the audio is being played slower than normal), but this may be better than the alternatives of continuing to play silence, static, a previous audio frame, or estimated data. A frame of video that is delayed typically causes even less disruption for viewers. The system can continue to operate and also recover in the future using workload prediction and reconfiguration methodologies.[8]
  • Similarly, video games are often soft real-time, particularly as they try to meet a target frame rate. As the next image cannot be computed in advance, since it depends on inputs from the player, only a short time is available to perform all the computing needed to generate a frame of video before that frame must be displayed. If the deadline is missed, the game can continue at a lower frame rate; depending on the game, this may only affect its graphics (while the gameplay continues at normal speed), or the gameplay itself may be slowed down (which was common on older third- and fourth-generation consoles).

Real-time in digital signal processing

[edit]

In a real-time digital 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 samples independent of the processing delay.[9] It means that the processing delay must be bounded even if the processing continues for an unlimited time. The mean processing time per sample, including overhead, is no greater than the sampling period, which is the reciprocal of the sampling 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-existent input and output buffers.

Consider an audio DSP example; if a process requires 2.01 seconds to analyze, 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 or queue 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 process is 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.

Live vs. real-time

[edit]

Real-time signal processing is necessary, but not sufficient in and of itself, for live signal processing such as what is required in live 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 using stage monitors or in-ear monitors and not noticeable as lip 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 bidirectional telecommunications 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 and high-performance

[edit]

Real-time computing is sometimes misunderstood to be high-performance computing, but this is not an accurate classification.[11] For example, a massive supercomputer 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 not catastrophic failures. In a real-time system, such as the FTSE 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 many chess-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.

Near real-time

[edit]

The term "near real-time" or "nearly real-time" (NRT), in telecommunications and computing, refers to the time delay introduced, by automated data processing or network transmission, between the occurrence of an event and the use of the processed data, such as for display or feedback 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.

Design methods

[edit]

Several methods exist to aid the design of real-time systems, an example of which is MASCOT, an old but very successful method that represents the concurrent structure of the system. Other examples are HOOD, Real-Time UML, AADL, the Ravenscar profile, and Real-Time Java.

See also

[edit]

References

[edit]
  1. ^ "FreeRTOS – Open Source RTOS Kernel for small embedded systems – What is FreeRTOS FAQ?". FreeRTOS. Retrieved 2021-03-08.
  2. ^ Ben-Ari, Mordechai; "Principles of Concurrent and Distributed Programming", ch. 16, Prentice Hall, 1990, ISBN 0-13-711821-X, p. 164
  3. ^ Martin, James (1965). Programming Real-time Computer Systems. Englewood Cliffs, New Jersey: Prentice-Hall Incorporated. p. 4. ISBN 978-0-13-730507-0.
  4. ^ Kant, Krishna (May 2010). Computer-Based Industrial Control. PHI Learning. p. 356. ISBN 9788120339880. Retrieved 2015-01-17.
  5. ^ Shin, Kang G.; Ramanathan, Parameswaran (Jan 1994). "Real-time computing: a new discipline of computer science and engineering" (PDF). Proceedings of the IEEE. 82 (1): 6–24. CiteSeerX 10.1.1.252.3947. doi:10.1109/5.259423. ISSN 0018-9219.
  6. ^ Kopetz, Hermann; Real-Time Systems: Design Principles for Distributed Embedded Applications, Kluwer Academic Publishers, 1997
  7. ^ Liu, Chang L.; and Layland, James W.; "Scheduling Algorithms for Multiprogramming in a Hard Real-time Environment", Journal of the ACM, 20(1):46-61, January 1973, http://citeseer.ist.psu.edu/liu73scheduling.html
  8. ^ Menychtas, Andreas; Kyriazis, Dimosthenis; Tserpes, Konstantinos (July 2009). "Real-time reconfiguration for guaranteeing QoS provisioning levels in Grid environments". Future Generation Computer Systems. 25 (7): 779–784. doi:10.1016/j.future.2008.11.001.
  9. ^ Kuo, Sen M.; Lee, Bob H.; and Tian, Wenshun; "Real-Time Digital Signal Processing: Implementations and Applications", Wiley, 2006, ISBN 0-470-01495-4, Section 1.3.4: Real-Time Constraints.
  10. ^ Kudrle, Sara; Proulx, Michel; Carrieres, Pascal; Lopez, Marco; et al. (July 2011). "Fingerprinting for Solving A/V Synchronization Issues within Broadcast Environments". SMPTE Motion Imaging Journal. 120 (5): 36–46. doi:10.5594/j18059XY. 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
  11. ^ Stankovic, John (1988), "Misconceptions about real-time computing: a serious problem for next-generation systems", Computer, vol. 21, no. 10, IEEE Computer Society, p. 11, doi:10.1109/2.7053, S2CID 13884580
  12. ^ a b "Federal Standard 1037C: Glossary of Telecommunications Terms". Its.bldrdoc.gov. Retrieved 2014-04-26.

Further reading

[edit]
[edit]
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Real-time_computing&oldid=1263720334"