Most people haven’t heard of QNX Software, though they’ve likely come in contact with it. The real-time operating system is used where software failure can lead to catastrophic consequences, even death – from high-speed trains to air traffic control towers to highway toll systems. It’s also used in more than 100 different types of cars on the road.
Nuclear Plant Powers up on Real-Time OS
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Nice to see us mentioned on here! While I don’t work for Ross Judd, I am very good friends with one of the guys who does and they do some amazing stuff. The control room mock-up is awesome…
(I work in isotope production at AECL myself.)
I have worked for Ross, and I’ve always been impressed by my interactions with QNX, which have unfortunately been too few and far between.
Hi Brett!
Hey woogs, fancy seeing you on here… hope things are going well for you this year.
There really isn’t much better in the real time space than QNX. We use QNX to control our automated molding machines and we have never had a probably. Only shutdown once while moved the factory. Since then 2 years plus uptime 24/7.
It’s nice to see QNX mentioned here, but why does the article hammer on Microsoft? Both Windows and Linux are general purpose OS’s with the user/server markets in mind. Real-time OS’s are a whole different animal. The comparison doesn’t make any sense.
Windows CE and Linux both have libraries to make them real time, but I wouldn’t trust either to run a reactor.
If you need real-time mission critical control, then use real-time OS’s, or if the application is simple enough, hardware packages like PLC/SCADA.
I agree with you on this point. I don’t think MSFT ever encourages the use of any version of Windows on life-critical stuff. In comparison to the RTOSs mentioned here, Windows is byzantine and messy. On the other hand, it’s doubtful that the RTOS systems like QNX can really handle the loads of a modern desktop with myriad hardware and maintain its stability.
If it could, then QSS could make a lot of money in a new business venture…
Edited 2006-10-09 03:57
I think it could. I think it could very easily in fact.
But that’s not QNX’s business plan. Far from it in fact. They have a small, highly functional and incredibly stable and scalable platform. They aren’t going to risk that by venturing into the desktop and server space of the average home, small business or enterprise. That’s been tried many times in the past decade and a half, and it’s failed miserably every time.
Their main function is to act as that core piece of software that’s so incredibly reliable that it’s used in trains, planes and automobiles. (and nucyoular paar playnts!)
It’s designed to do one thing and only one thing, and to do that thing really well. This doesn’t mean it can’t be made to expand—which I believe with it’s architecture is fairly simple—but that’s not what it’s made to do, and if QSS decided to jump off the deep end they’d lose their current clients quite quickly.
And I don’t doubt that their clients are probably a lucrative bunch.
Mission-critical, embedded systems work is *expensive*.
I know lot of little cases when NT-embedded was pushed by bussiness-persons into places where systems like QNX or scaled-down linux will be much better.
Dunno how deeply MSFT is tooted now in car industry, but at least there were articles that BMW uses it quite widely
Actually it is not like that, Microsoft to my knowledge has pushed hard into the embedded area, and also during the big power failure in north america it came out that some of the monitoring terminals of a nuclear plant were running on windows.
Of course there always is the never use our soft in life critical situations, but in case of a huge desaster I just want to see how Microsoft will wind out of that, because there always must have been someone who sold that stuff into nuclear plants.
I’m no longer a fan of QNX the company, but I’d just like to point out that monitoring systems could run Windows or whatever you felt like putting on them… they’re not mission-critical. The systems controlling the sensors and safety measures, now those are misison-critical.
It’s best to isolate the embedded systems and send data off to workstations running whatever is convenient; display the data in a comfortable desktop environment, and control the important bits from a well-designed embedded system.
– chrish
>why does the article hammer on Microsoft?
Because MS deserve to be hammered?
Come on, MS is making *billions* of dollars, yet there not even capable of producing good and secure software.
Most companies cannot afford to make good and secure software as it’s very costly, but MS could if they want: they have enough money for it, but they don’t do it as they don’t need to: a copy of their OS is sold for each PC sold whatever the quality of the OS..
And the customers suffer from Microsoft greed, so yes they deserve to be hammered.
I would say that Vista contradicts this but your point was largely relevant in the past. See: Windows 95 & ME.
Okay… that’s all fine and good. Trash the greedy corporation. I get it.
But Microsoft is still not competing in the Real Time OS sector, as QNX is not competing in the server/desktop OS sector. It is not a valid comparison no matter how much you hate or love Microsoft.
I never really thought about it, but if you had asked me, I’d have said it was QNX.
So, is this news? Not bashing, just wondering if this is the first powerplant to use QNX. Or if they all do.
Wouldn’t get on an elevator with anything else.
As amazing as this seems, it is entirely feasible to have elevators with absolutely no computer hardware or software involved: most elevators you use have zero computer hardware involved, in fact. It is very simple (comparatively speaking) to build decent elevators that are very reliable with zero computer stuff, as there’s many ways it can be done with simpler electromechanical hardware.
So, if you maintain “Wouldn’t get on an elevator with anything else.” I hope you live in a place where you can easily take stairs up and down to whatever floors you need
I think that in situations where there are a small number of elevators this is still true to a certain extent, but more and more, any situation in which there are more than 3 or 4 elevators in the core, is likely to have a traffic control computer coordinating all of the elevators.
After all, how else can they all be on the wrong floor, going in the wrong direction, when you need one?
As amazing as this seems, it is entirely feasible to have elevators with absolutely no computer hardware or software involved: most elevators you use have zero computer hardware involved, in fact. It is very simple (comparatively speaking) to build decent elevators that are very reliable with zero computer stuff, as there’s many ways it can be done with simpler electromechanical hardware.
Most modern elevators use microcontrollers, we had some old ones at work who were relais based (open rack with clicking things alover) quite relyable. but they don’t live forever…
Modern ones include things like automatic leveling, smoother rides and in larger buildings some clever behaviour of the elevators can be usefull.
Using Microcontrollers with a couple of input, outputs
and a program saves a lot of additional wires and relais.
I can’t imagine an elavator in a large building that didn’t use a microcontroller or PLC.
How do you get your electromechanically controlled elevator to look at 10 requests from 10 different floors for up or down direction and schedule them appropriately with hardwired relays?
I’m sure it’s possible with lots and lots of boolean simplification and cabinets full of hundreds of relays, but each relay is a mechanical failure point, and the project would be ridiculously expensive. I can buy 3 or 4 relays for the same price as a cheap PLC that can emulate thousands of relays.
Certainly PLC’s are used, and certainly there’s a microcontroller in them: but they’re also certainly not running anything more than a very simple embedded bit of software in a very tight loop.
Yes, PLC’s simplify things immensely, and can often make things much cheaper once things start getting complicated and allow things to be reprogrammed as needed, but they don’t require even anything as complicated as QNX, or as much RAM: they’ve been around and used before QNX was around, in such places as car factories. PLC’s have a minimum amount of memory, only as much as is required to hold the current state of all the I/O hardware and the limited number of timers and such, because they don’t need anymore than that.
Put in the original context of “I wouldn’t use an elevator with anything else” even with the more sophisticated elevators (how many use QNX?) causes options to be extremely limited.
FYI, yes, I’ve programmed PLC’s in industry.
What is your building control system/application written in? Building I work in is centrally controlled, from the vents to the window shades to the elevators to the escalators to the moving sidewalks to surveillance… there is only 5 flights of stairs and I do usually use them just for my health but if someone were to say, “QNX or nothing”, then I would take it to mean nothing is perfectly acceptable which would include those antiques.
Claims about QNX and Microsoft and security remind me of the bull coming out of Firefox in the early days.
http://secunia.com/product/708/?task=advisories
9 Security advisories
One of those 9 is a “multiple”:
http://secunia.com/advisories/18750/
“Multiple vulnerabilities have been reported in QNX Neutrino RTOS, which can be exploited by malicious, local users to cause a DoS (Denial of Service) or gain escalated privileges.
1) The crttrap utility loads libraries insecurely, which can be exploited to load an arbitrary library containing malicious code by manipulating the LD_LIBRARY_PATH environment variable.
Successful exploitation allows execution of arbitrary code with root privileges (installed setuid “root” by default), but requires that the system is in text mode.
The vulnerability has been reported in version 6.2.1. Other versions may also be affected.
2) A format string error in the fontsleuth utility can be exploited to execute arbitrary code with root privileges (installed setuid “root” by default) by supplying a specially crafted string as the zeroth argument.
The vulnerability has been reported in version 6.3.0. Other versions may also be affected.
3) A boundary error in the libAp system library in the “_ApFindTranslationFile()” function when handling the ABLPATH environment variable can be exploited to cause a stack-based buffer overflow and execute arbitrary code with root privileges (used by various utilities installed setuid “root” by default).
A similar vulnerability is also present in the handling of the ABLANG environment variable.
The vulnerabilities have been reported in version 6.3.0. Other versions may also be affected.
4) A boundary error in the libph system library in the “setitem()” function when handling the PHOTON_PATH environment variable can be exploited to cause a stack-based buffer overflow and execute arbitrary code with root privileges (used by various utilities installed setuid “root” by default).
The vulnerabilities have been reported in version 6.3.0. Other versions may also be affected.
5) A race condition in the phfont utility (installed setuid “root” by default) when spawning phfontphf can be exploited to gain root privileges by manipulating the PHFONT and PHOTON2_PATH environment variables.
The vulnerability has been reported in version 6.2.1. Other versions may also be affected.
6) A boundary error in the su utility can be exploited to cause a stack-based buffer overflow by passing an overly long string as the first command line argument.
Successful exploitation allows execution of arbitrary code with “root” privileges (installed setuid “root” by default).
The vulnerability has been reported in version 6.2.0. Other versions may also be affected.
7) An error can be exploited to cause the system to become unresponsive and hang by executing the following command:
echo -e “break *0xb032d59fnrncontncont” | gdb gdb
The vulnerability has been reported in version 6.3.0. The vulnerability does not affect version 6.0. Other versions may also be affected.
8) Insecure file permissions on the “/etc/rc.d/rc.local” file can be exploited to gain “root” privileges by adding arbitrary commands to the file.
The security issue has been reported in version 6.3.0. Version 6.0 is unaffected. Other versions may also be vulnerable.
9) A boundary error in the passwd utility can be exploited to cause a buffer overflow by passing an overly long string as the first command line argument.
Successful exploitation allows execution of arbitrary code with “root” privileges (installed setuid “root” by default).
The vulnerability has been reported in version 6.2.0. Other versions may also be affected.
Solution:
Grant only trusted users access to affected systems.
Remove setuid bits from affected files. Set proper file permissions on the rc.local file, and allow only trusted users to run GDB.
Provided and/or discovered by:
1) Discovered by anonymous person and reported via iDEFENSE.
2) iDefense Labs
3) Filipe Balestra
4) Filipe Balestra
5) Knud Højgaard
6) Texonet
7) Discovered by anonymous person and reported via iDEFENSE.
8) Discovered by anonymous person and reported via iDEFENSE.
9) Texonet”
Edited 2006-10-09 06:26
I am not an expert so I might be wrong but it seems most of the vulnerabilities are in unix compatibility stuff to me. hmmmm
I doubt a nuclear power-plant is directly connected if connected at all to the internet.
Those vulnerabilities aren’t necesarily critical.Physical access is all that is needed.I’m quite sure the compound itself is heavily secured.
I doubt a nuclear power-plant is directly connected if connected at all to the internet.
Unless of course you tire of chess and wish to play Global Thermonuclear Meltdown 😉
I’m glad I don’t live next door …
NK just launched their nuke: http://hardware.slashdot.org/hardware/06/10/09/0333202.shtml
I work on Air Traffic systems and have since 1995. Standard Air Force and FAA equipment. Systems run on a mix of Windows 3.11, DOS, Windows NT 4, Windows 2000, Windows 95, AIX, and Solaris (various versions). That’s the recorder systems, switching systems, radar mosaic (terminal and air route), and so forth. I know of no air traffic system that runs QNX, unless it’s on ROM for a specific functionality inside modems, monitors or some such. All of the primary systems are PC-controlled.
Every system that does just one thing and one thing only is a very reliable system. They aren’t “upgrading all the time either.” I’m surprised the jokers interviewed here didn’t make that distinction between critical systems and office environments.
These systems are designed and tested as one unit. It takes years to test a new upgrade and so the OS is largely locked when it’s released to service. People scoff when they hear that space shuttle laptops run Win 95, but that’s what was tested and approved for a specific set of purposes. And each and every system will usually work perfectly. The amateurs in IT depts sign off at the drop of a hat, but mission critical systems take years, sometimes over a decade to approve. After they’re in operation, they aren’t patched or upgraded except on extremely rare circumstances. Like a cash register, the UI is locked down so the users can’t create mischief. The applications on top of the OS are patched occasionally (like biannually for the real frequent ones). They have never had software issues, except for occasional application issues. In my experience, we’ve never had software issues so severe they took the system down. The one incident in LA 2 years ago was because of poorly written applications (that system ran Win 95/ NT 4) and poor maintenance. Virtually every problem I have had was because of hardware failure – hard drives, DATS (!!!), DAT Drives (!), keyboards, trackballs, video cards with fans, etc – the moving parts or the parts most touched.
They aren’t connected to the internet, the Controllers aren’t playing solitaire or Quake on them or writing their resumes. There’s very little file manipulation and that is abstracted so the users don’t even know it. Except in troubleshooting, floppies and CD-ROMS aren’t introduced. Single-purpose built and designed systems.
The STARS system runs Solaris, but it’s regarded as a failure by virtually every FAA technician who ran the older ARTS or EARTS systems. It isn’t Solaris’ fault – it’s because Raytheon’s applications on top of it are poorly written. The MEARTS system is a Lockheed Martin system that runs on almost the exact same configuration, but is extremely stable. Guess which one is being standardized on?
Edited 2006-10-09 06:33
You did not undestood what real time OS is. It’s not a matter of stability or reliability. It’s matter of real time. Only a real time of can garantee to give you the correct answer in the accurate time.
This is why you need that in a nuclear plant or a plane auto pilot, a shuttle onboard computer, a car onboard computer. Because if you need a new path, correct injection or tubo, it’s within 50 or 100 ms not within 50 or 10000 ms because you’re damned OS is swaping memory or so.
Of course, real time usage in production is often critical, so OS is reliable and stable. But be sure that this is the “real time” thing that make things possible.
I work on Air Traffic systems and have since 1995. Standard Air Force and FAA equipment. Systems run on a mix of Windows 3.11, DOS, Windows NT 4, Windows 2000, Windows 95, AIX, and Solaris (various versions). That’s the recorder systems, switching systems, radar mosaic (terminal and air route), and so forth. I know of no air traffic system that runs QNX, unless it’s on ROM for a specific functionality inside modems, monitors or some such. All of the primary systems are PC-controlled.
The operating systems you mention are not real time operating systems (RTOS). A RTOS can guarantee that a calculation/operation is completed within a specific time limit. Failure to complete the calculation within that time limit in a RTOS is considered a system failure, something that can have catastrophic effects.
A RTOS is often confused with fast systems (see other reply to your post) when in fact it does not have to be fast at all. The important thing is that the RTOS can guarantee that it will complete its operations in time. The fact that a deadline can be set to 50 nanoseconds or even a whole minute is not relevant.
Windows 3.11, 95, NT4, etc. are general purpose operating systems. They lack the mechanisms that allow them to guarantee that deadlines will be met. They are not necessarily slow systems, but the execution time for a calculation can vary greatly depending on (among other things) the system load.
Edited 2006-10-09 09:28
The operating systems you mention are not real time operating systems (RTOS).
I know what a real time OS is and I know the OSes I listed aren’t such. The article specifically said QNX was used in ATC systems. I’m saying it’s not, unless it’s in a system I haven’t encountered. The article is not accurate. That’s all I’m saying. I know the ground systems end to end – maybe inside the airplane.
When a controller pushes a “button” on a touch screen monitor to access a channel (phone/ radio) that is a Win 3.11 PC. The headset plugs into that Win 3.11 PC and the audio is digitized in that Win 3.11 PC. The audio is piped over proprietary ISDN to a digital switch. The switch does it’s work using ICs. QNX is nowhere in that system. I know of another that runs SCO Unix for the positions.
When ATCers look at their scope, they aren’t looking at exactly where the planes are at. They are looking at where the central Solaris processors are predicting that plane is going to be based on heading, aircraft characteristics, speed, etc. That central processor pipes the info to a position processor also running Solaris over ethernet that powers the display. QNX is nowhere in there. The system that ingests the radar CD2 data and puts the data into a useable formaat also runs Solaris.
Unless the author can name a specific air traffic system using QNX, the article is inaccurate.
> Every system that does just one thing and one thing
> only is a very reliable system.
Your whole posting could be applied to ATMs as well, and they *do* fail.
Your whole posting could be applied to ATMs as well, and they *do* fail.
ATM is a network protocol,eg:Asynchronous Transfer Mode.
He was referring to ‘Automatic Teller Machines’… which DO fail. Most used to run OS/2 but they started changing over to Windows and they seem to fail quite often with BSODs, ‘No more memory’ etc…
“Remember the old style of Christmas lights where you had a big long string and if one bulb burned out the whole thing burned out and you had to go through each one and find out which single bulb failed? That’s Microsoft.”
That one made me laugh.
Hmm…I wonder how QNX would compare against VxWorks, for instance. Are they even comparable, for that matter?
Hmm…I wonder how QNX would compare against VxWorks, for instance. Are they even comparable, for that matter?
QNX has a microkernel architecture. The QNX kernel contains only CPU scheduling, interprocess communication, interrupt redirection and timers.
VxWorks, on the other hand, uses a monolithic kernel including extensive intertask communications and synchronization facilities.
That said, they’re fairly comparable from a developer’s point of view.
Just curious, is there any QNX “distro” or other RTOS that you can download and try out for free?
Not anymore, I think. There was a time – 2 years ago? – when QNX Neutrino was released for the public. I downloaded it and played around with it. It’s interesting but as a desktop distribution almost not usable. Not too many applications, and the whole thing looked and acted as if it was a Linux distribution that was 5 years old.
Generally I was not very impressed. Again, I am referring to its use on the desktop. I am aware that it has its good sides as an embedded OS – altho Linux becomes increasingly an option there too. There are some real time extentions and Linux distributions that are quite good in that area.
I found this site: http://www.openqnx.com/
I tried QNX demo disk a few years ago:
http://toastytech.com/guis/qnxdemo.html
It boots from a floppy. I remember being quite impressed
with its responsiveness, but I think it is only a demo, it’s not very useful for anything practical.
In case you need an instable OS, DRM, activation etc.p.p. –> take Vista
In case you think you are somewhat special and have too much cash –> take OS X
In case you need a general system which is stable –> take Linux xyz
In case you think you are somewhat better –> BSD, OpenSolaris
In case you need to operate a nuclear power plant –> QNX
Edited 2006-10-09 12:18
I don’t doubt this OS is an interesting option for certain applications, but this article sounded a little too much like a paid/unpaid marketing spot.
“Remember the old style of Christmas lights where you had a big long string and if one bulb burned out the whole thing burned out and you had to go through each one and find out which single bulb failed? That’s Microsoft.”
Remember the old style of Christmas lights where you had a big long string and if one bulb burned out the whole thing burned out and you had to go through each one and find out which single bulb failed? That’s Microsoft.
Remember P Money? You go in Kinkos late at night and use a color photocopier to photocopy a 20 dollar bill – one side per page.
And then you buy some glue, cut the photocopied bills out of each sheet of paper and “Paste” the 2 sides together.
Thats Linux.
ill bet you that there is at most a 1-2 month gap between each QNX article on this page. and none of them are about some kind of QNX news report.
are someone playing os favorites? and to a proprietary os no less?
You can download another microkernel os
free download for Minix3. <-google
QNX is a *real-time* OS. Last time I checked, Minix wasn’t (that was with Minix 2 though).
>elevator with anything else” even with the more >sophisticated elevators (how many use QNX?) causes >options to be extremely limited.
I know a company that uses OS/2 Warp4 for elevator control and monitoring some other systems (heat control etc)