Today we’re happy to feature an interview by Grant Hayes of MacSlash with Paul Leroux, a technology analyst with QNX Software Systems, who is participating in Embedded World 2006. In the interview, Paul discusses the changes QSS has experienced in the last couple years, new and established competition, and moving forward in the marketplace with new technology. 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. 6. Let’s talk about competition to QNX. Specifically, real-time Linux has advanced quite a bit in the last few years. How does this impact QNX? Paul Leroux: Despite those advances, Linux’s real-time capabilities still lag far behind those of the QNX Neutrino RTOS – and that won’t change anytime soon. Embedded design is all about doing more with less, and QNX Neutrino can achieve better latencies on low-cost, low-power processors than Linux can on higher-end processors. With QNX, you shell out less for hardware, you get better response times, and you still get a full-fledged POSIX OS. Plus, you can now have guaranteed CPU time for critical tasks, even if your system is under load or a DoS attack. Even if Linux could approach QNX Neutrino in terms of real-time performance, real-time constitutes just one of many reasons why customers choose us. For instance, consider our component-based microkernel architecture. It provides finer-grained fault tolerance than Linux, and allows users to replace and upgrade drivers, protocol stacks, and other low-level services on the fly. That makes it extremely attractive to anyone building routers and other high-availability systems. 7. How about competition with more traditional rivals, like WindRiver and its VxWorks? Paul Leroux: You can no longer assume that a competitor who, say, is strong in defense systems won’t try to take away your automotive business. Technology requirements are becoming increasingly similar across market segments, and everyone is attempting to leverage their success in one segment to gain traction in others. That said, some of our competitors have made the fatal mistake of assuming the OS has become a commodity – they’ve started to believe their own hype. But in the embedded business, technology really does count. When someone is about to embed an OS into hundreds of thousands of devices, chances are they’ll want the fastest, most reliable, most cost-effective technology available. Because we still believe in the OS, because we focus aggressively on making our OS more secure, more reliable, and easier to work with, we hold a serious advantage. 8. What are QNX’s technical benefits over Windows CE? What is competition between the two like? Paul Leroux: For a technical comparison of QNX Neutrino and Windows CE, there’s no better source than Dedicated Systems, an independent firm that has performed exhaustive tests of both OSs. Their evaluations found that QNX Neutrino was the top choice when it comes to real-time performance and OS architecture. In fact, version 6.3 of QNX Neutrino scored higher than any other RTOS that Dedicated Systems has ever evaluated. QNX Neutrino also surpassed Window CE on “softer” measures, like ease of installation and quality of documentation. Anyone interested in these results can download detailed reports from the QNX website. From a market perspective, Windows CE is strong in industrial automation and in certain segments of the Japanese auto market, notably navigation. Aside from that, we rarely come up against it. 9. Does the eQip project have any official status within QNX Software Systems? Paul Leroux: For those who don’t know, eQip stood for “embedded QNX for intelligent platforms”. A pair of QNX developers launched the eQip project on their own initiative, with blessings from R&D management. It then evolved into a community project – and a pretty cool one, at that. When people first started downloading the eval version of QNX Neutrino, many of them didn’t realize that this rich OS environment can scale down to small form factors, and still deliver lots of functionality. eQip helped correct that perception, by demonstrating the cool features – and impressive graphics – that QNX can bring to something like a PDA. 10. What’s one thing that has excited you about QNX lately? Paul Leroux: More than anything else, our adaptive partitioning technology. First of all, it’s a unique feature in the OS world – no one has anything quite like it. And besides enabling higher levels of security, it can play a huge role in simplifying software integration. The firmware for the average embedded project is doubling in size about every 10 months, so it’s now commonplace to have multiple development teams work on a device’s various software subsystems. While this approach allows subsystems to be developed in parallel, it often leads to major headaches during integration and testing, when the subsystems suddenly have to contend for processor time. Components that worked well previously suddenly become starved of CPU. Adaptive partitioning can help by letting systems designers allocate a CPU budget to each development group beforehand. Each group can then test their code within their allocated partition under simulated worse-case conditions, knowing that the code will display similar performance at integration time – a good thing, when you’re trying to get product out the door!
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
I have a friend and ex-employee working for QNX. I’ve always admired QNX as an operating system, if not always as a company. It’s probably the fastest OS I’ve ever used.
I concur. I did some work in QNX many moons ago and was simply amazed at how easy it was to get started compared to Embedded XP (which was our previous platform). Another thing i noticed was that when using Eclipse in QNX, it was like night and day compared to using Eclipse in XP. I had to assume the JRE in XP is either really bad, or QNX’s JRE was REALLY good.
Suffice to say, QNX would be my preference when doing work for embedded devices.
of course, the absolute BEST api i’ve ever used in my career would be BeOS’s api. there’s my beos injection for this thread.
If you like the BeOS API, check out “Zinzala” which was built for QNX. Although it doesn’t specifically mention BeOS, I’m sure you’ll find that it bears more than a passing resemblence to the Be API. There’s an introduction at http://www.hexazen.com/Products/SDK/Zinzala/Articles/083004/.
wow, awesome! thanks so much!!
nivenh, you could also check the following (more detailed) OSNews article:
http://www.osnews.com/story.php?news_id=9112
Edited 2006-02-16 23:14
its good to see qnx is live and kicking.
He didn’t even mention or explain why iDefense recently posted several vulnerabilities of QNX at bugtraq (all of them resulting in root-access for the attacker), because they didn’t even respond in a timespan of more than one year!
It makes me feel uneasy somehow that this security-unaware company is still selling software, which could even run in my car!
QNX is not really about security. Heck, if you run the remote platform debugging daemon (qconn) as a service, any code you remote debug will even run as root!
The thing about QNX is that, once you have developed it and have it embedded on a system, there is virtually no way access to the code. Unlike other *nix systems the embedded space is less about plugins and modularity, it’s more about using limited power devices to achieve a specific objective.
Besdies, when’s the last time you see someone take their car or their handheld GPS (not PDA GPS’ like iQue btw) for upgrade?
QNX is not the OS where you run apache or use it as a Desktop machine.
“QNX is not really about security”
“The thing about QNX is that, once you have developed it and have it embedded on a system, there is virtually no way access to the code.”
You think someone who is defending QNX would actually RTFA.
“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.”
Or know anything about what they do… http://www.qnx.com/markets/networking_telecom/
http://www.qnx.com/markets/security_defense.html
Security is extremely important to QNX.
Sorry I was typing too fast in my replies. Let me rephrase.
When I say QNX is not about security – I was referring to the development environment (that’s why I mention the qconn case). To reply to DoubleSpeak, most of the iDefenseLab vulnerability in QNX (at least it seems to me) would affect development systems a lot more than deployed systems. I can’t see people hacking around the “su” access vulnerability when all they get is touch screen in a mission critical system for example.
Deployed QNX systems are quite secure when it gets locked down. If you look at the Cisco example They say that any failure would not affect others. quote “In QNX Neutrino, virtually any software component can fail and be intelligently restarted without rebooting and without impacting other services.” That’s basically what I said in my prev post.
Then, they should better eliminate all networking code in QNX.
There are already some remote vulnerabilities known related to cars (i.e. related to bluetooth – “carwhisperer”; although it’s no QNX-specific problem). Buggy and insecure software in cars which also provides remote access could really be a problem in the future. I just hope some kind of hacker will never get my airbag to open automatically
I should be a bit more clear. Even if security is not a strongpoint in QNX, by the virtue of the microkernel many code cannot be run.
The networking code in QNX can be enabled/disabled and installed in parts. Since QNX do use a microkernel, each driver can be run with different permission/user or priority as they see fit. Even the TCP/IP stack is not part of the kernel. For example, if the bluetooth driver was crashed the worst that happens is that the bluetooth driver related subsystems (probably just the GPS and maybe phone) would get disabled. By the virtue of the kernel it can’t deny other services of its dedicated timeslice. I would guess that a well-designed embedded system would have each subsystem running as a different user/group id.
One more thing going for QNX is that you can run a whole QNX embedded system without any developer tools (which is the norm when deployed) and without scripting support. Without neither hacking will be somewhat difficult.