What is “real-time” anyway?

Real-time systems are systems that have timing requirements. A real-time system is considered to fail when it doesn’t meet a timing requirement. How a timing failure is defined (and the consequences of a failed system) can vary widely. It is extremely important to realize that real-time requirements can vary widely, both in the speed of the timing requirement and the severity of consequences if the required real-time deadlines are not met.

Every real-time system is constrained in its ability to respond to events and/or signals. A system’s ability to respond to events and/or signals is referred to as the system’s bandwidth. For example, when designing a signal acquisition chain, the system’s bandwidth for each filter stage must be wide enough to pass through the desired signal in order to maintain the integrity of the signal. If the system’s bandwidth for the filters is not properly designed, the system will fail to provide the desired real-time response to certain input signals.

The system’s hardware and software both have limited bandwidth. All software executes on hardware that has limited resources. For example, the clock frequency of an MCU limits how many instructions it can execute in a given period of time. The rate of instruction execution is also limited by the MCU architecture, which determines how many clock cycles are required to execute each instruction. The ability of the software to respond to events in real time is affected by the algorithms used, the operating system (OS) used (if any), and the effective use of the OS’s features, such as multitasking and timing features.

The limitations of the hardware and software make real-time design both challenging and fun. Challenging, because the designer often has to look into the nitty-gritty of the MCU architecture, including the hardware peripheral registers and the assembly code instructions. But fun, from the satisfaction of understanding the intricacies of how the hardware works, and from being able to write software that takes advantage of it.

It is both a science and an art to balance these limitations and to understand the trade-offs between hardware and software in order to get to the end goal of a working real-time system.

The range of timing requirements

To illustrate the range of timing requirements that can be encountered, let’s consider a few different systems that acquire readings from analog-to-digital converters (ADCs).

Let’s first look at a lower-bandwidth control system. The control system is part of a soldering iron, and the control system maintains the tip’s temperature (as seen in Figure 1.1). The parts of the system we’re concerned with are the MCU, ADC, sensor, and heater.

The MCU is the brain of the control system. It is responsible for the following:

• Taking readings from a temperature sensor via the ADC
• Running a closed-loop control algorithm (to maintain a constant temperature at the soldering iron tip)
• Adjusting the output of the heater as needed

These can be seen in the following figure:

Figure 1.1: MCU-controlled soldering iron

A typical soldering iron would have pretty low bandwidth needs. For example, since the temperature of the tip doesn’t change very quickly, the MCU may only need to acquire 50 ADC samples per second (50 Hz). The control algorithm responsible for adjusting the heater (to maintain a constant temperature) may run at an even slower pace, perhaps 5 times per second (5 Hz).

While we are here, let’s take a quick look at the timing requirements of the ADC. Doing so will give us a feel for some of the time constraints we deal with when designing real-time systems. Figure 1.2 shows a common interface between an MCU and an ADC:

Figure 1.2: MCU with external ADC

The ADC asserts a signal to inform the MCU that the ADC has completed a conversion of the analog signal and that a digital value is ready for the MCU to read. The MCU must read the converted digital value, using the communication channel, before the next conversion takes place, or the result will be overwritten. The MCU has up to 20 ms to transfer the data from the ADC to internal memory before a new reading needs to be taken (as seen in Figure 1.3 below). The MCU also needs to be running the control algorithm to calculate the updated values for the heater output at 5 Hz (200 ms). Both of these cases (although not particularly fast) are examples of real-time requirements.

Figure 1.3: Free-running 50-Hz ADC

Now that we have looked at a lower-bandwidth control system, let’s consider that other control systems may require much higher bandwidth. For example, a network analyzer or oscilloscope may require reading an ADC at a rate of tens of GHz! The raw ADC readings will likely be converted into the frequency domain and graphically displayed on a high-resolution front panel dozens of times a second. To function properly, such a system requires significant data-processing bandwidth, and it must adhere to extremely tight timing requirements.

Somewhere in the middle of the possible bandwidth requirements, you’ll find systems such as closed-loop motion controllers, which will typically need to execute their proportional–integral–derivative (PID) control loops between hundreds of Hz to tens of kHz in order to provide stability in a fast-moving system. So, how fast is real-time? Well, as you can see from the ADC examples alone, it depends on the requirements.

In some of the previous cases, such as the oscilloscope or soldering iron, failure to meet a timing requirement results in poor performance or incorrect data being reported. In the case of the soldering iron, this might be poor temperature control (which could cause damage to components). For the oscilloscope, missing deadlines could cause erroneous readings, which is a failure. Too many inaccurate readings will cause the device to be viewed as unreliable, and sales will decline—all because a real-time requirement wasn’t being met consistently.

In other systems, such as the flight control of an unmanned aerial vehicle (UAV) or motion control in industrial process control, failing to run the control algorithm in a timely manner could result in something more physically catastrophic, such as a crash. In this case, the consequences are potentially life-threatening.

Thankfully, there are steps that can be taken to avoid all of these failure scenarios.

The ways of guaranteeing real-time behavior

One of the easiest ways to ensure that a system does what it is meant to do is to make sure it is as simple as possible while still meeting the requirements (some call this the KISS principle—Keep It Simple, Stupid!). This means resisting the urge to over-complicate a simple task. If a toaster is meant to toast a slice of bread, don’t put a display on it and make it tell you the weather too; just have it turn on a heating element for the right amount of time. This simple task has been accomplished for years without requiring any code or programmable devices whatsoever.

As programmers, when we encounter a problem, we tend to reach for the nearest MCU and start coding. However, some functions of a product are best handled without code at all (this is especially pertinent if a product has electro-mechanical components). A car window doesn’t really need an MCU with a polling loop to run, turning on motors through drivers and watching sensors for feedback to shut them off. This task can actually be handled by a few mechanical switches and diodes. If a feedback-reporting mechanism is required for a given system—such as an error that needs to be asserted in the case of a stuck window—then there may be no choice but to use a more complex solution. However, our goal as engineers should always be the same—solve the problem as simply as possible, without adding additional complexity.

If a problem can be solved by hardware alone, then explore that possibility with the team first before breaking out the MCU. If a problem can be handled by using a simple while loop to perform some polling of the sensor status, then simply poll the sensor for the status; there may be no need to start coding interrupt service routines (ISRs) (we will discuss these later in the book). If the functionality of the device is single-purpose, there are many cases where a full-blown RTOS can simply get in the way—so don’t use one!