“Real-time” essentially means “happening now or immediately responsive.” In engineering, real-time refers to systems that not only need to calculate the correct response, but they must respond instantly, often in continuous interaction (dynamically) with the system’s environment.
Real-time is an expression used in two main areas with respect to software and electronics. Real-time can refer to a clock in a circuit, as in a Real Time Clock (RTC). An RTC is a circuit that tracks time and date, and is used for setting alarms in relation to time and calendar. An RTC has to remain energized in order to maintain the current time and date; otherwise, the time and date must be reset. An RTC cannot recover the time once it’s lost track of it; not without some form of power to run it. Thus, many RTCs are designed with a trickle of power or a battery, even if everything else has “gone to sleep” to preserve power. An RTC should not be confused with the “clock” or “timer” in a circuit with an MCU. A clock or timer performs a very different function of timing (or clocking) computational cycles for a processor or controller.
The term “real-time” is also used with computers and controllers. Here, real-time refers to the immediacy of response that the “brain” of the device handles. A processor, controller, or operating system is real-time if it is able to respond immediately to situations without waiting for an hour glass icon to stop turning. Personal computers (PCs) are not meant to run real-time processes in this sense and do not have real-time operating systems; i.e., Windows and iOS operating systems are not meant for the often critical capability required of real-time systems. They do, however, have an RTC so that they can keep calendars and reminders.
Real-time control is critical in many applications due to safety issues. Examples of applications that have real-time constraints are the automotive industry (e.g., drive-by-wire and ABS), air traffic control, process controls, and medical devices (e.g., a pacemaker).
Real-time control or computing requires the processor to prioritize interrupts as they come in and act immediately on those of higher priority, and in “hard” cases without first finishing the task that is currently occupying the processor. “Hard” real-time cannot be dependent on anything that is not 100% reliable in turn, because an event that requires a real-time response cannot wait for an internet connection, for instance. Hard real-time refers to the fact that there are fatal consequences if the system fails to respond in time. In contrast, “soft real-time” is more tolerant of a missed deadline, but the consequences are still not favorable. The lateness of the response affects the value of the deliverable. With hard real-time systems, a late delivery is the same as no delivery at all.
In another example, a soft real-time system may wait for failure before taking corrective action, like a skipped spot on a DVD. A hard real-time system, however, may need to calculate that a good outcome is possible with a given task before performing it. Otherwise, it might perform a different task based on calculations that the deadline cannot be met with the initial, default task. Real-time systems need predictable, dependable resources, especially if there are dynamic inputs and processes that are required for successful execution.
Near, virtual, or firm real-time are subjective terms that can mean many different things, depending on who is defining it. “Near real-time” is similar to saying “good enough to work in this application, with respect to the need for real-time responsiveness.” Any device, process or system that involves safety critical operations might be real-time or have real-time components. Therefore, the phrase “hard real-time” is often used to clarify the seriousness of real-time requirements.
“Firm” real-time is a less-often used term, but like near real-time, it indicates that it is not soft real-time, but not hard real-time, either. A near/firm real-time system might infrequently miss a deadline and cause failure that is not catastrophic, but can be catastrophic if multiple deadlines are missed. An example of a firm real-time system is an automotive robot that occasionally misses a rivet weld. QA personnel downstream can still catch this failure and spot weld it, but missing many welds or missing them randomly and often can ruin the synchronization of the entire production line or cause total failure if the fault is missed. Getting to hard real-time involves more time and effort with exercises such as a Failure Mode Effect Analysis (FMEA) for hard real-time systems.
The study of real-time systems is wide-spread as it applies to aerospace, military, medical, computing, financial and many other industries. Fault tolerant computing is another area where real-time is an important topic; a single failure can lead to a catastrophic system failure. Quality of Service (QoS) is another area within networking where the concept of real-time is relevant, because poor QoS can lead to customer desertion, among other things.
Leave a Reply