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.

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.

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, SH-4, and x86, lets designers select the best hardware platform for their embedded system, then quickly get their systems up and running.

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, 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

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. Its distributed messaging:

• Provides a consistent form of IPC (inter-process communication)
• 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 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, that is, 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 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.

• 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 architectures 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 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

QNX networking protocols

QNX Software Systems offers one of the most comprehensive networking solutions for connected and distributed systems.

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 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:

• Multiple cards can register 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:

• Inherent supports for multiple links between CPUs. 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. 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. They:

• execute outside the microkernel, in memory-protected user space. Developers can start, stop, or upgrade filesystems on the fly, without having to reboot.
• are accessible through simple POSIX / C API calls: open(), read(), write(), close(), etc.
• can run concurrently on the same target, and even work in concert to extend one another's capabilities. For example, the compression filesystem can work with a flash filesystem to dramatically reduce the flash memory requirements on a given target.

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 flash drive offering read-only access.

File systems at a glance

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.

ETFS transaction 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 where ever 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.

• BIOS-less boot — customize the boot sequence to use 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

Instant Device Activation

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

IDA boot process

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
• once control has been assumed by the full driver process, either continue to run or exit seamlessly — all without blackout times or data loss

Reduced hardware costs

• 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)

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 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 multicore applications:

• Reuse existing applications
• Advanced visualization tools for multicore systems
• Multicore debugging and optimization tools
• SMP and BMP provide full visibility of all application processes and system resources

Bound multi-processing (BMP) is a QNX innovation for multicore 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 multicore systems — ensures, for example, that a legacy application without proper synchronization mechanisms runs as if it were on a single processor
• Alternative to asynchronous multi-processing (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 multi-processing use case

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, however, as needed, if a thread or its children need to change processor. This gives the system designer the ability to fine-tuning 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 multicore 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 multicore processors
• Source level debugging — performs equally well on one or multiple cores
• Blocking analysis — helps with shared resources

See also: QNX Momentics Tool Suite