Home
Products
Operating Systems

QNX Neutrino RTOS

Community Portal
Source, upgrades, community forums, and more
Whitepaper
Exactly when do you need an RTOS
Webinar
Embedded Meets Mobility - M2M Considerations and Concepts
Video
QNX helps Kieback & Peter keep it green
Free software evaluation
BSPs and drivers
BSP directory
We're here to help
  1. Overview
  2. Benefits
  3. Technology
  4. Multi-core
  5. POSIX
  6. What's new?

The QNX® Neutrino® RTOS is a full-featured and robust OS that scales down to meet the constrained resource requirements of realtime embedded systems. Its true microkernel design and its modular architecture enable customers to create highly optimized and reliable systems with low total cost of ownership. It offers the embedded industry’s only field-proven, clean strategy for migrating from single-core to multi-core processing.

QNX Neutrino RTOS architecture

QNX Neutrino RTOS architecture diagram

Because every driver, protocol stack, filesystem, and application runs in the safety of memory-protected user space, virtually any component can be automatically restarted if it fails.

True microkernel OS

The QNX Neutrino RTOS (realtime operating system) is so reliable because it is a true microkernel operating system.

Under QNX Neutrino, every driver, protocol stack, filesystem and application runs in the safety of memory-protected user space, outside the kernel. Virtually any component can fail — and be automatically restarted — without affecting other components or the kernel. No other commercial RTOS offers this degree of protection and isolation.

Advances in security

The QNX Neutrino RTOS has innovative security mechanisms designed to help you easily build impenetrable devices. Encrypted filesystems, memory guard pages, and limited root permissions are core features of the operating system that can be used to create secure and reliable devices.

Graphics and HMI technologies

The QNX graphics technologies use hardware layering (pipelines) for combining multiple content sources together into a single image. Display images from video, OpenGL ES, HTML5, and Qt 5 on a single display. Combine those graphics technologies with Neutrino’s support for multi-touch UIs and video capture, to build embedded devices that meet the user interface expectations that have been set by mobile devices, such as smartphones and automotive infotainment systems.

Multicore migration

The QNX Neutrino RTOS has a field-proven strategy for migrating from single-processor to multi-processor embedded environments. Its unique bound multi-processing (BMP) technology takes the risk out of migration by enabling developers to decide exactly where every process and thread will run.

The QNX® Neutrino® RTOS offers great economic and technical advantages thanks to its ability to extract extremely fast, predictable response times from inexpensive embedded hardware.

High reliability with low risk

Since 1980, manufacturers have relied on QNX RTOS technology to power their mission-critical applications — everything from medical instruments and Internet routers to telematics devices, 911 call centers, process control applications, and air traffic control systems.

Small or large, simple or distributed, these systems share an unmatched reputation for operating 24 hours a day, 365 days a year. Time-tested and field-proven, the QNX Neutrino RTOS sets the industry standard for reliability, fault tolerance, and scalability.

Advanced security mechanisms

QNX brings advanced security mechanisms that are built directly into the OS and kernel. With QNX you can build a system that offers the best possible security measures, thanks to:

  • Granular control of system privilege levels – restrict processes’ capabilities to only the elevated privilege level that is necessary for the specific commands, without providing the process with access to the entire system by elevating it to root privilege
  • Encrypted filesystems – the filesystem can be encrypted by dividing it into encryption domains, which can be locked, or unlocked for access
  • Read-only filesystems – protect data using a read-only filesystem that compresses the files in blocks, yet still supports random access
  • Reduced security attack surface – all processes, including drivers, filesystems, etc. execute in user-mode, greatly reducing the ability of compromised processes
  • Heap, Stack, and Memory Protection – heap, stack, and allocated memory blocks are protected by “guard pages” that the microkernel uses to detect and trap stack overflows
  • ASLR – The heap is protected by address space layout randomization (ASLR), which randomizes the stack start address and code locations in executable and libraries, and heap cookies

Reduced power consumption

QNX brings advanced thermal and power management capabilities that are built directly into the OS and kernel, to reduce the power consumed by mobile and powered devices, through:

  • Tickless mode – skip unnecessary clock ticks when system is in an idle state
  • Tolerant timers – timers can have a tolerance for non-realtime timer requirements (e.g. UI response timers)
  • Lazy interrupts – interrupts can have acceptable latencies for non-realtime devices (e.g. keyboard interrupt events)
  • Dynamic Voltage and Frequency Scaling – DVFS for ARM Cortex SoCs

Support for latest mobile graphics techniques

The QNX Neutrino RTOS provides a level of graphical and mobile techniques not offered by any other commercial RTOS.

QNX delivers a compositing windowing system which integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is then rendered into one image that is associated with a display. This allows the designer to use the most appropriate graphics technology that corresponds with the image, be it video, Open GL ES, HTML5, or Qt 5.

  • Multi touch input control – QNX supports multi-touch graphical displays that are popular in mobile devices
  • Video capture – frames can be captured from a video source and displayed using the compositing windowing system
  • OpenWF Display (WFD) API – driver architecture based on the WFD APIs
  • Multiple source graphics – graphics subsystem can render images from multiple sources onto a single display

Connect to other devices using the latest techniques

QNX Neutrino RTOS provides support for the latest in wired and wireless networking, and connectivity options, making the job of the designer simpler and faster due to:

  • USB 3.0 – support for USB 3.0 is included for the latest OMAP and x86 hardware
  • USB device – support device class drivers for CDC ACM (serial), USB Mass Storage and CDC_NCM (Network)
  • USB On-The-Go (OTG) Support – USB OTG systems can drop the hosting role and act as normal USB devices when attached to another host

Low BOM cost

The QNX Neutrino RTOS is the perfect OS for reducing the per-unit costs of embedded hardware. It can offer the best possible performance, even on inexpensive hardware, thanks to:

  • True realtime OS design – predictable response times and extremely fast interrupt latencies and context switches
  • Microkernel architecture – robust, self-healing systems
  • Adaptive partitioning – optimal use of all available CPU capacity for high performance with a small memory footprint

Self-healing systems

The QNX Neutrino RTOS provides a level of fault containment and recovery offered by no other commercial RTOS.

Its microkernel architecture has every driver, protocol stack, filesystem and application run outside the kernel, in the safety of memory-protected user space. Virtually any component can fail and be automatically restarted without affecting other components or the kernel.

Scale from small to large

The same RTOS, tools, APIs, and source code are used for developing and implementing systems to meet all manner of requirements for single-processor and multi-processor systems, large and small.

Guaranteed system resources

QNX adaptive partitioning technololgy can guarantee system resources for all applications as needed. Under normal operating conditions it allows applications to use all available CPU cycles, but during overload conditions, it enforces hard resource guarantees to ensure that all applications receive their budgeted share of resources.

Extensive board support

The QNX Neutrino RTOS supports a broad range of x86, PowerPC, ARM, MIPS and SH-4 platforms.

The resource manager framework, which, unlike conventional drivers, runs in memory-protected user space, simplifies driver development for custom hardware.

Efficient product development

The QNX Neutrino RTOS enables rapid and efficient product development in a number of ways:

  • The microkernel architecture facilitates bug identification and resolution, and enables safe and rapid component upgrades without costly downtimes or system outages
  • Just one OS and one set of binaries can target single-processor devices, SMP systems, or processor clusters
  • Open-source UNIX, Linux, and other code can be ported with a simple recompile because QNX Neutrino is engineered to the POSIX standard (1003.1-2001 POSIX.1)
  • Standard POSIX APIs not only let developers easily reuse application code but also provide a familiar development environment
  • Development teams can reuse code and reduce their verification efforts thanks to field-tested binaries — drivers, applications, custom OS services – which can be implemented across entire product lines
  • Out-of-the-box support for a wide range of networking protocols and flash filesystems, and a built-in high availability solution reduce overall development work

The QNX® Neutrino® RTOS is a full-featured and robust OS with a number of unique technological features that set it apart from all other competitive products.

  1. Tech overview
  2. Security
  3. Realtime
  4. Microkernel
  5. Partitioning
  6. High availability            
  7. Networking
  8. Distributed processing
  9. Filesystems
  10. PPS
  11. Fastboot                  
  12. Power & Thermal Management
  13. Graphics

Realtime

The QNX Neutrino RTOS provides deterministic response times at the application level and in all subsystems. Thread priority inheritance eliminates priority inversion problems.

Self-healing systems

Thanks to the microkernel architecture of the QNX Neutrino RTOS, virtually any component — even a low-level driver — can fail without damaging the kernel or other components. What's more, failed components can be restarted quickly and intelligently.

Adaptive partitioning

With the QNX Neutrino RTOS, spare CPU capacity is used when available. If resources are constrained, processes get their budgeted share. If, however, a system has spare cycles, processes can exceed their budget limits.

High availability

If a device driver, protocol stack, or application experiences a problem, it does not take other components down with it. The QNX Neutrino RTOS high availability manager can terminate and restore the faulting component in isolation — often in just a few milliseconds without a reboot.

Networking

Supported networking technologies include IPv4, IPv6, IPSec, FTP, HTTP, SSH and Telnet. Unique transparent distributed processing enables an application to access resources on any node in a network for seamless peer-to-peer resource sharing.

Protected & encrypted filesystems

QNX filesystems execute outside the microkernel in memory-protected user space. Developers can start, stop, or upgrade filesystems on the fly without having to reboot. Multiple filesystems can run concurrently on the same target and even work in concert to extend one another's capabilities. Filesystems can be marked as read-only, compressing the files in blocks while still supporting random access. Filesystems may also be encrypted and subdivided into encryption domains, rendering the files inaccessible until the domain is “unlocked”, thus providing further barriers to intrusion and significantly improved security and hardening of the filesystem.

Portability

Extensive support for POSIX standards facilitates application portability and rapid migration from Linux, UNIX, and other open source programs.

Runtime support and BSPs for popular chipsets, including ARM, MIPS, PowerPC and x86, lets designers select the best hardware platform for their embedded system, and then quickly get their systems up and running.

Power management

The QNX Neutrino RTOS offers several power management strategies to help developers meet the stringent power and heat requirements of many embedded systems. These include:

  • Tickless mode – optimize clock ticks when system is in idle state
  • Tolerant timers – for non-realtime timer requirements (e.g. UI response timers)
  • Lazy interrupts – for non-realtime interrupts (e.g. keyboard interrupt event)
  • Dynamic Voltage and Frequency Scaling (DVFS) – DVFS for ARM Cortex SoCs

Security

To address the ever-increasing security threats facing embedded systems, whether they are large distributed systems or small, isolated industrial controllers, QNX has advanced security mechanisms built directly into the QNX Neutrino RTOS that protect the device from malicious attacks. These can be used to ensure that all processes, including drivers and filesystems, execute in user-mode, greatly reducing the ability of compromised processes. Further, it is possible to divide the filesystem into encrypted domains, as well as to randomize the address space layout for further protection against malicious intent.

The security attack surface of the system can be further reduced by utilizing a unique ability to control settings that govern and protect which operations a process can perform, with granularity down to the system-call level. As a result, embedded developers no longer have to give processes root permissions and access to the entire system in order to gain access to necessary system resources.

Graphics

With the QNX Neutrino RTOS, developers can build graphically rich, compelling user interfaces (UIs) using built-in, high-performance OpenGL ES based transitions, support multi-touch displays, and render images from Qt, HTML5, video, and other technologies through a single compositing windowing system. This system integrates multiple graphics and UI technologies into a single scene.

Integrated tool chain

The QNX® Momentics® Tool Suite offers all the development and debugging features commonly found in other Eclipse-based IDEs, plus unique QNX capabilities, such as multicore profiling and an instrumented kernel.

Eclipse provides well-defined interfaces to ensure that tools work together seamlessly. Developers also benefit from an open, extensible platform for tool integration supported by a large and rapidly growing community of tool vendors and developers. They can plug in third-party tools, or build their own plug-ins using the industry-standard Eclipse framework.

QNX has advanced security mechanisms that are built directly into the QNX Neutrino RTOS that protect the device from malicious attacks. These can be used to encrypt the filesystem and reduce the attack surface of the system by restricting the privilege levels for elevated processes and by randomizing the address space layout.

Access control lists

Some filesystems, such as the Power-Safe (fs-qnx6.so) filesystem, extend file permissions with Access Control Lists (ACLs), which are based on the withdrawn IEEE POSIX 1003.1e and 1003.2c draft standards. ACLs extend the traditional permissions as set with chmod, providing finer control over who has access to files and directories within the system.

With the traditional file permissions as set with chmod, there are few choices for providing special access to a file:

  • Adding that person to the owning group
  • Creating a supplemental group that includes that person and the owner of the file
  • Loosening the permissions for "others"

Keeping track of the users in each group can become complicated, and allowing "others" additional permissions can make the system less secure. Access Control Lists extend file permissions, giving you finer control over who has access to files.

ACLs allow the administrators to specifically add, then view, users that can be permitted specific levels of access beyond simply "users", "groups", and "others". The permissions for these classifications can also contain specific user names at the corresponding access level.

Granular control of system privilege levels

No longer is it necessary to elevate the privilege of a process to root when that process needs to access system resources. The QNX Neutrino RTOS supports process-manager settings that govern permitted operations for a particular process.

A privileged process can obtain these abilities before dropping root privileges, which lets it retain some functionality that historically would have been restricted to root. Furthermore, these process-manager settings can be locked, meaning that even root users can't carry out certain actions that they might historically have been able to. This change significantly reduces the attack surface of the system, even when dealing with a root process.

Reduced attack surface

The attack surface of the system is further reduced by the inherent characteristic that all processes including drivers and filesystems, execute in user-mode, greatly reducing the ability of compromised processes. Combined with the granular control of system privilege levels, any compromised process will be significantly restricted in its ability to affect harm or gain elevated access.

Heap and stack protection, and ASLR

The heap is protected by address space layout randomization (ASLR), which randomizes the stack start address and code locations in executable and libraries, and heap cookies. Stack guard pages protect against stack overflows. At the end of each virtual stack is a guard page that the microkernel uses to detect stack overflows. If a program writes to an address within the guard page, the microkernel detects the error and sends the process a SIGSEGV signal.

In addition, malloc has been modified to place guard regions at both ends of allocated memory blocks in order to trap rogue code and prevent malicious intent.

Encrypted filesystems

All or part of the contents of a QNX6FS power-safe filesystem can be encrypted by dividing it into encryption domains.

A domain can contain any number of files or directories. After a domain has been assigned to a directory, all files created within that directory are encrypted and inherit that same domain. By default, assigning a domain key to a directory with existing files or directories doesn't introduce encryption to those files.

During operation, files that are assigned to a domain are encrypted, and the files' contents are available only when the associated domain is unlocked. When a domain is unlocked, all the files and directories under that domain are unlocked as well, and are therefore accessible (as per basic file permissions). When a domain is locked, any access to files belonging to that domain is denied.

The encrypted filesystem uses:

  • AES-256 in CBC mode
  • AES-256 in XTS mode

Encryption keys can be private and randomly generated on a per-file or per-domain level, or they can be optionally public, and managed external to the filesystem. There is a master system key which is private and randomly generated only once, and is used to encrypt all the domain master keys.

With its pre-emptible microkernel and priority-based preemptive scheduler, the QNX Neutrino RTOS delivers response times that are both fast and highly predictable. High-priority threads can meet their deadlines on time, every time, even under heavy system load.

A comprehensive, integrated set of technologies supports the realtime reliability and performance of the QNX Neutrino RTOS, including:

  • Fast interrupt latencies and context switches that help squeeze the fastest possible response time from embedded hardware
  • Priority inheritance to eliminate priority inversion
  • Simplified modeling of realtime activities through synchronous message passing
  • Nested interrupts and a fixed upper bound on interrupt latency to ensure that high-priority interrupts are handled first, within a predictable timeframe

The QNX Neutrino RTOS is a true microkernel operating system and, as such, the microkernel includes only the most fundamental services, such as signals, timers, and schedulers. All other components — filesystems, drivers, protocol stacks, and applications — run in the safety of memory-protected user space. Fault resilience is built right in.

All OS components communicate via a single, well-defined messaging layer. This messaging layer forms a virtual "software bus" that permits the addition — plug in — and removal of software components at any time. Messages flow transparently across processor boundaries, providing seamless access to any resource, anywhere on the network.

QNX Neutrino RTOS microkernel

QNX distributed connectivity

The QNX Neutrino RTOS microkernel isolates processes in memory-protected user space.

Self-healing systems

The principles behind the QNX microkernel architecture have been proven through more than three decades of implementations in the most exacting environments:

  • Virtually any component, even a low-level driver, can fail without damaging the kernel or other components
  • If a component fails, the OS can cleanly terminate it and reclaim any resources it was using — no need to reboot
  • Failed components can be restarted quickly and intelligently, using the operating system's high availability manager

Simplified design

Inherently modular, the QNX Neutrino RTOS microkernel architecture simplifies the design of modular and easy-to-maintain systems. Distributed messaging:

  • Provides a consistent form of inter-process communication (IPC)
  • Enables scalable, distributed, fault-resilient systems that can transparently share resources across almost any chassis, fabric, or interconnect
  • Automatically synchronizes the execution of cooperating components
  • Eliminates the need to track complicated queuing behavior
  • Partitions complex applications into cleanly separated building blocks, which can be individually developed and tested
  • Allows system services to be accessed via simple, industry-standard POSIX function calls — there is no need to manage a complex messaging layer

QNX adaptive partitioning is a simple, reliable solution for processor-intensive systems where task starvation is not an option. It ensures that critical processes are never starved of resources and always meet realtime deadlines.

Adaptive partitioning eliminates the over-engineering required by fixed-partitioning designs, which waste unused cycles and force designers to use more-expensive CPUs. It thus both improves product time to market and does away with the complex task-starvation problems that typically arise during a project’s integration phase.

QNX Neutrino RTOS adaptive partitioning

QNX distributed connectivity

QNX adaptive partitioning offers applications unused CPU capacity while guaranteeing required CPU cycles to critical processes.

A unique approach

QNX adaptive partitioning is a unique partitioning approach. It provides minimum CPU time guarantees to partitions (sets of processes or threads), while allowing partitions to exceed their time budgets when spare processing cycles are available.

The system designer can reserve a percentage of processing resources for a specific partition. Under normal operating conditions, partitions can use whatever CPU cycles are available. However, during an overload when more computation is required than the system can sustain over time, the QNX adaptive partitioning scheduler enforces limits on the CPU cycles that each partition is permitted to consume, guaranteeing that the minimum required CPU resources are always available for specified processes.

System efficiency

By its very nature, QNX adaptive partitioning is more efficient than fixed partitioning.

  • Fixed partitioning designs, such as ARINC 653, are inherently inefficient. Spare CPU capacity in a partition cannot be temporarily borrowed by other partitions, so CPU budgets must be set in advance to anticipate peak demand.
  • With QNX adaptive partitioning, spare CPU capacity is used when it is available. Processes can exceed their budget limits if the overall system has available cycles. When CPU resources are constrained, budgets are enforced and every part of the system gets its fair share.

Improved system security

QNX adaptive partitioning fundamentally improves system security:

  • Developers and integrators can isolate downloadable content to secure partitions, thwarting denial-of-service (DoS) attacks
  • Malicious or unvalidated software that monopolizes system resources can’t starve critical functions of CPU time

Self-healing systems

QNX adaptive partitioning helps create fault tolerant and self-healing systems:

  • Guaranteed CPU cycles for error detection and system-recovery operations ensures rapid system recovery
  • Operators and administrators with access to the user interface — a console or a remote — can always determine the system state, regardless of processor load

Guaranteed realtime deadlines

QNX adaptive partitioning technology provides flexible scheduling while maintaining real time determinism:

  • Available CPU cycles are dynamically assigned from partitions that aren’t busy to partitions that can benefit from extra processing time
  • Available CPU cycles always go to the highest priority, ready-to-run thread in the system
  • Developers can designate critical threads as guaranteed to run regardless of partition budget and system load

Guaranteed event responses

QNX adaptive partitioning helps system designers guarantee responses to events without complex manipulation of process and thread priorities:

  • A minimum CPU budget allocated to a device’s user interface can guarantee that it rapidly and invariably responds to user actions, such as a button push or voice command
  • CPU cycle guarantees for media players can ensure that they always get the cycles they need to deliver smooth, continuous playback — eliminating skipping or pauses in media playback

Efficient product development

QNX adaptive partitioning reduces the time and effort needed to integrate and debug embedded systems:

  • Developers can set aside CPU budgets for individual parts of the system to ensure fair sharing of system resources, avoiding the need to normalize priority schemes across the system, which is time consuming and error prone
  • Developers and integrators can monitor and reset budgets as determined by their projects’ unique requirements — all without writing or even recompiling code

Simplified integration

No extra work is required to integrate QNX adaptive partitioning technology into a system.

  • Adaptive partitioning can be added to a system with minimal effort — no recoding (or even recompiling) of applications is required
  • Partition parameters are configured, not programmed: no code changes are necessary to implement CPU guarantees for specified processes
The QNX Neutrino RTOS implements two simple principles to ensure high availability:
  • Fault isolation — segregate failures in well-defined software components to minimize their impact on overall system availability.
  • Recovery — detect faults and automate recovery without system reboots to minimize mean time to repair (MTTR)

These principles are embodied in the QNX Neutrino RTOS microkernel architecture, which ensures that a component failure is constrained to that component, and the High Availability Framework, which provides the infrastructure for fault detection and recovery.

In addition, the QNX Neutrino RTOS supports high availability through:

  • Redundant services — transparent distributed processing (network distributed architecture) enables rapid building of redundant services
  • Guaranteed CPU resources — adaptive partitioning guarantees minimal CPU time and memory to critical software components, ensuring that they have the resources they need under all conditions

Fault isolation — the microkernel

The QNX RTOS microkernel architecture isolates faults, ensuring that a component failure is constrained to that component:

  • Full MMU-based memory protection for all components ensures that a failure in one component cannot corrupt other components or the OS kernel
  • Device drivers and system services, such as networking and filesystems, can be restarted automatically without affecting other software components
  • POSIX process model enforces clear resource ownership and automatic cleanup by QNX Neutrino when processes terminate abnormally

Recovery — the High Availability Framework

The QNX High Availability Framework provides a reliable software infrastructure on which to build highly effective high availability systems. As well as supporting hardware-oriented high availability solutions, it provides developers with tools to isolate and even repair software faults before they domino through a system.

With the High Availability framework, developers can quickly construct custom failure recovery scenarios and design systems to recover quickly and transparently.

Self-healing systems

The High Availability Framework enables developers to build and implement self-healing systems:

  • Automatic restart of failed processes — without a system rebooting
  • Automatic recovery of inter-process communications following process failures
  • Customized failure recovery actions, where applications identify failure conditions and perform specified activities to mitigate consequences and speed recovery

High Availability Manager

The High Availability Manager (HAM) is a "smart watchdog" — a highly resilient manager process that monitors a system and performs multi-stage recovery whenever system services or processes fail or no longer respond.

As a self-monitoring manager, the HAM is resilient to internal failures. If, for whatever reason, the HAM itself is stopped abnormally, it can immediately and completely reconstruct its own state by handing over to a mirror process.

The High Availability Framework includes a HAM API library, which offers a simple, thread-safe mechanism for communicating with the HAM, and a client recovery library, which provides a drop-in enhancement solution for many standard libc I/O operations.

QNX Neutrino RTOS networking support includes an ever-expanding list of protocols, including:

  • IPv4/IPv6 (based on NetBSD 4.0)
  • SNMP v1/v2/v3
  • L2 VLAN, QoS, STP
  • 802.11a/b/g, WPA, WPA2, WEP

Security protocol suite support includes:

  • IPSec, IKE, SSL, SSH, NAT, IP filtering
  • Open cryptography API
  • hardware acceleration support for packet handling

TCP/IP Stack RFC Support

QNX Software Systems is continuously expanding its networking support. If you cannot find the protocols you need, please contact us for the very latest information.

QNX’s Transparent Distributed Processing (TDP) technology enables seamless peer-to-peer resource sharing on a network. It is ideal for:

  • "In the box" networking equipment, where it can be used over backplanes and interconnection technologies
  • Industrial control systems applications, such as distributed monitoring, management, and control

Optimal use of shared resources

TDP extends the QNX message passing architecture across virtually any network interconnection technology. It provides a framework for the dynamic interconnection of hardware and software resources (message queues, filesystems, services, databases) located on remote nodes, using standard messages.

Resources have true location independence: software on any node can access any published resource.

Transparent distributed processing

QNX composition manager

QNX transparent distributed processing allows an application to access resources on any node in the network, across virtually any network interconnection technology.

Location independence

Complete location independence is supported by a central directory of global naming and location services:

  • Registration by multiple cards for the same service
  • Automatic supervision and notification of available resources
  • Flexible deployment and partitioning of applications at runtime

Built-in redundancy and load balancing

Redundancy and load balancing are a fundamental quality of systems implementing TDP:

  • There are inherent supports for multiple links between CPUs, so if one link fails, data is automatically re-routed over the remaining links, without loss of service
  • Network traffic can be load-balanced over all available links, resulting in significantly higher throughput
  • Applications can specify a preferred node for data, but if a failure occurs on that node, the data is transparently load balanced over the remaining functioning nodes

Support for various transports

Messaging for TDP operates above the transport layer. It works equally well across LANs, backplanes, proprietary switch fabrics, vehicle buses such as CAN and MOST, and even the Internet.

Efficient product development

TDP saves time and costs associated with custom development and incremental hardware. TDP replaces the traditional custom — and cumbersome — messaging infrastructures required to enable inter-process communications. No special coding is needed to make applications and servers instantly network distributed:

  • No additional network code is required
  • Processes running on a single CPU will continue to communicate with each other even if they are subsequently distributed among multiple CPUs, allowing developers to extend resources to networked nodes and simplify the development of multi-node systems
  • Developers can create robust and fault-tolerant systems that offer on-demand access to resources on multiple CPUs, and if a CPU is not available, a similar resource can be transparently accessed on another CPU — delivering built-in redundancy and load balancing
  • When debugging, developers can query and collect remote data via a single connection to multiple cards, ensuring that data can be accessed even in the event of a broken connection

QNX filesystems are robust, portable and efficient.

  • Execute outside the microkernel, in memory-protected user space, and start, stop, or upgrade filesystems on the fly, without having to reboot
  • Accessible through simple POSIX / C API calls: open(), read(), write(), close()
  • Run concurrently on the same target, and even work in concert to extend one another's capabilities

QNX pathname space

QNX filesystems all work inside the QNX pathname space. This pathname space allows QNX systems to seamlessly access filesystems on any computer in a network. QNX systems do not even require a hard drive or a flash drive to boot. They can be designed to boot from RAM, from another machine in a network, or from a flash drive offering read-only access.

File systems at a glance

Embedded
Disk
Network
Other

Flash Devices

NOR Flash

NAND Flash

RAM
Temporary storage


POSIX – QNX Filesystem

Ext2 - Linux

FAT 12, 16, 32 – Windows/DOS

NTFS (read only) - Windows

ISO9660, Joliet – CD-ROM Devices

HFS+ (read only) - Apple Mac OSX

UDF - CDs and DVDs

NFS
Unix connectivity

CIFS
Microsoft connectivity


Compression

Add compression / decompression to any file system

Encryption

Encryption can be applied to a QNX6FS file system


Embedded filesystems — NOR and NAND flash

QNX flash filesystem technology delivers reliability at the filesystem level:

  • Read/write persistent storage resists data corruption from an unexpected reset or a power loss.
  • Wear-level capability increases the life span of flash parts.
Embedded Transaction Filesystem (ETFS) structure
Transaction-based power-safe NAND filesystem structure

ETFS is a power-safe filesystem composed entirely of transactions.

Performance

QNX NOR and NAND filesystem performance features include:

  • Background reclaim, which concurrently performs background garbage collection to reclaim unused space, mitigating potential I/O delays to find and erase blocks and sectors
  • RAM filesystem for caching and temporary files
  • Compression support to optimize use of flash

POSIX, ISO C file semantics, and tools

QNX NOR and NAND filesystem supports:

  • Standard file stream operations
  • Dynamic creation and manipulation of files and directories
  • Symbolic names, long file names, and permissions
  • Raw flash can be read and written directly for reprogramming boot loaders via standard POSIX command line tools such as cp and dd

NOR flash devices

NOR flash devices are supported with the QNX Flash Filesystem version 3 (FFSv3).

Fault recovery

Updates to metadata are handled in carefully executed sequences. This behavior allows for high filesystem integrity even after power-loss.

After a reset or power-on, the filesystem is scanned, and data integrity is restored wherever possible.

Bad sector handling

Sectors with errors are recorded and transparently avoided.

NAND flash devices

NAND flash devices are supported with Embedded Transaction Filesystem (ETFS) technology.

Resist power failure corruptions

Atomic transactions ensure integrity of file and directory operations, and resist corruptions caused power failures.

Block integrity

The QNX filesystem ensures the quality for all blocks on NAND flash devices:

  • Factory-marked bad blocks are reserved and unused
  • Blocks are marked for refresh before hitting the normal read degradation limit, avoiding possible ECC errors and the need to recover data

Automatic file de-fragmentation

The QNX filesystem employs several strategies to prevent data fragmentation:

  • Write buffering reduces fragmentation by consolidating small write transactions before they are written to NAND
  • Background de-fragmentation runs automatically, but is automatically pre-empted by user activity

Bulk copy support

Filesystem data is not block-specific. NAND devices can be bulk copied using a separate flash program.

The QNX Neutrino RTOS offers several fastboot strategies to help developers meet the stringent fast boot requirements of many embedded systems. These include:
  • BIOS-less boot — customize the boot sequence to bypass the BIOS
  • Microkernel — easily start applications before starting drivers
  • Instant Device Activation (IDA) — a minidriver starts applications needed to meet early readiness, then hands control over to a standard boot process

BIOS-less boot

With the QNX Neutrino RTOS, developers can easily replace standard BIOS with customised early initialisation of periphereals. Customized early initialisation can eliminate time-consuming tasks (such as initializing keyboards or USB devices) that may be superflous in embedded systems.

Most x86 systems place device drivers — which are responsible for device initialization — in the BIOS. In the QNX Neutrino RTOS these drivers are outside the BIOS. This architecture allows developers to easily select which drivers and, therefore, which devices are initialized and when, removing unneeded initializations and deferring others until after the boot. In brief, work is removed or deferred to achieve the fastest possible boot times.

When developing BIOS-less boots, developers can hard-code custom interrupt assignments so that they are known at compile time. They can design their systems to boot from a partial boot image boot on a linearly mapped device, such as a flash or EEPROM. This partial image can be optimized for fast boot times, but include a driver to access storage, such as a hard drive, NAND flash device or USB device with a full boot image.

Microkernel

The QNX Neutrino RTOS’s unique microkernel architecture makes it easy to optimize component and application availability following a boot to change the startup sequence to take advantage of any idle time. The system architect has complete control of what starts when. For example, developers could configure a system to play a jingle almost instantly after power-up by loading the audio driver and a small, throw-away playback utility before most other drivers.

Instant Device Activation

QNX Instant Device Activation enables embedded systems to meet critical early readiness requirements, such as receiving and responding to CAN bus messages, after a cold power up and boot.

Instant Device Activation (IDA) boot process

QNX composition manager

Instant Device Activation brings a minidriver up before the kernel initialization to meet early boot requirements, then hands control over to the OS.

Critical functionality

IDA uses small, highly efficient device drivers that start executing before the OS kernel is initialized. This minimal driver layer can:

  • Respond to external events, meet critical response times, access hardware, and store data for the full driver
  • Either continue to run or exit seamlessly once control has been assumed by the full driver process, all without blackout times or data loss

Reduced hardware costs

IDA technology can be used to reduce hardware costs, because it:
  • Manages data from buses, such as MOST and CAN, without the addition of costly hardware, such as external power modules
  • Boots from a cold or low-power state without auxiliary communications processors to meet timing and response requirements

Application customization

Designed to facilitate application customizations, IDA technology includes the full source code and documentation for easy configuration. Designers and integrators can:

  • Adapt standard polling intervals to meet device timing requirements
  • Define the amount of data stored in the IDA buffer
  • Determine the optimal driver transition model, by specifying when the full driver process takes over

Persistent/Publish-Subscribe (PPS) is a small, efficient, and flexible service introduced by QNX Software Systems specifically for use in embedded systems. PPS allows developers to build loosely connected systems based on asynchronous publications and notifications. Software components can easily communicate with each other, even when they are created using differing programming languages or environments. Features include:

  • Support for one-to-one, one-to-many, and many-to-one relationships between publishers and subscribers
  • Interface based on object names, which allows plug-ins and substitutable components
  • Compatibility with any programming language, including C, C++, Java, Flash, Python, Perl, bash, or ksh
  • Object attributes that can be persisted across a system reset without requiring additional logic
  • Support for on-demand publishing (pull instead of push)

The QNX Neutrino RTOS offers several power management strategies to help developers meet the stringent power and heat requirements of many embedded systems. These include:

Tickless mode

Power savings can be achieved by having timers set to help the system sleep for longer intervals. The kernel can reduce power consumption by running in tickless mode, although this is a bit of a misnomer. The system still has clock ticks, and everything runs as normal unless the system is idle. Only when the system goes completely idle does the kernel "turn off" clock ticks. In reality what it does is slow down the clock so that the next tick interrupt occurs just after the next active timer is set to fire.

Tickless mode must be enabled via the system startup code, and is only active when the entire system is idle.

Tolerant timers

In order to help the kernel save power, timers that don't require real-time precision can be assigned a tolerance value. The classic example of this is a UI response timer set in seconds.  The kernel then uses the expiry time plus the tolerance to optimize processing of timers and interrupts.

When setting up a timer, you can specify how much tolerance the kernel is allowed when scheduling your thread after the timer fires. Setting timer tolerance allows the system to sleep longer and then do more work when it does wake up as multiple timers can be fired when the kernel awakens.

Lazy interrupts

In order to help the kernel save power, you can make an interrupt "lazy" by specifying an acceptable latency for it. Before putting the CPU to sleep, the kernel checks all the interrupt latency values and sees if it can guarantee that another interrupt (e.g., for a timer tick) will occur before the latency period has expired. If it can prove that another interrupt will occur first, the kernel masks the lazy interrupt before going to sleep. When any interrupt is received by the CPU, all the lazily masked interrupts are unmasked.

In order to save power, interrupts that don't require realtime responses can be assigned a latency value. The classic example of this is a keyboard interrupt event. The kernel will mask this interrupt if it can guarantee that another interrupt will occur within the latency window. When any interrupt is received, the kernel then also processes interrupts that may have occurred for lazily masked interrupts.

Dynamic Voltage Frequency Scaling

Dynamic Voltage Frequency Scaling (DVFS) allows ARM Cortex SoCs to run at various power levels based on CPU load and/or temperature. This system-level power management could be beneficial in saving power during low CPU loads and in ensuring that the chip’s thermal limits are never reached.

The DVFS driver manages Dynamic Voltage Frequency Scaling for a system on a chip (Soc) This driver provides some level of power and thermal management from a system level. The driver is responsible for the following tasks:

  • Monitoring the CPU load (MPU load)
  • Monitoring the SoC temperature (if possible)
  • Scaling the voltage and the frequency of MPU, based on the reported CPU load and/or SoC temperature
  • Providing an API for applications to send commands or read various information

The QNX Neutrino RTOS provides a level of graphical and mobile techniques offered by no other commercial RTOS.

QNX delivers a compositing windowing system which integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is then rendered into one image that is associated with a display. This allows the designer to use the most appropriate graphics technology that corresponds with the image, be it video, Open GL ES, HTML5, or Qt 5.

Screen: multiple graphical inputs

QNX Neutrino has been updated with a new graphics compositing windowing system called Screen, which integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is then rendered into one image that is associated with a display. This allows the designer to use the most appropriate graphics technology that corresponds with the image.

Screen: A composited windowing system

QNX Application packaging diagram

Screen enables developers to create separate windows for the output of each rendering technology (HTML5, Qt, Video, or OpenGL ES) so that each window can be transformed - scaling, translation, rotation, alpha blending - to build the final scene for display.

Unlike traditional windowing systems that arbitrate access to a single buffer associated with a display, this compositing windowing system provides the means for applications to render off-screen.

Rendering to off-screen buffers allows the manipulation of window contents without having to involve the applications that are doing the rendering. Windows can be moved around, zoomed in, zoomed out, rotated, or have transparency effects applied to them, all without requiring the application to redraw or even be aware that such effects are taking place.

Screen is responsible for:

  • Running all drivers (input, display, OpenGL ES)
  • Allocating memory needed by application windows
  • Displaying content when rendering completes

Screen integrates multiple graphics and user interface (UI) technologies into a single scene. This scene is rendered into one image that is associated with a display.

Screen: A composited windowing system

QNX Application packaging diagram

Screen integrates multiple graphics and user interface (UI) technologies into a single scene.

The main responsibility of Screen is to combine all visible window buffers into one final image that is displayed. This responsibility is handled by the Composition Manager and is achieved using several classes of hardware. The Composition Manager can be configured to use available compositing hardware in a way that best meets the needs of a particular system.

Screen has a plug-in architecture that includes hardware-specific compositing modules and a module for OpenGL for Embedded Systems (OpenGL ES).

Screen uses GPU-accelerated operations to optimally build the final scene. You may resort to using software rendering if your hardware cannot satisfy the requests. The graphics drivers and display controllers that run within Screen are based on the OpenWF Display (WFD) API.

Multi touch input control

QNX supports multi-touch graphical displays that are in wide use. The Input Events Library has been extended to support multi-touch screens. The Gestures Library provides gesture recognizers to detect gestures through touch events that occur when you place one or more fingers on a touch screen.

What are gestures?

A gesture is an interaction between users and your application through a touch screen. A composite (also called transform or continuous) gesture is one that may send multiple notifications to the application as you continue to touch or move your fingers on the screen. Discrete gestures send only a single notification to the application. The supported gestures are:

  • Composite
  • Swipe
  • Pinch
  • Rotate
  • Two-finger
  • Pan
  • Discrete
  • Tap
  • Double tap
  • Triple tap
  • Long press
  • Press and tap
  • Two-finger tap

If it is necessary to detect a gesture that isn't supported by the Gestures Library, new gesture recognizers can be added. Touch events are events generated by the touch controller. In the Gestures Library, touch events contain various types of information about the touch event, such as the type of touch event (touch, move, or release), the timestamp of the event, the coordinates of the touch, and so on.

Video capture

The video capture framework gives applications the ability to capture frames from a video input source and display them using the Screen compositing windowing system.

Window groupings

A window group is used to organize windows who share properties and a context. Properties can be queried and set based on the group type. These properties when set, are then applied across each window in the group. Properties that windows can share when in the same group include:

  • Idle time
  • Keyboard focus
  • Multi-touch focus

All windows in the same group also share the same context.

More efficient and streamlined APIs

QNX Neutrino has a graphics driver architecture that is based on the OpenWF Display (WFD) API, which is tuned for embedded and mobile devices, typically under resource constraints.

High-performance graphics architecture

QNX Neutrino makes full use of the built-in high-performance OpenGL ES based transitions and accelerated blitting APIs within the Screen subsystem.

QNX Software Systems offers the only full multi-core solution for embedded RTOS systems on the market.

Multiprocessor capable since 1997, and deployed on multi-core processors in virtually every embedded environment, the QNX® Neutrino® RTOS offers:

  • Symmetric (SMP), asymmetric (AMP), and bound (BMP) multiprocessing models
  • Inherent scalability — symmetric and bound multiprocessing scale seamlessly beyond two processors
  • Support for a wide range of popular multiprocessor boards
  1. Multi-core overview
  2. Bound multiprocessing
  3. Multi-core tools

In addition to its unparalleled reliability and self-healing capabilities, the QNX Neutrino RTOS microkernel architecture offers significant advantages over monolithic kernels.

Monolithic kernels

Monolithic kernels, such as Microsoft Windows or Linux, require either big kernel locks (BKL) or fine-grain locking. This is more problematic than QNX's microkernel implementation because:

  • BKLs can cause long delays for threads requiring kernel access when the kernel is running on a different core, greatly degrading coherency
  • Fine grained locking introduces a large amount of complexity into code, creating fragile, difficult to understand system level interactions, without solving the entire problem — timeliness of access is still restricted to the degree of locking implemented in the current subsystem

Microkernels

With the QNX microkernel, kernel operations are relatively few and of short duration. This minimal locking approach improves the performance of the rest of the system because neither BKL or fine grained locking approaches are necessary.

Long time-scale operations (including process managers) run in process space, and because of that, they do not halt the scheduling of other threads in the system: applications, drivers, or protocol stacks. Keeping extended duration operations in process threads (and outside the kernel) grants the microkernel the freedom to schedule regular process threads across multiple CPUs.

Efficient development

The QNX Neutrino RTOS enables rapid time-to-market for multi-core applications:

  • Reuse existing applications
  • Advanced visualization tools for multi-core systems
  • Multi-core debugging and optimization tools
  • SMP and BMP provide full visibility of all application processes and system resources

Bound multiprocessing (BMP) is a QNX innovation for multi-core systems. It extends the SMP practice of "processor affinity" to enable developers and system integrators to bind processes and threads to a specified processor without code changes. BMP is attractive to developers for a number of reasons:

  • Facilitated migration to multi-core systems — ensures, for example, that a legacy application without proper synchronization mechanisms runs as if it were on a single processor
  • Alternative to asynchronous multiprocessing (AMP) — where one or more cores are dedicated to the data plane, and one or more cores are dedicated to the control plane
  • Prevention of threads unnecessarily migrating between cores, or from overwriting each other’s caches
Bound multiprocessing use case

Example system with bound multi-processing

QNX Software System's unique BMP technology enables developers to bind processes and threads to a specified processor without code changes.

Optimization techniques

The QNX Neutrino RTOS uses multiple techniques to optimize performance on BMP systems. These techniques include soft affinity and runmasks.

Soft affinity

Whenever possible, the QNX Neutrino RTOS ensures that a thread is scheduled to run on the same CPU that it was last running on in order to improve cache performance.

Runmasks

Each thread has a runmask; that is, a bitmask that indicates which processors the thread is permitted — or forbidden — to run on. By default, a thread inherits the runmask of its parent thread to ensure that all threads in a process are bound to the same processor. Runmasks for each thread can be changed dynamically at any time, if a thread or its children need to change processor. This gives the system designer the ability to fine-tune system performance by tying threads to specific CPU cores or reserving cores for dedicated functions.

The QNX® Momentics® Tool Suite is a complete multi-core aware tool chain with multiprocessing debuggers, compilers, and embedding tools. Developers can easily reuse applications developed for single-core systems and quickly get them to market on multi-core systems:

  • Application profiler – isolates processing bottlenecks and finds candidates for multi-threading and parallel operations
  • System profiler – shows the processing load on each core, monitors inter-core communication, and detects resource contention to ensure optional performance on multi-core processors
  • Source level debugging – performs equally well on one or multiple cores
  • Blocking analysis – helps with shared resources

See also: QNX Momentics Tool Suite

POSIX certified

The QNX® Neutrino® RTOS supports hundreds of POSIX commands, utilities, and programming interfaces that maximize code portability and reusability. This rich, standards-based environment includes familiar shells and command-line interfaces, and allows developers to quickly migrate Linux, UNIX, and other open source programs to QNX.

The QNX Neutrino RTOS is certified for conformance to the POSIX PSE52 Realtime Controller 1003.13-2003 System product standard. Government agencies as well as commercial customers can choose the QNX Neutrino RTOS with the assurance that it provides both the code portability and the realtime determinism needed for an array of military, networking, medical, and automotive systems.

Engineered for POSIX

The QNX Neutrino RTOS was engineered from the ground up for POSIX standards. This approach eliminates the complex POSIX adaptation layer needed by other RTOSs, resulting in faster performance and lower memory costs for embedded applications.

See also: Certifications

QNX Neutrino RTOS 6.6

QNX® Neutrino® RTOS 6.6 – released in February 2014 offers a wealth of new graphics, UI, multimedia, security, and power management capabilities. The QNX OS 6.6 also supports the new QNX SDK for Apps and Media, which allows developers to create rich user interfaces with web technologies (HTML5, JavaScript, CSS) and to develop and deploy packaged HTML5 apps.

Screen graphics subsystem

  • A new graphics subsystem that can render images from multiple sources onto a single display
  • Support for multi-touch displays and gestures
  • Support for video capture and display
  • New driver architecture based on the OpenWF Display (WFD) API

Core operating system

  • Security enhancements:
    • Granular control of privilege elevation, without needing to assign root level privilege to the process
    • Kernel memory management enhancements for security
    • Address space layout randomization
    • Guard pages in heap and stack
  • Support for USB 3.0, OTG, and USB Device
  • Updates to OpenSSH, OpenSSL, and DHCPv6
  • Power and thermal management features designed to reduce CPU power consumption and heat dissipation
  • Updates to the filesystems
  • Read-only compressed filesystem (ROCF)
  • QNXFS6 with encryption

Updated GNU tool chain

  • Latest Eclipse-based IDE
    • Eclipse 4.2, with support for Git
    • CDT 8.2
  • gcc 4.7.3
  • gdb 7.5
  • binutils 2.23
  • C++11 support

See also: QNX Neutrino RTOS 6.6 Release Notes

QNX Neutrino RTOS 6.5 Service Pack 1

QNX® Neutrino® RTOS 6.5 Service Pack 1 was released in June 2012. This service pack included new enhancements to the Neutrino RTOS software.

Core operating system

  • Kernel memory management enhancements
  • io-pkt enhancements
  • New USB communication class support
  • Updated suppport for latest x86 platforms

See also: QNX Neutrino RTOS 6.5 Service Pack 1 Release Notes

QNX Neutrino RTOS 6.5

QNX® Neutrino® RTOS 6.5 was released in July 2010. This release included new enhancements to the core software and kernel.

Core operating system

  • Symmetric Multiprocessing support for ARM Cortex-A9 and Freescale Power e500MC cores
  • Persistent Publish/Subscribe service
  • Improved performance and higher file throughput
  • New support for Intel APICs and MSIs for x86 hardware
  • Expanded support for x86 boards from Advantech, Intel, and Kontron
See also: QNX Neutrino RTOS 6.5 Release Notes

QNX Neutrino RTOS 6.4.1

QNX® Neutrino® RTOS 6.4.1 was released in May 2009. This release included new features, as well as important bug fixes.

Core operating system

  • Support for ARM Cortex A8 (ARMv7 architecture)
  • Support for Freescale e500 Core Signal Processing Extensions (SPE)
  • Defragmentation of physical memory
  • Restored support for MIPSBE and MIPSLE targets

Networking

  • BIND9 support
  • SSH support

Filesystems

  • Read-only support for Microsoft NTFS and Apple HFS+

Graphics

  • Composition window manager — a new tool that enables the easy creation of transparency holes in video and flash content

See also: QNX Neutrino RTOS 6.4.1 Release Notes