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