Introduction

An Introduction to Real-Time

About Real-Time?

Reference: Real-time technology

A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed. In other words, the time taken to complete an operation in real-time systems can be expressed in an algebraic equation. Real-time systems, as well as their deadlines, are classified by the consequence of missing a deadline.

Hard

Missing a deadline is a total system failure.

Firm

Infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.

Soft

The usefulness of a result degrades after its deadline, thereby degrading the system's quality of service.

Thus, the goal of a hard real-time system is to ensure that all deadlines are met, but for soft real-time systems the goal becomes meeting a certain subset of deadlines in order to optimize some application specific criteria. The particular criteria optimized depends on the application, but some typical examples include maximizing the number of deadlines met, minimizing the lateness of tasks and maximizing the number of high priority tasks meeting their deadlines.

Hard real-time systems are used when it is imperative that an event is reacted to within a strict deadline. Such strong guarantees are required of systems for which not reacting in a certain interval of time would cause great loss in some manner, especially damaging the surroundings physically or threatening human lives (although the strict definition is simply that missing the deadline constitutes failure of the system). For example, a car engine control system is a hard real-time system because a delayed signal may cause engine failure or damage. Other examples of hard real-time embedded systems include medical systems such as heart pacemakers and industrial process controllers. Hard real-time systems are typically found interacting at a low level with physical hardware, in embedded systems.

About Real-Time Operating Systems

Reference: Real-time operating systems

A real-time operating system (RTOS) is an operating system (OS) intended to serve real-time application requests.

A key characteristic of a RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system. The chief design goal is not high throughput, but rather a guarantee of a soft or hard performance category. A RTOS that can usually or generally meet a deadline is a soft real-time OS, but if it can meet a deadline deterministically it is a hard real-time OS.

A real-time OS has an advanced algorithm for scheduling. Scheduler flexibility enables a wider, computer-system orchestration of process priorities, but a real-time OS is more frequently dedicated to a narrow set of applications. Key factors in a real-time OS are minimal interrupt latency and minimal thread switching latency, but a real-time OS is valued more for how quickly or how predictably it can respond than for the amount of work it can perform in a given period of time.

RedHawk RTOS

Concurrent’s RedHawk Linux is an industry-standard, real-time version of the open source Linux operating system for Intel and AMD-based systems. RedHawk Linux provides the guaranteed performance needed in time-critical and hard real-time environments. RedHawk guarantees that a user-level application can respond to an external event in less than 15 microseconds on most platforms. RedHawk Linux includes all the features of Red Hat Enterprise Linux. The user-level commands, utilities and system administration are compatible with standard Red Hat. RedHawk achieves its superior real-time performance by providing the latest official release from kernel.org that includes key open source patches and kernel enhancements developed by Concurrent. RedHawk user libraries provide access to value-add features that are not part of other Linux offerings. RedHawk is fully compatible with standard Linux userlevel APIs, thus Linux applications written for other Linux distributions will run on RedHawk without modification. RedHawk is the ideal Linux solution for a broad range of deterministic applications such as modeling, simulation, data acquisition, industrial control and medical imaging systems.

SimWB is fully supported on Concurrent iHawk™ multiprocessor platforms running RedHawk Linux. Simulation models are scheduled using RedHawk’s Frequency Based Scheduler (FBS) under control of the iHawk’s Real-Time Clock & Interrupt Module hardware (PCI) card. RedHawk Linux shielding features can also be used to guarantee real-time response by dedicating a CPU to a process. Users can assign models to different system CPUs to achieve parallel execution.

About Hardware-In-the-Loop

Reference: Hardware-in-the-loop

Hardware-in-the-loop (HIL) simulation is a technique that is used in the development and test of complex real-time embedded systems. HIL simulation provides an effective platform by adding the complexity of the plant under control to the test platform. The complexity of the plant under control is included in test and development by adding a mathematical representation of all related dynamic systems. These mathematical representations are referred to as the “plant simulation”. The embedded system to be tested interacts with this plant simulation.

An HIL simulation must include electrical emulation of sensors and actuators. These electrical emulations act as the interface between the plant simulation and the embedded system under test. The value of each electrically emulated sensor is controlled by the plant simulation and is read by the embedded system under test (feedback). Likewise, the embedded system under test implements its control algorithms by outputting actuator control signals. Changes in the control signals result in changes to variable values in the plant simulation.

In many cases, the most effective way to develop an embedded system is to connect the embedded system to the real plant. In other cases, HIL simulation is more efficient. The metric of development and test efficiency is typically a formula that includes the following factors:

• Cost
• Duration
• Safety
• Feasibility

HIL with SimWB

• Multi-core, parallel I/O: Concurrent iHawk multiprocessing systems running SimWB are based on COTS components offering the latest, leading-edge processor, chipset, memory and I/O bus technology. Solutions that use proprietary hardware are slow in comparison to Concurrent’s latest available COTS-based systems. SimWB recognizes and utilizes multiple cores by default and there is no limit on the number of cores than can be used by SimWB. With SimWB, individual I/O processes can be targeted to different system cores and I/O buses for parallel execution, thus allowing the simulation loop to run at faster frame rates. Without the ability to run I/O on different cores, I/O processing becomes serialized thus extending execution time of the simulation loop.
• Independent I/O: In SimWB, all I/O is performed by processes outside of the Simulink models, thus allowing the models to be independent of the intricacies and specific behavior of the I/O devices. This provides flexibility and makes it easy to remap I/O when necessary. In other HIL solutions, I/O is implemented via Simulink S-functions that are embedded within the Simulink model. They are, for all intents and purposes, part of the model.
• No I/O limits: There are no practical limits on SimWB configurations. Concurrent iHawk systems can be configured with thousands of hardware I/O points.