From clean socks to secure transactions, QNX brings it all to Embedded World

Every year, QNX Software Systems exhibits at the Embedded World conference in Nuremburg. And every year, we like to mix things up and do something different. For instance, in years past, we have showcased a robotic vacuum, a heart defibrillator, a pipeline inspection system, an Oscar-winning flying camera, a programmable logic controller, and a control panel for bulldozers — all running on the QNX Neutrino OS.

What have we got lined up this year? Plenty, as it turns out. Once again, our booth will feature several QNX-based products, including:

• An innovative double-drum washing machine that cleans two loads of laundry simultaneously — finally, you can wash lights and darks at the same time!
• A Modular Train Control System (MTCS) from MEN Mikro Elektronik that complies with the EN 50155 functional safety standard and is based on the QNX OS for Safety
• A hardware security module from Worldline that protects secret keys and performs high-speed cryptographic operations for secure data transactions
• A traffic-light controller from SWARCO that helps improve traffic flow and optimizes the use of existing road infrastructure — learn more about this system in this morning’s press release

It’s hard to imagine four systems that could be more different. And yet, the developers of these systems all chose the same OS — a testament to the “bend it, shape it, any way you want it” quality of QNX technology. Not to mention its performance and reliability.

The Bluetooth connection
Of course, we can’t show up at Europe’s biggest embedded systems conference without bringing something new for embedded developers. And so, this year, we are demonstrating the QNX SDK for Bluetooth Connectivity, a new middleware solution for medical devices, industrial automation systems, consumer appliances, and other embedded system applications.

Designed for flexibility, the SDK offers a dual-mode Bluetooth Smart Ready stack that supports classic Bluetooth connectivity as well as connectivity to Bluetooth Low Energy devices. It also supports a comprehensive set of pre-integrated Bluetooth profiles, including the classic PAN, SPP, HDP, HID, FTP, and OPP profiles, as well as the BAS, FMP, HRP, HOGP, and PXP Low Energy profiles. Here’s the SDK at a glance:

For developers of infusion pumps, vital-sign monitors, and other medical devices, the SDK includes an IEEE 11073 Personal Health Data stack certified by the Continua Health Alliance. This stack enables easy interoperability with pulse oximeters, weight scales, and other Bluetooth-enabled peripherals, and addresses the growing demand for health devices that can wirelessly collect patient data, either at home or in a clinical setting.

Of course, the proof of the Bluetooth pudding is in the pairing. So we've also built a demo that shows how the SDK can help developers build vital-sign monitors and other connected embedded systems. The demo system can discover and pair with Bluetooth classic and Bluetooth Low Energy devices, render their data onto a touchscreen display based on Qt 5, and provide a history of heart rate, blood oxygen levels, and other vitals:

A screen capture of the Bluetooth-powered QNX medical demo

Read the press release and product-overview page to learn more about the new QNX SDK for Bluetooth Connectivity.

And if you are Nuremberg this week, drop by and see us! We’re in Hall 4, Booth 534.

QNX boards the bus: an automated fare collection system from MSI Global

You can find QNX technology in almost every form of transportation imaginable, from cars and trains to boats and planes. It’s even used in motorcyles. If you download the infographic, “35 Ways QNX Touches Our Lives,” you’ll find lots of examples, including in-car infotainment, locomotive control, and cruise-ship navigation. But here’s the thing: the infographic doesn’t say a thing about buses. Not a single mention.

Enter an announcement that fills the gap. Earlier today, QNX revealed that the QNX Neutrino OS is powering an automated fare collection system used throughout Singapore, the Philippines, and Thailand. The system comprises automatic gates, ticketing machines, and yes, onboard bus equipment, including a console for the driver and a smartcard validation system for passengers. The system was created by MSI Global, an international system integrator specializing in land-transport solutions and a subsidiary of the Land Transport Authority (LTA) of Singapore.

Silvester Prakasam, head of the fare system business unit at MSI, has good things to say about QNX. “MSI’s experience with QNX Neutrino has been very favorable and we will continue to leverage the same secure OS for our future projects. Creating a solution that could gain widespread adoption was a key consideration in our choice of OS, and with QNX Neutrino we were able to create a design that is fast and reliable, yet affordable to customers in cost-sensitive regions.”

Read the press release to learn more. Meanwhile, I thought you would enjoy some images of the fare collection system, starting with the smartcard reader:



Here's an example of the ticketing machines:


And here's an example of the automatic gates:

Can a safety-critical system be over-engineered?

Too much of a good thing?

It's a rhetorical question, of course. But hear me out.

As you can imagine, many safe systems must be designed to handle scenarios outside their intended scope. For instance, in many jurisdictions, passenger elevators must be capable of handling 11 times more weight than their recommended maximum — you just never know what people will haul into an elevator car. So, if the stated limit for a passenger elevator is 2000 pounds, the actual limit is closer to 22,000 pounds. (Do me a favor and avoid the temptation to test this for yourself.)

Nonetheless, over-engineering can sometimes be too much of a good thing. This is especially true when an over-engineered component imposes an unanticipated stress on the larger system. In fact, focusing on a specific safety issue without considering overall system dependability can sometimes yield little or no benefit — or even introduce new problems. The engineer must always keep the big picture in mind.

Case in point: the SS Eastland. In 1915 this passenger ship rolled over, killing more than 840 passengers and crew. The Eastland Memorial Society explains what happened:

"...the Eastland's top-heaviness was largely due to the amount and weight of the lifeboats required on her... after the sinking of the Titanic in 1912, a general panic led to the irrational demand for more lifesaving lifeboat capacity for passengers of ships.

Lawmakers unfamiliar with naval engineering did not realize that lifeboats cannot always save all lives, if they can save any at all. In conformance to new safety provisions of the 1915 Seaman’s Act, the lifeboats had been added to a ship already known to list easily... lifeboats made the Eastland less not more safe..."

There you have it. A well-intentioned safety feature that achieved the very opposite of its intended purpose.

Fast forward to the 21st century. Recently, my colleague Chris Hobbs wrote a whitepaper on how a narrow design approach can subtly work its way into engineering decisions. Here's the scenario he uses for discussion:

"The system is a very simple, hypothetical in-cab controller (for an equally hypothetical) ATO system running a driverless Light Rapid Transit (LRT) system...

Our hypothetical controller has already proven itself in Rome and several other locations. Now a new customer is considering it for an LRT ATO in the La Paz-El Alto metropolitan area in Bolivia. La Paz-El Alto has almost 2.5 million inhabitants living at an elevation that rises above 4,100 meters (13,600 ft.—higher than Mount Erebus). This is a significant change in context, because the threat of soft and hard memory errors caused by cosmic rays increases with elevation. The customer asks for proof that our system can still meet its safety requirements when the risk of soft memory errors caused by radiation is included in our dependability estimates..."

So where should the engineer go from here? How can he or she ensure that the right concerns are being addressed? That is what Chris endeavours to answer. (Spoiler alert: The paper determines that, in this hypothetical case, software detection of soft memory errors isn't a particularly useful solution.)

Highly recommended.

Railway communications stay on track with QNX

Yesterday, a colleague was discussing how companies in the railway industry have shown interest in the QNX Neutrino RTOS Safe Kernel. Safety is a huge priority for that industry, so companies that make systems for controlling locomotives and train yards see immense value in an operating system kernel certified to IEC 61508 Safety Integrity Level 3, or SIL3. (Super-quick tutorial: IEC 61508 is a functional safety standard that addresses the complete life cycle for safety-critical applications.) The conversation got me to thinking about a QNX-based system with a rather goblinesque name: ORC.

You've heard of applications where failure isn't an option. ORC is one of them. More specifically, it's a radio-over-IP (RoIP) system, deployed in New Zealand, that transmits all voice communications between rail vehicles and the national train control center. It also handles any emergency calls that a train may transmit if a derailment occurs.

As you can imagine, ORC has to run 24/7, with no excuses. To achieve that goal, it takes advantage of QNX Neutrino's dynamic upgradability and software fault tolerance.

Last year, QNX published a case study on ORC. The article was written by Robert Cameron, who works for a QNX distributor called Symmetry Innovations. You can find the article on the QNX website; I've also included here in its entirety:

---

Xworks Selects QNX for Mission-Critical Railway Communications System
Radio over IP system helps New Zealand Railways perform major upgrade of nationwide radio network.

ONTRACK, the government organization responsible for New Zealand’s rail network, operates a nationwide radio system to facilitate the safe movement of trains and track workers. The system, which comprises 148 hilltop and tunnel VHF repeaters, interlinked by a narrowband UHF network to a central control center, has had no major upgrades since it was installed in the early 1980s.

In a bold move to improve the system’s reliability, flexibility, and support for mobile data, ONTRACK has embarked upon a major upgrade, replacing the UHF-linking infrastructure with an Internet Protocol (IP) network. This project requires installation of radio over IP (RoIP) conversion equipment at each repeater site. VHF analogue radio will continue to provide voice and data communication from the hilltop to the train due to its excellent coverage properties.

ONTRACK considered several RoIP solutions before commissioning Xworks to develop a custom system based on the QNX Neutrino RTOS. The system, a four-channel RoIP device called the ORC, serves as a bridge between conventional VHF/UHF radio networks and an IP network. The ORC performs many functions, including:

• bandwidth-efficient G.729A audio compression


• integrated Selcall and CTCSS (CCIR) encode/decode


• serial control and diagnostics of Spectra Engineering MX800 base station radios


• integrated gigabit Ethernet switch


• extensive front-panel diagnostic capabilities


• remote management via SNMP and web browser


• local I/O for site monitoring and control


• support for data-only radios

The result is a fully integrated, low-bandwidth, vendor-neutral RoIP solution that operators can manage and control remotely from New Zealand’s National Train Control Centre.


A single ORC RoIP unit can access up to four remote radio networks via local or wide area networks, including the Internet.

24/7 reliability
The ORC has to operate flawlessly 24/7, for two key reasons:

• It forms an integral component of the hilltop repeaters, which transmit all voice communications between rail vehicles and the train control center.


• It must decode any CCIR tone sequences, including emergency calls, that a train may transmit if a derailment or other critical event occurs.

To achieve the required level of high availability, Xworks selected the QNX Neutrino RTOS because of its inherent fault tolerance and dynamic upgradeability.

Vehicle visibility on the nationwide rail corridor is paramount. Thus, the system uses special extended Selcall packets in areas of poor GPRS coverage to guarantee 100% visibility. The ORC intercepts these position reports, decodes and verifies them, then sends them back to the Train Control Centre over the IP network.

Because many repeater sites are located in remote areas with helicopter access only, the ORC includes several remote control and diagnostic facilities; it can even be cold-started remotely. The network connectivity features offered by the QNX TCP/IP stack enable operators to perform diagnostic functions remotely via Telnet or the integrated QNX Web server. Field upgrades can be performed via FTP, and extensive non-volatile logs are kept in battery-backed static RAM. The ORC also supports DHCP, which was a key requirement, and an industry-compliant MIB, which allows access to almost all ORC functions.

Time constraints
The Xworks team had to complete this complex project within 18 months. To deliver on time, the team leveraged its previous experience with the QNX Neutrino RTOS and the QNX Momentics Tool Suite.

To complete the project, the team used many QNX software components, including the high availability manager, TCP/IP stack, DHCP client, Telnet server, FTP server, Web server (Slinger), data server, flash memory driver, RAM memory driver, 16550 serial driver (13 serial ports), and AC97 audio driver.

Code reuse was a key consideration. Thanks to the message passing architecture and resource manager framework of the QNX Neutrino RTOS, the development team was able to reuse many proven device drivers previously developed for processor-specific hardware and peripherals. No code modifications to the drivers were required.

To further reduce development time, Xworks licensed signal-processing algorithms, such as the G.729 audio codec, from Vocal Technologies of Buffalo NY, USA.


To help ensure high uptimes and fault tolerance, the Xworks ORC uses the QNX high availability manager.

Nationwide deployment
Xworks has supplied 100 ORC units to ONTRACK for deployment throughout New Zealand. After rigorous on-site testing, ONTRACK’s chief radio engineer Trevor Pollock is delighted with the outcome and says “The ORC is loaded with every conceivable feature for operating a mobile radio system over an IP network. The voice quality is amazing and it’s a real miser on IP bandwidth.”

Future directions
The ORC can work in any industry that uses conventional (analog) mobile radio equipment. Potential applications include:

• Internet access to conventional voice radio networks


• Bridging of disparate radio networks (police, fire, etc.)


• Leased line and UHF link replacement


• Control and monitoring of repeater sites


• Interoperability between radio and telephone networks

Xworks also uses the QNX Neutrino RTOS in many other products, including the KMC mobile communications controller and GPS tracking device. This device is deployed in commuter trains and maintenance vehicles operating on the New Zealand rail network.

The Xworks team that developed the ORC hardware and software consisted of Aaron Croad, Kevin Buckle, and Kelvin McVinnie.

 

30 years of QNX: Chunnel train drivers gear up with QNX-based simulators

It was the early 1990s, and the folks who built the Channel Tunnel (aka the Chunnel) had a problem. To make the Chunnel commercially viable, they had to reach a goal of 1200 train crossings per day. But to do that, they needed lots of train drivers. Which meant they had to train lots of train drivers.

Being a Chunnel-train driver isn’t easy. You have to work equally well in English and French. You have to be ready at a moment’s notice to execute a variety of emergency procedures in case of fire, breakdown, or accident in midtunnel. And you have to embrace the notion of driving 100 miles per hour through a 31-mile tunnel that lies 330 feet below the sea bed. Claustrophobics need not apply.

So how were the folks running the Chunnel going to train enough drivers to handle all that? Not by using the tunnel itself, since it would be open for business 24 hours a day.

The solution was simple: use simulators. After holding international competitions in 1991, the chunnel folks chose a French firm, EBIM, to provide QNX-based simulators for the Eurostar, C92, and Le Shuttle trains.

Here's a photo of a reporter taking the EBIM simulator for a virtual drive, circa 1993. I know it's hard to believe, but photojournalists were still shooting in B&W back then:



What led EBIM to choose QNX? Allow me to quote Philippe Rose, who worked for EBIM at the time:

"We chose QNX because it was the only PC-based realtime OS that came ready with all the facilities — windowing tools, realtime functions, networking — that would allow us to achieve our design goals.

"Our first major goal was to make the simulator easy to operate. Because most instructors aren't familiar with computers, we wanted to provide an intuitive GUI interface, preferably one that used a touchscreen.

"We also wanted to develop software that could evolve easily as specifications are updated. When we first started working on the simulators, none of the trains existed. What's more, safety procedures and characteristics of rail lines were still changing.

"Finally, we wanted to achieve the fastest response times possible so that simulations would be realistic. When a trainee pulls the horn, it must sound without delay. Pressure indications and cabin movements must change immediately when he brakes. The synthetic images used by the visual system also require a high refresh rate--a new train position must be provided every 40 milliseconds (i.e. 25 images per second).

"QNX let us achieve these goals easily. First of all, creating interface prototypes with the Interface Editor took very little time, even though we had no previous experience with windowing systems.

"And the software architecture we created not only adapts easily to evolving specifications but even helps us make the most of QNX's fast response times. For example, during the integration phase of a simulator we sometimes boost performance by adjusting the initial distribution of processes. Doing this is easy since QNX processes are inherently network distributed — whether two processes exchange messages on the same node or across the network, the code is exactly the same."

GE locomotives pull ahead with QNX

Sheer brute strength. That, to me, sums up a train locomotive. After all, how else do you haul 20 million pounds of freight up a mountain?

As it turns out, it takes more than raw horsepower. Case in point: the Evolution locomotives from GE. To my surprise, each Evolution locomotive employs 20 QNX-based Pentium-class systems to monitor and control the diesel engine, traction motors, compressors, battery chargers, radiator fans, and numerous other systems. According to an article in Design News, these systems “measure and check 2,500 to 5,000 parameters with data latency varying from tens of microseconds to tens of seconds, depending on the system…”

Why all the compute power? Because on its own, raw physical power doesn’t cut it. For instance, each axle on the locomotive uses a 1000 horsepower inverter to regulate torque and slippage. Too much slippage, and the wheel burns “through the rail in a hurry.”


Lots of horsepower, and lots of compute power to boot.

To learn more about these locomotives, check out the article here and the GE brochure here. To learn more about how QNX is used in control systems, check out the QNX industrial software platform webpage here.