问题
I am having trouble deciding on whether to classify my application as 'real time' or 'near real time', or perhaps even something else.
The software receives data immediately as it is generated from the source, then based on certain rules, raises an alert when certain conditions are met. It takes the approach of checking the last 30 seconds of data every 30 seconds to see whether the criteria for a rule has been met.
Is that real time? What are the thresholds for the definitions of real time vs. near real-time?
EDIT
I think this is a duplicate of Define realtime on the web for business.
Please decide if the above thread is insufficient to answer your question.
回答1:
Real-time = Guaranteed maximum time for resolution. It could be picoseconds or minutes depending on the application's requirements
This is StackOverflow's biggest problem: unqualified people answer LOTS of questions with answers that "sound right" and get voted up, people who care whether the answer is actually correct don't spew nonsense fast enough to earn rep to fix the wrong answers. Posting anonymously due to expected knee-jerk reactions.
回答2:
Real-time is getting a required response to an event completed within the time period specified or your system fails.
People are used to thinking this must mean 'small number of milliseconds/microseconds' but that isn't necessarily true - it depends on your system.
If your system will fail if it doesn't complete it's required response within 30 seconds then it's 'real-time'.
For some systems, a fail could be catastrophic, e.g. causing multiple fatalities - this is described as safety critical, e.g. shutting down a nuclear power plant.
回答3:
The phrase "real-time" covers a fairly large patch of ground.
The vague definition is "software that acts within a bounded response time".
Where the boundary is hard e.g. in a car's injection control system, the software is said to be "hard real-time".
Where the boundary is soft e.g. in a music-playback system, where variations of up to 50ms are tolerable, the system is said to be "soft real-time".
So yes, for some definition of real-time, your system is real-time.
But you're probably going to get laughed at if you call it real-time around anybody else who actually works on real-time systems, because 30 seconds is pretty huge.
回答4:
Well, that could be more of a marketing question than a technical one.
Real-time, in terms of embedded hardware, involves a known fixed maximum time for handling incoming information (interrupts and the like).
You can certainly claim 30 seconds delay as real-time especially if the delivery of said information is longer than that.
For example, if your "alert" is an email that could spend 10 minutes in a mail server or a red cross on a monitor that the users only check every half hour, 30 seconds is more than adequate for real-time.
回答5:
I think one aspect that defines real-time is that the process is deterministic - that is, the application's response time is totally predictable based on the inputs.
Thus, painting with very broad brush-strokes, any app sitting on top of Windows can only be "near-real-time", at best. Doubly so if your app is running on some sort of sandbox platform (Java, .NET) where you don't have absolute control over platform functions (eg, garbage collection).
My personal rule is that "real-time" doesn't belong on a desktop PC; that's the realm of PLCs (and yes, they may be running OSes like QNX, VxWorx or even RTLinux).
回答6:
Another way to define "real-time" is by evaluating the capabilities of the many RTOSs (real-time operating systems). e.g QNX's definition is here. Notice that they conform to the POSIX PSE52 Realtime Controller 1003.13-2003 System product standard. Most embedded operating systems will provide similar functionality.
回答7:
Definition of 'hard' real-time from my controls friends - Late information is wrong information. If it needs to be there every 1s and it gets there in 1.1s, it's useless for calculations.
回答8:
I provide a lengthy discourse on this on my web site real-time.org. The home page has a temporary link to a briefing. The briefing discusses how and why people don't understand what "real-time" (and "hard" and "soft" and "predictable" etc.) means. It provides some precise and general definitions. I have heard from people who don't agree with my explanation of this topic, but none of them have come forward with anything remotely as precise and general as mine. "Pull up a chair, let's talk" as Larry King says.
回答9:
I believe the answer is that realtime systems are subjective, in that "real time" is just timeliness contraints imposed by the requirements. Though clearly something that takes 2 hours to respond to a request is not real time, a 30 second delay might be fast enough to qualify as real time.
I work on what I consider real time systems, where when an event happens in the sytem it is immediately propogated to devices on the system, such that the delay in knowing about an update on a device is product of the network latency and the time take to update its in-memory data.
I personally wouldn't classify something with that polls for updates every 30 seconds as realtime. We have a web app as part of the afore mentioned system that does just that, it refreshes every 30 seconds, so the user is presented with data that is at most 30 seconds old. Contrast this with the win forms equalivent that is updated as soon as the event occurs.
Again, "real time" is bounded by your definition of a timely response.
回答10:
I would say the definition of real time would depend on the context. As with the music example real time would need to be milliseconds, but possibly with your example real time could be within 30 seconds or so. It's all relative.
回答11:
I think you need to look at the specific solution or part of the solution in where you need the response to be real-time. A real time response is one which is perceived by the receiver (the application or basically the end-user) as being real-time.
回答12:
Real Time deals with microseconds...mainly around robotics. Think 'move arm 30 microseconds; weld 1000 microseconds;', like in automobile assembly.
Is your 30 seconds based on a Thread sleep or a timer in a non-real time OS? If so, then you have a potential varience. Will you consider it a failure if you're outside that variance (30.01 seconds)? If not, then it's not real time.
回答13:
I am in agreement with John, in your scenario you are looking at least 30 seconds of delay, I would say that it is nearly real time.
来源：https://stackoverflow.com/questions/80394/what-constitutes-real-time