1. How has QNX changed since its acquisition by Harman International in 2004?
Paul Leroux: If you polled QNX employees with this question, 99% would tell you that life at QNX has remained remarkably stable. Granted, we're now part of a much larger organization, but we still target the same markets (networking, automotive, industrial automation, medical), offer the same value-added services, and maintain the same technology focus.
Harman, of course, is strongly focused on automotive and home infotainment products. In fact, they acquired QNX because they see software, and the QNX Neutrino RTOS in particular, as key to achieving differentiation in those markets. Nonetheless, Harman encourages us to target multiple industries, including networking and automation. One reason is the cross-training effect: The more that cars and home entertainment systems become network-connected, the more that QNX's expertise in networking will help enable products in those markets.
Likewise, the graphics technology that QNX originally developed for control systems and high-end videogaming devices is proving invaluable for in-car navigation and infotainment units. Our expertise in one market feeds the others.
Our management has also remained stable, with the notable exception of our new head of R&D, Charles Eagan. Charles is a former Cisco executive and longtime QNX developer, and he brings lots of know-how to the table. Dan Dodge remains at the helm as QNX CEO and CTO.
2. Where is the current focus at in QNX Neutrino development?
Paul Leroux: We have two big pushes: a new technology that constitutes a radical departure from conventional OS partitioning, and a new mode of multiprocessing that helps developers migrate easily to multi-core processors.
Let's start with partitioning. Most embedded systems nowadays need to be secure, connected, and upgradable; they must also deliver fast, predictable response times under all operating scenarios, including failure conditions and system upgrades - that's a pretty tough set of requirements. Consequently, we've just introduced adaptive partitioning, which provides each software subsystem with a guaranteed share of CPU cycles, even when the device experiences a heavy processing load or a denial-of-service attack. With adaptive partitioning, a user can download and start a new software component without compromising the real-time behavior of existing components - even if the new component misbehaves and starts running in a loop at the highest priority level. Process starvation, which is always a concern in priority-based real-time systems, is eliminated.
Now the cool thing is, adaptive partitioning will enforce CPU guarantees only when the processor runs out of spare cycles. Otherwise, it uses standard, priority-based preemptive scheduling. This approach allows busy partitions to borrow unused CPU cycles time from other partitions and permits 100% processor utilization; it also allows developers to code their embedded applications the exact same way they do today. This is a far cry from conventional fixed partition schedulers, which force developers to redesign their apps and which prohibit full CPU utilization - a real issue for resource-constrained embedded products.
As for multi-core, we've introduced bound multiprocessing - BMP for short. Most developers are already familiar with SMP, where one copy of the OS manages all processor cores simultaneously, and applications can float to any core. Well, BMP shares SMP's scalability and transparent resource management, but also lets you lock any existing software application, along with all of its threads, to a specific core. That way, applications written for uniprocessor environments can run correctly in a multi-core environment, without modifications. Moreover, those legacy apps can run in conjunction with new applications that take full advantage of the concurrent processing provided by multi-core hardware.
Of course, we still support SMP and AMP - developers are free to choose which form of multiprocessing works best for their design.
3. Who is adopting QNX Neutrino lately?
Paul Leroux: The auto market has embraced QNX Neutrino in a big way. Companies like Audi, DaimlerChrysler, Honda/Acura, Hyundai, and Saab all ship QNX-based telematics and infotainment units in their vehicles. Networking is also very strong - witness the release of Cisco's flagship, the CSR-1 routing system, which is based on our microkernel technology.
At the same time, we're seeing a resurgence in our traditional markets, industrial automation in particular. Sales to industrial customers grew considerably last year - more than we expected. Personally, though, the most exciting development this past year was the new QNX-based Laser Camera System for the space shuttle Discovery. It isn't the first time that QNX has been used on a space shuttle, but it's cool knowing that QNX helped the Return to Flight mission become reality.
4. Are QNX 4 customers upgrading to QNX Neutrino?
Paul Leroux: It all depends on their requirements. Many QNX 4 users have upgraded to QNX Neutrino because it offers fuller POSIX compliance, targets multiple processor architectures, and supports tools for memory analysis, code coverage, application profiling, and system profiling. At the same time, we've redoubled our efforts to help users to stay with QNX 4, if that's what's best for them.
For instance, we've released the first in a series of QNX 4 driver updates, which provide support for a variety of network chips, graphics chips, and ATAPI controllers. There's even a new USB 2.0 driver that supports HID, printer, and mass storage devices. Developers can find out more by visiting the developer support center on the QNX website.
5. When can we expect a successor to the QNX Momentics self-hosted development suite?
Paul Leroux: We've been very quiet about this, but starting soon, developers won't have to wait for new versions to get their hands on the latest QNX technologies. That's because we're working on a new component-based model of product releases. Rather than force developers into major upgrades - the traditional method - we will release new features as they become available. Moreover, developers will be able to integrate these new features into their existing QNX environment, and just as easily "unplug" a feature if it doesn't address their requirements.
We can do all this because we designed our technology from the beginning to be modular and component-based. The new product rollout model will leverage this inherently modular design.
- "Paul Leroux, 1/2"
- "Paul Leroux, 2/2"