The technology behind QNX

QNX
was originally developed as a real time operating system (RTOS) for embedded
systems. An embedded system is a system where the main processor and the code to
control it are placed together compactly. These systems are used for devices
like mobile phones, PDAs; ‘intelligent’ microwave ovens, washing machines,
refrigerators; and hardware devices for the Internet and networking. These
devices operate in real time, meaning that the time delay between the input and
the output is predictable, unlike non real-time devices where this time can’t
be determined. So, the better the ‘responsiveness’ of the instruction set of
an operating system (OS), the better is its real-time response. OSs like QNX
that enable embedded devices to run in real-time came to be called real time OSs.
Such OSs are very small in size, making it possible to fit them on small
solid-state memory modules.

QNX later branched off as a platform OS that runs on ordinary desktop
computers. A platform OS is an OS that runs on various hardware platforms, say
the PPC and x86. Some examples of such OSs are Windows and Mac OS. These are
end-user environments.

Because QNX is a cross between a real time and a platform OS, it is called
QNX RTP (Real Time Platform). The real time version of QNX is known as Neutrino,
which is the base for the RTP and on which the features of a platform OS are
added. In this article, we’ll look at QNX’s architecture, the making of its
applications, and its memory and internal communication.

The architecture of QNX

Since QNX RTP is built on Neutrino, it inherits all features of the Neutrino
RTOS. The Neutrino has a microkernel (that is, a small core of the OS)
architecture. The kernel handles the main services, like threads, messaging,
condition variables, signals, and scheduling, within the OS. Neutrino, in
specific, provides multitasking, threads, priority-driven preemptive scheduling,
and fast context switching. Other processes related to end-user applications
will access these services from the kernel. Since the microkernel is very small,
it’s quicker in handling things. It doesn’t have services like file systems,
device I/O, and networking, that are normally found in conventional OS kernels.
Instead, it has optional processes to provide these services. In fact, even the
process manager is an optional component.

In QNX RTOS, the processes run in their own memory-protected addresses. So
the core doesn’t get affected if any of the processes crash. This is the base
for QNX RTP, making it highly stable. The kernel is composed of POSIX
standard-API and is not related in any way to the Unix kernel as many users may
think. This also makes it suitable for development in cross-platform
environments.

The making of QNX applications

Applications in QNX are modular, meaning the software and even the device
drivers are plugged into the microkernel. This makes QNX highly scalable and apt
for devices, right from ones that are short on system resources to high-end
workstations or servers. The Photon microGUI, which is the graphical interface
for the OS, is also based on a similar architecture. Any software developed for
Neutrino is in the form of modules that can be dynamically plugged into it. This
is also true for any additions or enhancements to existing modules in the OS.
So, unlike in conventional development, you don’t have to recompile and relink
the whole program code of the software for testing. Only the modules that are
changed or added, need to be compiled, linked, and tested. The kernel and the
existing tested modules can be left as such. This is supposed to reduce the time
required for development. A lot of development tools are also incorporated in
the QNX RTP distribution and you have a choice of both command-line GNU
development and a graphical environment with the Photon microGUI. There is also
a very strong developer community for QNX.

QNX’s memory and internal communication

We talked of the protected memory environment that gives QNX its stability.
Embedded systems have something called hardware watchdog timers. These are built
into the hardware and keep an eye on all processes. They reset the processor if
a process goes haywire. This can lead to system restarts and memory dumps. What
QNX RTOS employs is a software watchdog. So if an error occurs while a process
is running, the OS detects and passes it over to a user written thread, which
could make an intelligent decision. This helps reduce system downtime.

Inter Process Communication (IPC) is a very important component for reliable
communication and working of an OS. QNX claims to be the first OS to use
message-passing as a means of IPC. This method brings consistency in the
communication, be it local or over the network. In other words, when
applications are accessing a resource, they don’t know whether it’s on the
local machine or somewhere on the network.

This was just an outline of the kind of technology that goes behind QNX RTP.
For those who want more insight, check out the QNX developers network at http://qdn.qnx.com.
You can also subscribe to newsgroups at news://inn.qnx.com.

Ashish Sharma