RTOS, secure virtualization technology for real-time systems, DO-178B and hypervisor for the most demanding embedded operating system applications...

LynuxWorks Patented Technology Speeds Handling of Hardware Events Meeting real-time performance requirements

Patent #5,469,571
"Operating System Architecture using Multiple Priority Light Weight kernel Task-based Interrupt Handling." Granted November 21, 1995

One of the most difficult challenges faced by designers of embedded systems is to meet real-time performance requirements. The interaction of multiple input-output (I/O) devices and system processes gives rise to complexities in timing and can degrade system performance.

The LynxOS real-time operating system incorporates this patented technology.

LynuxWorks™ developed a new way of managing kernel threads and priority processing, and was awarded a patent for its technology, which is part of the LynxOS® real-time operating system. The invention takes a unique approach to handling hardware events in a real-time environment, and allows complex multi-process and multi-threaded applications to respond in a predictable and timely manner.

Processes and priorities

In multi-tasking operating systems, such as UNIX®, each process or program receives a priority which helps determine when it will run. In general, higher priority processes run before lower ones. Once a process is running, it has the full attention of the CPU. The OS changes which process is executing by one of three means:

Yielding The process itself voluntarily gives up the CPU
Preemption The system intervenes to start another process of higher priority
Blocking The process waits on an event, usually I/O, and so gives up the CPU

Yielding occurs when a process is "idle"; with nothing in particular to do, it voluntarily yields execution to the system. This is a primary mechanism in cooperative tasking systems, such as MacOS or Windows 3.1.

Preemptive scheduling allows the OS to determine which process will run next. A preemptive architecture provides for greater concurrency, i.e., more process can appear to run simultaneously. Most versions of UNIX and to a large extent Windows95 are preemptive systems.

Blocking is similar to yielding in that it is voluntary. It is common to systems where the OS governs I/O. Data is not always ready when a process requests it, so rather than looping and wasting CPU time, processes yield the CPU until their data becomes ready.

Hardware versus software priorities

Hardware-based events, specifically interrupts, can have a priority scheme of their own. Data coming from a mouse, for example, generates an interrupt of lower priority than one used to service a hard disk drive; the storing of hard drive data supersedes that of mouse data, which can be preempted.

When the CPU is "handling" an interrupt of a given priority, interrupt requests of a lower priority are ignored or deferred and requests of a higher priority are yielded to automatically—the disk drive interface program ignores the mouse interrupt and the mouse code yields to the disk drive's interrupt request.

Interrupt prioritization differs sharply from its software equivalent in that it is built into the CPU hardware. Moreover, short of disabling the interrupt scheme, hardware interrupt service execution always supersedes software priority-based process execution.

This scheme generally makes good sense; it allows that data associated with an interrupt not be lost just because another program is executing.

Priority inversion

The two priority schemes can interact in unexpected ways, however. Imagine a design in which high priority hardware events supply data to high priority processes, and lower priority hardware events to lower priority processes:

This common, seemingly sensible arrangement can lead to problems when even the highest priority process in the system finds itself constantly interrupted by hardware events. The lower priority process associated with lower-priority I/O may not be running but the low priority interrupt can steal cycles and significantly degrade an application's ability to meet hard real-time deadlines.

LynxOS' unique patented approach

LynxOS is a POSIX®-conformant operating system that implements the UNIX concept of processes, but actually schedules on the basis of POSIX threads of execution which can exist within processes. LynxOS uses this difference to address priority inversion and other scheduling challenges with two solutions unique in the real-time world:

  1. Kernel threads (versus traditional handling):

    Most operating systems make a strong distinction between internal operation and the functioning of user processes. The system "kernel" or core is a large, monolithic program that seldom offers predictable real-time response. Moreover, the OS kernel does not participate in the overall priority scheme (although it governs it). Interrupts are handled by extensions to the kernel called "drivers" which also function outside normal prioritization. Handler code within the drivers processes interrupts and exits quickly so as not to impact system performance. User processes communicate with the kernel and perform most I/O through entry points or calls into the drivers and so I/O ends up being processed outside the user process context.

    The patented LynxOS approach departs from this model by allowing separate POSIX-style threads of execution within the kernel that drivers can use for interrupt handling. LynxOS treats these threads like normal user threads, with software priorities, not interrupt priorities. The driver's interrupt handler, then, does a minimum of work and signals the kernel thread that interrupt-related data is available.

    Such a strategy permits real-time-critical user tasks to execute even during interrupt processing.

  2. Threaded Priority Tracking:

    While kernel threads give the real-time system designer more options for finer control over real-time event processing, they do not alone resolve priority inversion—a kernel thread servicing a low-priority interrupt could still rob performance from an important process (user thread). The key to really making kernel threads participate in the overall system priority scheme is priority tracking.

    Kernel threads begin their existence with a very low priority (usually 0) as created by a driver. When a user thread opens the device, the kernel thread promotes its own priority and "inherits" the priority of the user thread opening the device:

    If another user thread of higher priority opens the device, the kernel thread bumps its priority up to match the other thread; when the I/O is complete the kernel thread returns to the next pending thread's priority level, or to its starting level.

    As the kernel thread goes about servicing any interrupts associated with the device, it does so in step with the user thread consuming (or producing) the data. The interrupt in question, then, can be of high or low priority as needed by the hardware without serious impact to the system software priority scheme. So, by using priority tracking the designer can selectively "flatten" or restructure a processor's interrupt handling architecture so as to serve the application's needs. The patented technology is proprietary to LynuxWorks, and has been incorporated into LynuxWorks' real-time operating systems which complies to UNIX and POSIX standards.


The combination in LynxOS of kernel threads and priority tracking gives developers much finer control over processes scheduling than in a traditional RTOS, such that processes can execute at their assigned priorities regardless of other activities in the system. Kernel threads and priority tracking harmonize the distinct functioning of hardware interrupts and software processes, reducing unforeseen interactions and unpredictable behaviors, and so easing the difficult task of real-time application development.

A LynuxWorks embedded OS is featured in this embedded system application:
Who else uses a LynuxWorks embedded operating system?
Security white papers
Separation Kernels Enable Rapid Development of Trustworthy Systems
By using separation kernel technology and a security abstraction design approach, military system developers can use off-the-shelf components and tools to rapidly build and maintain high security systems. (March 2014)
Coming Together of Safety and (Cyber) Security Changes Demands in RTOS Market
Separation kernels and secure hypervisors will be evermore in demand as safety and certification will be required in more and more applications. Governments are already working on infrastructures deploying this type of technology. (October 2012)
Building in RTOS Support for Safety- & Security-Critical Systems
LynuxWorks explains the differences between safety-critical and security-critical applications and how to meet their demanding requirements with the LynxOS-178 RTOS and the LynxSecure hypervisor. (EE Times Design, August 2011)
Enhancing Application Performance on Multicore Systems
Tips on optimizing a multicore real-time system, including virtualization, avoiding synchronization and concurrency while maximizing application parallelism. (Military Embedded Systems, February 2011)
Hardware Virtualization puts a new spin on Secure Systems
Real-time determinism and military security don't have to be separate realities. A combination of a secure separation kernel and an embedded hypervisor enables whole new levels of system security. (COTS Journal, October 2010)
Using a Separation Kernel to add Military-Grade Security to Legacy Systems
A challenge for the software designer is how to integrate modern military-grade software programs into legacy software designed long before security standards were predominant in system requirements. (VME Critical Systems, Summer 2010)
Virtualization: Keeping Embedded Software safe and Secure in an Unsafe World
A new, secure methodology is needed to separate systems of different security levels which run on shared resources—without compromising the performance of legacy systems. (EE Times, June 2010)
Secure Virtualization Combines Traditional Desktop OSs and Embedded RTOSes in Military Embedded Systems
Advances in software and hardware technologies now make it feasible to use both embedded and desktop operating systems in a secure military system. (Military Embedded Systems, May 2010)
DO-178B Provides Certification Safety net
Developers of commercial avionics software must demonstrate compliance with DO-178 guidelines. The FAA has issued additional guidance for so-called DO-178B Reusable Software Components (RSCs as defined in AC20-148), which allow for reuse of certifications. (COTS Journal, November 2009)
Designing Safety-critical Avionics Software Using open Standards
Safety-critical avionics systems have continually grown more complex and software-intensive. Regulatory authorities and avionics manufacturers have responded with guidance such as DO-178B and RSC to ensure that software performs safely, with controlled development cost. (Boards and Solutions, September 2009)
Two Different Realms: RTOS Support for Safety-critical vs. Security-critical Systems
Safety- and security-critical system functions are evolving simultaneously, with different yet similar requirements. Modern RTOSes are stepping up to meet these needs. (VME and Critical Systems, June 2009)
Virtualization Makes Better use of Open-source OSes and apps
With the introduction of the embedded hypervisor, embedded systems can avoid certain performance or licensing issues inherent to open-source OSes and applications. (EE Times, March 23, 2009)
Secure Virtualization Technology can Extend the life of Legacy Systems
By combining the concept of virtualization and security, one can consolidate multiple legacy systems running on heterogeneous operating systems onto a single host system with high-assurance security. (Military Embedded Systems, January/February 2009)
Virtual Machines: Intel's CPU Extensions Transform Virtualization
Virtualization has traditionally presented its share of design challenges in information-assurance-based systems. But now, Intel's VT-x and VT-d CPU extensions are changing the game and showing potential to become the de facto path to virtualization. (Military Embedded Systems, January 2009)
Separation Kernel for a Secure Real-time Operating System
The technical foundation adopted for the so-called MILS architecture is a separation kernel like LynxSecure, which permits multiple functions to be realised on a common set of physical resources without unwanted mutual interference. (Boards and Solutions Magazine, February 2008)
Advances in Virtualization aid Information Assurance
Advances in the newest Intel® processors are making virtualization much easier to implement in security applications than ever before. (Embedded Computing Design, January 2008)
Protecting our most Vital Systems
Some significant defence programmes are already committed to a new approach to high-threat, high-asset-value systems. Rance DeLong explains MILS. (Components in Electronics, April 2007)
Perspectives: Security and the Separation Kernel
Today's avionics systems are designed to support more than one application, using a partitioned operating system and memory management units to ensure applications have adequate separation. (Avionics Magazine, April 2007)
MILS: An Architecture for Security, Safety, and Real Time
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Technology Magazine, November 2006)
Partitioning Operating Systems Versus Process-based Operating Systems
Partitioning operating systems are the latest buzz, while processes, by contrast, have been around for over 30 years. Both provide memory protection, however, the intent behind them is very different.
DO-178B and the Common Criteria: Future Security Levels
Although there are similarities between the airborne safety-critical requirements in RTCA/DO-178B and the Common Criteria, ISO 14508, compliance with the higher levels of security in the Common Criteria demands meeting additional security requirements. (COTS Journal, April 2006)
Reusing Safety-Critical Software Components
Safety-critical systems often operate together as a single "system-of-systems," making it important that they meet the most stringent and rigorous requirements for safety-criticality. The failure of one module in a system could create other failures or vulnerabilities, or worse yet, failure of the system as a whole. (COTS Journal, August 2005)
Using the Microprocessor MMU for Software Protection in Real-Time Systems
With minimal impact to overall system performance, user tasks and the kernel can be protected from accidental corruption by using multiple protected address spaces.
Improving code Migration and Reuse
The unrelenting growth and integration of embedded controls, information processing, and communications has created a need for systems that provide robust protection for resources and services in the face of serious threats. (Embedded Computing Design, August 2006)
FCS Program Rolls Forward in Formation
A wireless data network, with advanced communications and technologies, links soldiers with 18 new, lightweight manned and unmanned ground vehicles, unmanned aircraft, sensors and weapons—and it's all in one program. (COTS Journal, June 2005)
Secure Operating Systems for Deeply Embedded Devices
As we add more intelligence to our embedded devices, we find that they are becoming increasingly integrated into our information technology infrastructure. Though system security is not a new concept, security-in-depth is a new paradigm developers are now starting to address. (RTC Magazine, September 2004)
LynxSecure Separation Kernel and Embedded Hypervisor LynxOS-SE Embedded RTOS Luminosity Eclipse-based IDE
LynxOS Embedded RTOS RTOS: LynxOS-178 for software certification


SpyKer Embedded-System Trace Tool

Industry Solutions


Industry Standards

Embedded Systems Technology

RTOS Training for Embedded Systems

Training at LynuxWorks

LynuxWorks Support

Embedded Systems

LynxOS RTOS Support

Embedded System Consulting

Contact Us

About LynuxWorks

Press Room

Newsletter and Announcements



Site Map

Board Support Packages (BSPs)

BSP Device Drivers

BSP Targets by Operating System

BSP Targets by Form Factor

Third-party I/O Devices and Hardware

SynergyWorks: LynuxWorks partners

What is SynergyWorks?

Third-party add-ons for LynuxWorks operating systems

Copyright © LynuxWorks™, Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of LynuxWorks is prohibited.