Introduction To Real-Time Embedded Systems

This article will take a first look at real-time embedded systems including classifications, constraints, and design patterns.

One of the most exciting, yet challenging, areas of electrical and computer engineering is embedded system design. If you aren't sure what embedded system design is, please refer to the links at the end of the article. Part of what makes embedded system design so challenging are the numerous design constraints that any embedded system requires. These can include power consumption, limited memory, I/O availability, temperature, spatial constraints, and of course overall cost. For some embedded systems, a particularly important constraint is time.

When a system has to respond to an event or request within a strictly defined time, we call this a real-time system. This defined time is referred to as a deadline. These systems must be predictable and therefore are by definition deterministic.

If a real-time system is embedded, we call it a real-time embedded system. We use these two terms interchangeably in this article. Examples of real-time embedded systems are “mission critical” applications like aircraft controls, anti-lock braking systems, pacemakers, and programmable logic controllers.

Real-Time Classifications

A real-time system can be classified based on the acceptability of missing its timing constraints. If missing a timing constraint is absolutely unacceptable, for instance, if this could result in a loss of human life, we call this a hard real-time system. The pacemaker mentioned above is one example of this.

If missing a timing constraint is acceptable but undesirable we call it a soft real-time system. Email systems, wireless routers, and your cable box all have real-time constraints that they are designed to meet. Even so, the consequences of missing those deadlines are often small or insignificant, e.g., you might get annoyed because your favorite TV show has to buffer for a second. When a soft real-time system misses a deadline for a given operation, the operation does not immediately lose all of its value. Instead, the value diminishes over time—i.e., it decreases toward zero as time moves farther beyond the deadline (see Figure 1, left).

Many systems exist on a spectrum from hard to soft, where it is not unacceptable to miss a deadline, but doing so makes the operation being performed immediately lose all of its value. Systems that lie within this spectrum are often referred to as firm real-time systems (see Figure 1, middle).

In a hard real-time system, a missed deadline creates not only a complete loss of value but also a negative value, i.e., harm (see Figure 1, right).

Figure 1. Real-time system classifications (adapted from: Rochange, Uhrig, and Sainrat. “Time-Predictable Architectures”. 2014, 1.1.2)

Timing Constraints

Every real-time system has a set of timing constraints that it has been designed to meet. If a system doesn't have timing constraints, it is not real-time. These timing constraints can be broken down into two categories: event response and task scheduling.

Event Response

An event is a stimulus that the system must respond to. These can be initiated in both hardware and software, and they indicate that something occurred and must be dealt with. An event may look most familiar when it comes in the form of an internal or external interrupt. For instance, when a button is pressed, the system may sense this and perform the necessary operations. Events can be generated at any time the system detects a change. The time between the moment at which a system detects an event and the moment at which it responds to that event is called latency. Latency is defined as the response time minus the detection time.

L = Tr – Td

Task Scheduling

A task is a set of instructions that need to be run by the system's processor. Some real-time system designers will prefer to schedule tasks, especially if these will run periodically. Many embedded systems need to repeatedly sense a number of inputs and then modify outputs based on this new information. These kinds of systems lend themselves to using tasks. These tasks are typically scheduled and run using a software construct called a scheduler. The time between when a scheduled task is supposed to run and when it actually does run is referred to as jitter. Jitter is defined as actual time minus desired time.

J = Ta – Td

Regardless of whether a real-time system uses event response, task scheduling, or both, the end goal is to have as little latency and jitter as possible, while defining an upper bound (worst-case scenario) that is deemed acceptable.

Design Patterns

How does one go about designing a real-time embedded system? As the requirements of the system grow and the timing constraints tighten, it becomes increasingly difficult to manage all of the needs of an embedded system while meeting deadlines. Below are some well-established principles used throughout the industry.

Round-Robin

Round-robin scheduling is one of the most well-known and widely used scheduling algorithms for managing the constraints of a real-time system. It works just as its name suggests: it gives each system component a turn to use shared resources and complete the desired task. Figure 2, below, shows a CPU giving each task 500 ms of processing time before switching to the next task. Tasks may or may not complete within the 500 ms, and they will often pick up where they left off when their turn comes around.

Figure 2. Round-robin task scheduler

Queuing

Another useful construct in real-time systems is the queue. A queue can be thought of as a production line where items come in and wait to be processed. When ready, the system removes the next item from the queue and handles it. In this way, a new task that needs to be performed can be placed in the queue and will wait while the system handles any tasks that came before. Eventually, the new task is dealt with, even as more tasks come in behind it. Figure 3 shows a first-in-first-out (FIFO) queue, where Task C sits in the queue until both Task A and Task B have been processed.

Figure 3. First-in-first-out (FIFO) queue

RTOS

There comes a point in the design and implementation of a real-time system when the overhead of managing timing constraints is so great that using any single design pattern or principle no longer becomes feasible. It is at this point that a real-time operating system becomes the best-fit solution. A real-time operating system, or RTOS (pronounced R-toss), utilizes the design patterns of scheduling and queuing, but it adds further functionality including task priority, interrupt handling, inter-task communications, file systems, multi-threading, and more. All this results in the most effective method for meeting and exceeding time-constraint goals.

Popular real-time operating systems include VxWorks, QNX, eCos, MbedOS, and FreeRTOS. The first two in the previous list are proprietary, but the other three can be used for free. MbedOS works with Arm's Mbed platform, and FreeRTOS has been ported to many different microcontrollers. We may explore getting one of these up and running in a future article.

Conclusion

In this article, we took a high-level view of real-time embedded systems, with a focus on how these types of systems are classified and defined. We classified a real-time system according to how acceptable it is for the system to miss a deadline, and what the consequences of missing that deadlines are. We also discussed timing constraints and three common methods of organizing and implementing a real-time system.

Being an introduction, this article focused more on a conceptual understanding and less on hands-on knowledge. Even so, with an understanding of these concepts, a microcontroller, and an RTOS, you could enable your next design to solve problems that were previously out of reach.

Supporting Information

• What Is Embedded System Design? Defining an Electrical Engineering Field
• Intro to Embedded Development: Styles and Standards