Near Real Time means effectively Real Time but without guarantees of hitting specific deadlines. Also known as soft real time (as opposed to hard real time).
For example Erlang Language is used in Near Real Time telecommunications and Internet applications, e.g. in switches, etc. It is a dynamic language with a Non Real Time garbage collector. It does not have specific deadline capability, but it effectively works in practice.
This does not imply that a Near Real Time system that works in practice could work in true Real Time. You cannot count on it to do so.
The term Near Real Time is also sometimes used to mean that users see data that is only a few seconds old. (But purists favor the above definition.)
Actually, purists use "real time" and "other." If it isn't truly real time then it isn't. There is no substitute.
As a purist, I use the phrase soft Real Time to refer to conditions where we can make probabilistic guarantees about delay - e.g. when we can assert that delays are bounded by a Poisson distribution or Bell curve. This seems to be a much stronger assertion than 'Near Real Time', since it still involves a useful guarantee even without the 'hard' deadline boundaries.
You, sir, are simply not a purist in any sense of the word. If a system has fully predictive latency then it is real time. If it does not then it isn't -- that's how real time systems are defined. Period. There is no "near real time," no "soft real time," no "probabilistic real time," nor any other blather. It's real time or it ain't.
Not even 'hard Real Time' systems have "fully predictive latency". They have upper bounds, and sometimes lower bounds. Latencies are never fully deterministic down to the hardware layer. Issues such as metastability and clock drift prevent such a thing. I'm a purist in the sense that I won't call a system Real Time unless it can be proven; in the industry, unfortunately, the word gets bandied about even for aviation software without any formal analysis. I would guess you're not involved with Real Time systems of any sort, just contributing here to 'out-pure' me for kicks and grins.
The use of this term within the purist category of "other" is a recognition of necessary processing and presenting time frames. Illustration: We cannot observe the Universe in "Real Time" because of physical separation distances involved. In the computing sense, Near Real Time is a recognition of this taking into consideration that what we observe is in reality a "playback" of the real thing, since it has been through a process of encoding-storage and decoding-presentation and the attendant time requred for the operations. -- Donald Noyes.20110706
Real Time does not mean zero latency. It means controlled latency. Delays are acceptable where we can make guarantees about them and still meet system timing requirements. We do not say 'Near Real Time' when we have delay; we say it when we cannot bound the delay.
A video camera cannot observe the universe. It can only observe the light that strikes the sensitive elements on the camera. That light might carry information about locations distant and in the past. We can call such a system 'Real Time' if the information in the video is processed at the same rate it is obtained, such that we can guarantee the delay between receiving a frame and updating our information, as opposed to requiring a later batch effort.
Consider this:
I am sure that segments and intervals of time can be reproduced to appear in dependable and predictable manner such as to be effective in part, but I am speaking of Near Real Time in such a manner as to allow information and control interchange two-way-simultaneous in packets which are longer in duration than the magnitudes of the two-way delay.
This is if response requires processing before response, or is dependent in the case of control on the receiving end's process response to changes commanded. It he interchange is over great distances and the command increments are small (less than complete sequences and not autonoumus or semi-autonomous), task completions are difficult, or severely drawn out. Such is the case in controlling a robotic vehicle say at a distance of Mars. Instead of commands, one must depend upon sequences with local feedback and control or near autonomous decision and control. Other real-time problems occur when both processing units misunderstand or only partly process the information being exchanged, as in when the receiving party begins a return exchange before processing the complete message from the sending party. This most often results in an interrupted or halted exchange.
It is true that, as we increase delay or risk of disruption, we must simultaneously increase autonomy. That doesn't mean we can't have Real Time, but we do need to specify our actions on appropriate time scales. For example, light-speed round-trip to Mars is 11 to 44 minutes depending on relative orbital, so at that level we would need to schedule actions that take on the order of at least a couple hours to complete. Currently, of course, we are limited to an orbiting communication satellite above Mars, so our real communication delays are up to a day, and thus even longer missions are required. Low-level teleop (move arm 3cm to left) would be grossly inefficient and unsafe, but we could provide a route or patrol mission. Any code we transmit for autonomous behavior can potentially make real-time decisions at a much finer scale.
Anyhow, it seems you conflate 'Real Time' with 'interactive'. From connotation, that is understandable - we almost always use 'Real Time' in reference to interactive systems. But the meanings are different: Real Time is simply about meeting timing constraints. Those timing constraints might be microseconds, or might be hours. Granted, we could never meet the temporal requirements for teleoperation of a Mars rover... but choosing sane requirements is a separate issue.
Not only are timing constraints important, but also the dependency on time as a function in rates of change, as in the failed mission which was the result of confusing english and metric expressions of velocity to determine the magnitude and timing of the velocity change component of the mission. Requirements may be separately and singly understood, but when employed in connection with another component using differing usages in length, velocity and acceleration the result of which, in this particular critical operation, resulted in an unrecoverable and destructive result.
Clearly communicating requirements is important, but I'm not sure what it has to do with the topic of this page.
See original on c2.com 