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

 

Learn More About:

 

Comments

4 Comments


  • mjaa 2019-04-18

    Thank you for your introduction to embedded systems design in time critical applications. For over 50 yrs I have been a practitioner and enthusiast in this “beautiful game”. In the early 70’s we wrote structured position independent stack oriented code for many r/t embedded systems. This included using emerging rtos and also writing your own bespoke rtos when memory was often a constraint. This was made possible by the introduction of microprocessor’s such as the Motorola 6809 with its rich orthogonal instruction set that easily facilitated stack oriented argument passing supporting re-entrant and recursive code. An even more significant development in the world of real-time embedded systems design was the Motorola 68000 series whose instruction set allowed the easy partitioning of user and system stacks. This new instruction set also introduced a rich orthogonal set of set of pointer based address modes across what had grown to five 16 bit base registers (2 SPs, 2 index, 1 PC). I would suggest the introduction of the M6809 and especially the M68000 series processors marked a watershed in the development of r/t embedded systems. Whilst material science ( processor speeds, power consumption and logic density) have since made huge leaps over the decades I have not found anything significantly “new” in` r/t systems functionality (processor instruction sets, rtos concepts, primitives etc). My question is “do I have a point?” or is it a self indulgent assertion as a result of the selective memory of those over 60 OR the equally annoying superiority complex of those who have been around this beautiful game (for too long!). I ask “what has significantly changed in RTOS implementation and function over the last 40 yrs?” Hopefully this series and the input of those higher primates in the forum will set me straight.

  • Curt Carpenter 2019-04-19

    It seems to me that the “independent processor per task” approach to real time is increasingly feasible from an economic standpoint, and I wonder what impact that will have on the future of embedded real time hardware and software?

  • Gaofeng Fan 2019-04-20

    one question here, how about 8-bit MCU? I knew vehicles use a lot of 8-bit MCU for simple control. For straightforward task, does 8-bit MCU with simple assembly code be able to handle the task effictively to satisfy your real-time requirement?
    If that scenario makes sense, then does it mean the RTOS is applicable to certain type of complex tasks?

    • sjs7985 2019-04-24

      Yes, an 8-bit MCU programmed in assembly could certainly handle real-time tasks . Yes, an RTOS is most applicable when the complexity of the real-time requirements has become hard to manage. For instance, when a design needs to do many different things that may or may not be related, especially if these tasks need to execute in separate threads while accessing a shared memory space; an RTOS provides the necessary infrastructure to accomplish these things safely and efficiently.