Upload
vanhanh
View
225
Download
0
Embed Size (px)
Citation preview
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 1/19
QNX Neutrino RTOS
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
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.
Tr u e micr oker n e l O S
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.
Advan ces in s ecu r i ty
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.
Gr aph ics an d HMI tech n ologies
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.
Mu lt icor e migr at ion
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 r e l iabi l i ty with low r is k
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.
Advan ced s ecu r i ty mech an is ms
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 contro l o f system privi lege leve ls – restrict processes’ capabilities to only the elevated
privilege level that is necessary for the specific commands, without providing the process with access to
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 2/19
the entire system by elevating it to root privilege
Encrypted f i lesystems – the filesystem can be encrypted by dividing it into encryption domains, which
can be locked, or unlocked for access
Read-only f i lesystems – 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 Pro tection – 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
R edu ced power con s u mpt ion
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
Su ppor t for lates t mobi le gr aph ics tech n iqu es
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
Con n ect to oth er dev ices u s in g th e lates t tech n iqu es
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 BO M cos t
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 - h eal in g s ys tems
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 f r om s mal l to lar ge
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.
Gu ar an teed s ys tem r es ou r ces
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 3/19
conditions, it enforces hard resource guarantees to ensure that all applications receive their budgeted share
of resources.
Ex ten s ive boar d s u ppor t
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.
Ef f ic ien t pr odu ct deve lopmen t
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.
R ealt ime
The QNX Neutrino RTOS provides deterministic response times at the application level and in all
subsystems. Thread priority inheritance eliminates priority inversion problems.
Self - h eal in g s ys tems
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.
Adapt ive par t i t ion in g
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 avai labi l i ty
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.
Networ kin g
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.
P r otected & en cr ypted f i les ys tems
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.
P or tabi l i ty
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.
P ower man agemen t
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
Tole rant t imers – for non-realtime timer requirements (e.g. UI response timers)
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 4/19
Laz y inte rrupts – for non-realtime interrupts (e.g. keyboard interrupt event)
Dynamic Vo ltage and Frequency Scaling (DVFS) – DVFS for ARM Cortex SoCs
Secu r i ty
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.
Gr aph ics
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.
In tegr ated tool ch ain
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.
Acces s con tr o l l is ts
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.
Gr an u lar con tr o l o f s ys tem pr iv i lege leve ls
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.
R edu ced at tack s u r face
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 an d s tack pr otect ion , an d 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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 5/19
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.
En cr ypted f i les ys tems
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
The QNX Neutrino RTOS microkernel isolates processes in memory-protected user space.
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 6/19
Self - h eal in g s ys tems
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
Simpl i f ied des ign
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 adaptive partitioning offers applications unused CPU capacity while guaranteeing required CPU
cycles to critical processes.
A u n iqu e appr oach
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.
Sys tem e f f ic ien cy
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.
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 7/19
Impr oved s ys tem s ecu r i ty
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 - h eal in g s ys tems
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
Gu ar an teed r eal t ime deadl in es
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
Gu ar an teed even t r es pon s es
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
Ef f ic ien t pr odu ct deve lopmen t
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
Simpl i f ied in tegr at ion
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 iso lat ion — 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 se rvices — 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
F au lt is o lat ion — th e micr oker n e l
The QNX RTOS microkernel architecture isolates faults, ensuring that a component failure is constrained to
that component:
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 8/19
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
R ecover y — th e High Avai labi l i ty F r amewor k
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 - h eal in g s ys tems
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 Avai labi l i ty Man ager
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 R F C Su ppor t
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.
IPv6 stack (npm-tcpip-v6.so) [+] More
2367 PF_KEY Key Management API, Version 2
1826 IP Authentication Header
2402 IP Authentication Header
2403 The Use of HMAC-MD5-96 within ESP and AH
2404 The Use of HMAC-SHA-1-96 within ESP and AH
2405 The ESP DES-CBC Cipher Algorithm With Explicit IV
2406 IP Encapsulating Security Payload (ESP)
1828 IP Authentication using Keyed MD5.
1829 The ESP DES-CBC Transform
1852 IP Authentication using Keyed SHA
2841 IP Authentication using Keyed SHA1 with Interleaved Padding (IP-MAC)
2292 Advanced Sockets API for IPv6
2553 Basic Socket Interface Extensions for IPv6
2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
2460 Internet Protocol, Version 6 (IPv6) Specification
2461 Neighbor Discovery for IP Version 6 (IPv6)
2462 IPv6 Stateless Address Autoconfiguration
2451 The ESP CBC-Mode Cipher Algorithms
1981 Path MTU Discovery for IP version 6
2373 IP Version 6 Addressing Architecture
2144 The CAST-128 Encryption Algorithm
2401 Security Architecture for the Internet Protocol
2960 Stream Control Transmission Protocol (SCTP)
3257 Stream Control Transmission Protocol Applicability Statement
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 9/19
3309 Stream Control Transmission Protocol (SCTP) Checksum Change
3286 An Introduction to SCTP
2526 Reserved IPv6 Subnet Anycast Addresses
2374 An IPv6 Aggregatable Global Unicast Address Format
2375 IPv6 Multicast Address Assignments
2473 Generic Packet Tunneling in IPv6 Specification
2464 Transmission of IPv6 Packets over Ethernet Networks
2893 (Portions of) Transition Mechanisms for IPv6 Hosts and Routers
1701 Generic Routing Encapsulation (GRE)
1702 Generic Routing Encapsulation over IPv4 networks
2710 Multicast Listener Discovery (MLD) for IPv6
2711 IPv6 Router Alert Option
3493 Basic Socket Interface Extensions for IPv6
3602 The AES-CBC Cipher Algorithm and Its Use with IPsec
2410 The NULL Encryption Algorithm and Its Use with IPsec
2408 Internet Security Association and Key Management Protocol (ISAKMP)
2407 Internet IP Security Domain of Interpretation for ISAKMP
2631 Diffie-Hellman Key Agreement Method
1933 Transition Mechanisms for IPv6 Hosts and Routers
NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S.
Department of Commerce.
Rivest, R., Shamir, A., and Adleman, L., "A Method for Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, v. 21, n. 2, February 1978.
IPv4 full stack (npm-tcpip-v4.so) [+] More
791 INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL SPECIFICATION
792 INTERNET CONTROL MESSAGE PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL
SPECIFICATION
793 Transmission Control Protocol (TCP)
768 User Datagram Protocol
1122 Requirements for Internet Hosts -- Communication Layers
2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms
1112 Host Extensions for IP Multicasting
1323 TCP Extensions for High Performance
826 An Ethernet Address Resolution Protocol
2236 Internet Group Management Protocol, Version 2
894 A Standard for the Transmission of IP Datagrams over Ethernet Networks
IPv4 tiny stack (npm-ttcpip.so) [+] More
791 INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOL SPECIFICATION
793 Transmission Control Protocol (TCP)
768 User Datagram Protocol
826 An Ethernet Address Resolution Protocol
894 A Standard for the Transmission of IP Datagrams over Ethernet Networks
1812 (Portions of) Requirements for IP Version 4 Routers
Application RFC Support
1123 Requirements for Internet Hosts -- Application and Support
1700 Assigned Numbers
951 BOOTSTRAP PROTOCOL (BOOTP)
2409 The Internet Key Exchange (IKE)
1542 Clarifications and Extensions for the Bootstrap Protocol
1048 BOOTP Vendor Information Extensions
1084 BOOTP Vendor Information Extensions
854 TELNET PROTOCOL SPECIFICATION
1408 Telnet Environment Option
1572 Telnet Environment Option
959 FILE TRANSFER PROTOCOL (FTP)
2389 Feature negotiation mechanism for the File Transfer Protocol
2428 FTP
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
O ptimal u s e of s h ar ed r es ou r ces
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 10/19
QNX transparent distributed processing allows an application to access resources on any node in the
network, across virtually any network interconnection technology.
Locat ion in depen den ce
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
Bu i l t - in r edu n dan cy an d load balan c in g
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
Su ppor t for var iou s t r an s por ts
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.
Ef f ic ien t pr odu ct deve lopmen t
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
Q NX path n ame s pace
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 11/19
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.
F i le s ys tems at a g lan ce
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 f i les ys tems — NO R an d NAND f las h
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
ETFS is a power-safe filesystem composed entirely of transactions.
P er for man ce
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
P O SIX, ISO C f i le s eman t ics , an d 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
NO R f las h dev ices
NOR flash devices are supported with the QNX Flash Filesystem version 3 (FFSv3).
F au lt r ecover y
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 s ector h an dl in g
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 12/19
Sectors with errors are recorded and transparently avoided.
NAND f las h dev ices
NAND flash devices are supported with Embedded Transaction Filesystem (ETFS) technology.
R es is t power fai lu r e cor r u pt ion s
Atomic transactions ensure integrity of file and directory operations, and resist corruptions caused power
failures.
Block in tegr i ty
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
Au tomat ic f i le de- f r agmen tat ion
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
Bu lk copy s u ppor t
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
Microkerne l — 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
BIO S- les s 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.
Micr oker n e l
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.
In s tan t Dev ice Act ivat ion
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 13/19
Instant Device Activation brings a minidriver up before the kernel initialization to meet early boot
requirements, then hands control over to the OS.
Cr i t ical fu n ct ion al i ty
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
R edu ced h ar dwar e cos ts
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
Appl icat ion cu s tomiz at ion
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:
Tickles s 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.
Toler an t t imer s
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.
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 14/19
Laz y in te r r u pts
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.
Dyn amic Voltage F r equ en cy Scal in g
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.
Scr een : mu lt ip le gr aph ical in pu ts
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
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 15/19
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
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.
Mu lt i tou ch in pu t con tr o l
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
Discre te
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 captu r e
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.
Win dow gr ou pin gs
A window group is used to organize windows who share properties and a context. Properties can be
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 16/19
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
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.
Mor e e f f ic ien t an d s tr eaml in ed AP Is
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 - per for man ce gr aph ics ar ch i tec tu r e
QNX Neutrino makes full use of the built-in high-performance OpenGL ES based transitions and
accelerated blitting APIs within the Screen subsystem.
In addition to its unparalleled reliability and self-healing capabilities, the QNX Neutrino RTOS microkernel
architecture offers significant advantages over monolithic kernels.
Mon ol i th ic ker n e ls
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
Micr oker n e ls
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.
Ef f ic ien t deve lopmen t
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 17/19
P O SIX cer t i f ied
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.
En gin eer ed for P O SIX
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 Neutr ino 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.
Scr een gr aph ics s u bs ys tem
A new graphics subsystem that can render images from multiple sources onto a single display
Support for multi-touch displays and gestures
QNX Software System's unique BMP technology enables developers to bind processes and threads to
a specified processor without code changes.
O ptimiz at ion tech n iqu es
The QNX Neutrino RTOS uses multiple techniques to optimize performance on BMP systems. These
techniques include soft affinity and runmasks.
Sof t af f in i ty
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.
R u n mas ks
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
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 18/19
Support for video capture and display
New driver architecture based on the OpenWF Display (WFD) API
Cor e oper at in g s ys tem
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 ch ain
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 Neutr ino 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.
Cor e oper at in g s ys tem
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 Neutr ino RTOS 6.5
QNX® Neutrino® RTOS 6.5 was released in July 2010. This release included new enhancements to the core
software and kernel.
Cor e oper at in g s ys tem
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 Neutr ino 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.
Cor e oper at in g s ys tem
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
Networ kin g
BIND9 support
SSH support
11/4/2014 QNX Neutrino RTOS
http://www.qnx.com/products/neutrino-rtos/neutrino-rtos.html 19/19
F i les ys tems
Read-only support for Microsoft NTFS and Apple HFS+
Gr aph ics
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