Real-time electronic systems: fundamentals, planning, and applications

Informatec Digital » Resources » Real-time electronic systems: fundamentals, planning and applications

Real-time electronic systems are deeply embedded in our daily lives, though they often go unnoticed. From car airbags to air traffic control, and even a simple microwave oven, everything depends on the computer system not only doing things correctly, but doing them at the precise moment . If it exceeds the time limit, even slightly, it's considered a failure, even if the calculation is perfect.

The beauty (and the challenge) of these systems lies in their need to interact with the physical world on very specific timelines . Simply being "fast" isn't enough: they must be predictable, stable, and synchronized with what's happening outside the computer. This is why the design, analysis, and testing of a real-time system are considerably more complex than those of a conventional, general-purpose system.

What is a real-time system and how does it differ from a fast system?

A real-time system (RTS) is essentially a digital system that controls or monitors a physical process with clear time constraints. It must not only produce logically correct results but also guarantee that the response arrives within a defined time frame; failure to meet this deadline constitutes a system failure.

Clear examples of this behavior include the activation of a car's airbag or ABS , a robot trying to catch a ball in mid-air, or the engine management system of a modern vehicle. In all these cases, a delayed reaction, even by a few milliseconds, can be useless or even dangerous.

The word “time” in this context means that correct functioning depends on when the response occurs , not just what it is. And “real” implies that the system must react to external events during their actual evolution, using a timescale consistent with that of the physical environment it controls.

This contrasts with a simply “fast” system, where the only thing that matters is that the output appears as quickly as possible, without having to synchronize with the outside world. A very powerful web server can be fast, but it is not necessarily a real-time system if it does not have strict deadlines tied to physical events.

It is also important to distinguish them from online systems : these may always be connected and responding to requests (for example, a browser or a booking system), but they do not have to respect rigid deadlines coordinated with physical processes, so they are not automatically real-time systems; however, in modern web applications, real-time search may require similar latencies and guarantees.

Practical example: traffic light control at an intersection

A very illustrative example of real-time electronic systems is a traffic light control system at a busy intersection . Simply changing the lights "more or less" on time isn't enough; decisions must be made continuously based on what's happening on the street.

First, traffic is monitored . Sensors (inductive loops, cameras, infrared sensors, etc.) are placed in the lanes and pedestrian crossings to detect vehicles and people. These devices constantly send data to the central controller, which thus receives up-to-date information about the environment.

At the control center, an embedded computer processes the data in real time, applying algorithms that calculate the number of vehicles in line, the occupancy of each lane, and the number of pedestrians waiting. With this information, it determines how long each phase of the traffic light should last in each direction.

Next comes decision-making . The system decides, for example, to extend the green light in the most congested direction to reduce traffic jams or to prioritize a pedestrian crossing if it has been waiting for too long. These decisions are based on predefined optimization policies and on safety and traffic flow requirements.

Once the decision is made, the controller acts on the actuators that govern the lights . It changes the state of the traffic lights with millisecond precision, respecting amber, all red, interlocks, and other safety requirements, ensuring a smooth transition between phases.

All of this is done through continuous optimization : the system monitors traffic without interruption and adjusts green, amber, and red light timings in real time to adapt to sudden changes (a traffic jam, an ambulance passing, variations in traffic flow during certain times of day, etc.). This clearly demonstrates why we talk about real-time: the control logic only makes sense if decisions are executed within specific timeframes.

History and evolution of real-time systems

The origins of real-time computing are closely linked to the control of industrial and aerospace processes in the second half of the 20th century. Reference texts laying the foundations for these systems were published as early as 1965, and shortly thereafter, in 1973, Liu and Layland formalized the mathematical definition of scheduling in strict and flexible real-time systems.

In computer simulation, the term "real-time simulation" began to be used when the computer model ran as fast as the physical process it represented. This presented a classic dilemma: either increase the model's fidelity at the expense of speed, or reduce accuracy to achieve or surpass real-time performance.

The same thing happened with graphical interfaces and game engines : for the experience to be smooth, they must react quickly enough to user input and scene changes, maintaining a high and constant number of frames per second.

Since the 60s and 70s, real-time systems have matured thanks to lessons learned from high-profile real-world cases, some almost disastrous, which helped to refine time analysis and planning techniques.

Landmark cases: Apollo 11 and Mars Pathfinder

One of the most famous incidents in the early history of real-time computing was the overload of the Apollo 11 lunar module's computer . During the descent, the guidance system began issuing alarms (such as the famous 1202) indicating that the CPU was lagging behind its workload.

According to mission reports, if those alarms had persisted, the reliability of the navigation data for the crew would have been compromised, and the mission might have been aborted. Ultimately, based on previous simulations and experience, the decision was made to proceed, and the Eagle module successfully landed on the Moon.

Essentially, it was a case of processor overload : there was more computation than the CPU could handle within the allotted time, especially when the processing associated with the alarm was added to the normal workload. This incident highlighted the importance of maintaining sufficient resource margins in systems where the cost of failure is unacceptable.

Another well-studied case is that of the Mars Pathfinder spacecraft . Here, the problem wasn't so much a matter of raw overload, but rather a phenomenon known as priority inversion, which caused missed deadlines even though the CPU had a seemingly reasonable capacity margin.

In a preemptive scheduling system, priority inversion occurs when a high-priority task is blocked by a low-priority task that owns a shared resource (such as a mutex), and, in the meantime, a medium-priority task interrupts the low-priority task. The result is that the critical task is indirectly blocked by a less important task, breaking real-time guarantees.

To mitigate this risk, the priority inheritance protocol is used . When a high-priority task is blocked by a lower-priority task, the scheduler temporarily raises the priority of the low-priority task to the level of the high-priority task. This prevents intermediate-priority tasks from interrupting it, allowing it to release the resource as quickly as possible and then return to its original priority.

These cases made it clear that designing a STR is not just about "having enough CPU headroom," but also about understanding scheduling and timing theory , and temporarily testing the entire system (hardware, firmware, and software) together.

Basic components of a real-time system

A typical STR consists of a combination of specialized hardware, software, and interface elements with the physical process. It is not simply a program; it is an integrated system that must respond to external stimuli within known timeframes.

On the physical side, we find the system to be controlled : this can be any process susceptible to regulation, such as an industrial plant, a motor, a production line, a traffic light, a robot, or medical equipment. The STR measures its state and applies control actions to keep it within the desired parameters.

Between the physical world and the computer lies a signal interface , comprised of analog-to-digital converters (ADCs) and digital-to-analog converters (DACs), as well as conditioning circuitry. This layer adapts voltages, currents, and signal formats so they can be read and generated by the digital system.

A key element is the real-time clock , which generates periodic interruptions in each sampling period. This synchronizes data acquisition, control, and actuation tasks, ensuring that measurements and commands are issued precisely when they should be.

The system typically includes a human operator console with start and stop controls, interfaces for adjusting parameters, and mechanisms for forcing manual modes. Additionally, screens are used to display statuses, alarms, trends, and any other relevant information for monitoring the process.

Significant status changes are stored in a real-time database , allowing for a record of what has happened, the investigation of failures, and the extraction of statistics to improve management. This historical information grows over time and informs maintenance, optimization, and redesign decisions.

Many industrial environments have a remote monitoring system that allows for the supervision and, in some cases, control of the plant from distributed control centers. This is essential when one facility depends on another (for example, a plant that supplies raw materials to another), and decisions made in one impact the entire chain.

At the heart of the STR is the embedded computer , whose software is usually divided into several types of modules: digital control algorithms (regulators, filters, feedback loops), data logging, address and management interfaces, and direct interaction with the operator.

Key features: time, concurrency, security, and efficiency

Real-time systems typically deal with large and complex problems , involving multiple variables, external devices, and changing conditions. This necessitates careful attention to architecture, planning, and communication mechanisms between tasks.

Since the data comes from the physical world, the system must handle real numbers (floating-point, fixed-scale, etc.) that represent magnitudes such as temperature, pressure, speed, or voltage. The accuracy of the representation and calculation can be crucial for the quality of the control.

Safety and reliability are usually critical: a failure can cause serious economic losses, property damage, personal injuries, or environmental impacts. That's why fault tolerance techniques, redundancy, and controlled degradation strategies are integrated.

Concurrency is another defining characteristic. A STR typically executes several tasks in logical parallel: sensor reading, control, communications, logging , user interface, etc. This necessitates managing shared resources, avoiding race conditions, and ensuring that critical sections do not exceed deadlines.

Efficiency is not a luxury, it's a necessity. A STR must be logically and temporally correct , but also optimized to take full advantage of the CPU, memory, and I/O devices. The challenge lies in finding a balance between timing margin, hardware cost, and software complexity.

Input/output devices are typically specialized and tightly coupled to the physical process . We're not just talking about generic ports, but fieldbuses, smart sensors, and communication protocols designed to minimize latency and ensure tight delivery times.

Types of real-time systems: hard, soft, and firm

Depending on the severity with which they handle timing errors, STRs are classified into several categories. In a hard real-time system , all deadlines must be met without exception. A single failure can lead to serious consequences or, at the very least, invalidate the outcome.

Typical examples of hard real-time systems include flight control, certain critical medical systems , and electrical infrastructure protection. In these cases, a correct but delayed result is useless; the system must be designed so that, under no foreseeable scenario, will it fail to meet its time limit.

Soft real-time systems allow for occasional delays. The usefulness of the result decreases with the delay, but it can still be usable. This is the case in multimedia or data acquisition applications, where a few lost frames or delayed samples degrade the quality, but the system continues to function.

Between these two extremes lie firm real-time systems . Here, occasional delays are tolerated, but when a response arrives late, it becomes worthless and is discarded. Classic examples include real-time video or telecommunications systems: a frame that arrives late is dropped to maintain synchronization.

Architectures: open/closed and centralized/distributed

Real-time systems can also be classified by their degree of technological openness . Proprietary systems employ closed technologies and protocols, controlled by a single vendor, which can provide good performance but limits interoperability and evolution.

In contrast, open systems use public standards and protocols that facilitate the integration of components from different manufacturers, software reuse, and progressive migration to new platforms.

Another important distinction is between centralized and distributed systems . In a centralized approach, a main node is responsible for coordinating communication and critical processing, while the other nodes act as relatively simple terminals or peripherals.

In a distributed architecture, processing and communication are divided among several intelligent nodes that cooperate more or less autonomously. This allows for scalability, redundancy, and proximity to the physical process, but complicates time synchronization and overall coordination.

Determinism, interruption latency, and responsiveness

Determinism is a core attribute of SRTs: it's the ability to predict with a high degree of probability how long a task will take to start and finish . It's not about being the fastest possible, but about having a known and bounded response time.

Interrupt latency measures the time from when an external interrupt is generated (for example, a sensor reporting an event) until the system begins to handle it. This value is critical because many service requests originate from the physical environment and cannot tolerate arbitrary delays.

Responsiveness focuses on the time it takes for a task to execute once an interrupt has been accepted . It includes factors such as the startup time of the service routine, the duration of associated processing, and the impact of nested interrupts or preemptions.

A quantitative analysis of determinism and responsiveness is typically performed to characterize the system: for example, it might be required that 95% of tasks complete within a certain timeframe . From there, applications running on the RTOS must be designed to avoid falling into the worst-case expected performance range.

System control by processes and reliability

In many advanced real-time systems, the application processes themselves have very fine control over the system . They can explicitly declare their priority, their memory requirements (what part should be cached, what swapping policy is allowed, etc.), and the privileges they require.

Although it may seem like an anarchic model at first glance, it is actually based on well-defined process types and clear restrictions . It is common to establish requirements such as: "maintenance processes must not exceed 3% CPU usage, except during clearly defined low-load windows."

Reliability goes beyond simply being free from occasional failures. A network service provider (NSP) must maintain service quality within agreed-upon limits over extended periods, guaranteeing response times that meet specifications even in the face of reasonable disruptions.

In addition, fault tolerance is required : if a serious problem occurs (hardware failure, human error, external disturbance), the system must preserve as much data and functionality as possible, and degrade its behavior by prioritizing the highest priority critical tasks.

Languages ​​and real-time programming

In practice, many real-time systems (RTS) are embedded and must interact with numerous external components, making concurrent programming and direct device control essential. Modern languages ​​offer primitives for threading, communication, and synchronization, but these must be used with great care in real-time applications, especially in web frameworks and real-time services like Laravel.

Implementation efficiency is key: "pretty" language features can come at a high price in terms of response time, CPU usage, or memory consumption . That's why, in embedded systems, every abstraction is meticulously evaluated before being adopted.

Two languages ​​with a prominent presence in the real-time world are Ada and Java with real-time extensions . Ada was specifically designed to support critical systems and has incorporated improvements to strengthen its capabilities in this area.

In the case of Java, real-time functionalities were added later, with specifications such as the Real-Time Specification for Java and the Real-Time Core Extension, which introduce memory and scheduling models better suited for RTOS.

Real-time operating systems (RTOS)

A real-time operating system (RTOS) is the core software that provides the framework upon which applications with strict deadlines are built. It is required that its services (scheduling, interrupts, synchronization, I/O, etc.) behave predictably.

Unlike a general-purpose operating system, an RTOS is optimized to execute repetitive tasks within very tight timeframes . The goal is not to "do a lot of things" but to ensure that the most important task runs when it should, without surprises.

That's why they tend to be much lighter systems, without graphical flourishes or unnecessary services, with sizes of just a few megabytes and a minimalist design philosophy. Less code means less unexpected latency and fewer points of failure , which fits with real-time requirements.

Historically, RTOSs began development in the 60s and 70s for military, aerospace, and industrial applications. In the following decades, commercial products emerged, such as VxWorks, QNX, and real-time variants of Solaris , widely used in telecommunications, automotive, and embedded systems.

With the rise of IoT in the 2000s and 2010s, lightweight RTOSs like FreeRTOS have become very popular in low-power connected devices. At the same time, real-time POSIX extensions have been proposed to unify interfaces and facilitate software portability.

Today, many RTOSs integrate with artificial intelligence and machine learning techniques to optimize scheduling, predict failures, and adapt control parameters at runtime. All of this, of course, while maintaining a focus on time guarantees.

The RTOS market is worth several billion dollars and is expected to grow steadily in the coming years, driven by medical devices, industrial automation, automotive and critical infrastructure systems.

Requirements that a good RTOS must meet

A modern RTOS must be multitasking and preemptive , so it can preempt lower-priority tasks to immediately execute a more urgent one. Priority-based scheduling is the prevailing paradigm: it always runs the most important task that is ready to execute.

Furthermore, it must provide communication and synchronization mechanisms (queues, semaphores, mutexes, events) designed to minimize unnecessary blocking and avoid phenomena such as priority inversion, applying inheritance protocols or priority capping where appropriate.

It is essential that the timing behavior of the RTOS be well understood : maximum interrupt latencies, context switch times, execution times of synchronization primitives, etc. Without this data, it is impossible to demonstrate that an application meets its deadlines.

Scheduling algorithms: EDF and other models

Task scheduling is one of the cornerstones of real-time systems. Among the most studied algorithms is Earliest Deadline First (EDF) , a dynamically prioritized scheduler that is optimal in many real-time contexts.

EDF prioritizes tasks based on their absolute completion deadline : the task with the nearest deadline has the highest priority at any given time. This ensures, under certain conditions, that if a feasible plan exists that meets all deadlines, EDF will find it.

This algorithm is preventative: if another task with a more pressing deadline arrives during the execution of a task, the system can interrupt the current task and allocate the CPU to the new one. EDF is typically implemented using a priority queue ordered by time remaining until the deadline.

One of the advantages of EDF is that it can achieve near 100% CPU utilization while maintaining deadlines, provided the task set is schedulable. Furthermore, it adapts well to dynamic environments where deadlines or estimated execution times change.

For example, if we have two processes P1 and P2 with different periods and computation times, EDF will always give preference to the instance whose absolute deadline is closer, alternating its execution as new activations arrive and deadlines are recalculated.

However, EDF is not without its drawbacks. In situations with extremely high workloads and frequent changes, it can become complex to implement efficiently, and under certain conditions, starvation problems can arise for tasks with relatively long deadlines.

Other well-known real-time algorithms include Rate Monotonic (RM) and Deadline Monotonic (DM) , which use fixed priorities based on the period or relative timeframe of tasks. Each has its own optimality conditions and preferred application area.

Typical applications of real-time systems

STRs are everywhere. In the process industry , they are used to control and monitor production lines for food, beverages, chemicals, pharmaceuticals, etc., ensuring that key variables are kept within their limits and that the final product has the expected quality.

In transportation, airplanes, trains, cars, and ships rely on real-time navigation, control, and safety systems . These range from ABS braking systems to traction and stability control, as well as rail and maritime traffic management systems.

Modern telecommunications rely on real-time management of information flow in high-speed networks: packet switching, live voice and video transmission, quality of service assurance and latency reduction are tasks where meeting deadlines is essential.

In the defense sector, surveillance, radar, electronic warfare, and cybersecurity systems use real-time platforms to detect and respond to threats in milliseconds or less, protecting critical infrastructure and strategic resources.

In medicine, equipment such as vital signs monitors, ventilators, pacemakers, or infusion pumps operate with real-time software that must react safely to changes in the patient's condition, often with life-or-death consequences if deadlines are missed.

Beyond the digital world, real time can also be observed in biological processes. For example, a seed only germinates when environmental conditions fall within specific ranges and timeframes (humidity, temperature, light). If it were to germinate as soon as it touches the ground, without respecting these timeframes, it would likely not survive. This is a useful metaphor for how a system that does not adapt to its temporal environment can fail.

Looking at the big picture, STRs span telecommunications, multimedia, industrial control, robotics, avionics, railways, automotive, household appliances, scientific experiments, and medical systems . And the list continues to grow as new technologies are developed.

In all these environments , specific real-time communication protocols are needed , such as CAN, Token Bus, TDMA-TTP, adapted CSMA/CD, or Positive Acknowledge or Retransmit (PAR) schemes, which reduce transmission times and provide guarantees about when the data arrives.

Alongside all this, a proprietary real-time software engineering has been refined, with data flow methodologies, data structures and object orientation adapted to represent interruptions, context changes, asynchronous communications and recovery from errors with hard time requirements.

With all of the above, it becomes clearer why real-time systems are now an essential part of modern technological infrastructure: they are responsible for thousands of critical and everyday processes functioning safely, reliably, and without the user having to think about everything that happens "behind the scenes" in fractions of a second.