All roads lead to QNX at embedded world 2013

Montreal, my home town, was once known as a city of churches. So much so that Mark Twain famously quipped, "this is the first time I was ever in a city where you couldn't throw a brick without breaking a church window."

If Mr. Twain were alive today and able to visit embedded world 2013, he might make a similar comment about QNX. Because it seems that, wherever you turn at embedded world, someone is demonstrating a QNX-based system.

Multimedia and wireless demos
First stop is the QNX booth, where you'll find a natty new demo designed to showcase our support for wireless, video, and HMI technologies. Among other things, the demo shows how QNX lets you work with a mix of application and graphics environments, including Qt 5.0, OpenGL ES 2.0, and Crank Software’s Storyboard Suite.

Power up the demo, and you'll see several applications, including a medical monitor:



and a speedometer:



You'll also find games, a digital thermostat, a photo viewer, an audio meter, and several other demo apps. And did I mention? You can find two of these demo systems in the QNX booth, one based on a Freescale i.MX 6 SABRE Lite board and the other on a TI AM335 Starter Kit board.

PLC demos
If you're a hard-core industrial developer, be sure to catch the two programmable logic controller (PLC) platforms in the QNX booth. These platforms were a group effort: QNX provided the OS; companies like IsaGRAF, KW-Software, and koenig-pa provided the ladder logic and EtherCAT software; and Freescale and TI provided the hardware — one platform is based on a Freescale QorIQ TWR-P1025 Tower System Module, the other on a TI Sitara AM335x ARM Cortex-A8 processor.

The purpose of these platforms is simple: to reduce the time and cost of developing PLCs and other industrial systems. If you're interested, the eval software for the platform based on the Freescale module is now available for download from the QNX website.

QNX CAR platform demo
No, we didn't drive the new QNX concept car to embedded world. But we did bring a demo of the QNX CAR application platform, and from what I hear, it's driving lots of booth traffic (pun fully intended). Here's a snap of the demo, taken on the show floor:



Lotsa partner demos
Take a walk down the aisle, and you'll soon come across several other vendors showing QNX-based systems. Here are the ones we've identified so far:

Acontis is demonstrating its EC-Motion EtherCAT motion library running on the QNX Neutrino RTOS and a TI Sitara AM335x ARM Cortex-A8 processor. Hall 1/1-538.

Crank Software is demonstrating an automotive demo based on the QNX CAR application platform. Hall 4/4-330.

Digia is demonstrating “Qt 5 on the QNX platform – a Cinematic Experience,” which will show many new features in Qt 5 Qt Quick 2. Hall 4/4 – 520.

Freescale and koenig-pa are demonstrating a PLC reference platform that integrates koenig-pa EtherCAT protocol software, ISaGRAF PLC firmware, and the QNX Neutrino RTOS on a Freescale dual-core QorIQ P1025 processor. Hall 4A/4A-206 and Hall 5/5-425.

KDAB is showcasing an IP camera demo written in Qt5 and QML, and running on the QNX Neutrino RTOS and a Freescale i.MX 6 SABRE Lite ARM Cortex-A9 platform. Hall 4/4-622.

KW-Software is demonstrating a PLC development platform developed in collaboration with QNX Software Systems, TI, and koenig-pa. Hall 1/1-446.

MPC Data, a Bsquare Company, is showcasing a high-performance graphics demo based on OpenGL and the QNX Neutrino RTOS. Hall 4A/4A-108.

Xilinx is showcasing a high-precision, low-noise, multi-motor electrical drive demo running on the QNX Neutrino RTOS. Hall 1/1-205.

For more details on these demos, check out the press release that QNX issued this morning.

The joy of talking
Several QNX experts are presenting technical talks at embedded world:

• Clear SOUP and COTS Software for Safety-Critical Systems — Tues, Feb 26, 14:00 - 14:45, Session 03
• The Joy of Scheduling — Thurs, Feb 28, 10:00 - 10:30, Session 19
• Ten Truths about Building Safe Software — Thurs, Feb 28, 14:15 - 15:00, Session 21
• Issues in M2M Communication for Software and Firmware Updates — Thurs, Feb 28, 16:30 - 17:00, Session 24

So, if for some strange and inexplicable reason, you want to avoid all things QNX, don't go to embedded world this week. Because once you arrive, there will be no escape. :-)

Designing safe software systems? I've got three articles to keep you on track

Believe it or not, the men in this video are performing a safety procedure:



So are the men in this video:



I know what you're probably thinking: What's so safe about standing near, or hanging from, a moving train? Are these people nuts?

On the other hand, you may know exactly what is happening: The men are exchanging railway tokens. In a nutshell, only one token exists for any given section of track, and only the train driver possessing the token can access that section. (If you're a software developer, think mutex.) The idea, of course, is to prevent two or more trains, especially those traveling in opposite directions, from using the same section of track at the same time.

From what I can gather, token-based systems have proved highly effective in preventing train-to-train collisions. Indeed, they remain in use in several areas, particularly on heritage railway lines.

That said, the world of rail transportation has moved on. High-speed freights, such as the TGV postal in France, zoom along at over 250 km/h, while passenger trains, such the China Railway High-speed, carry passengers at speeds reaching 350 km/h. The Shanghai Maglev Train, meanwhile, operates at a jaw-dropping 430 km/h — and is designed for speeds up to 500 km/h.

Available and correct
None of these trains could run without software control systems. Let me re-phrase that: safe software control systems. A safe software system possesses two key characteristics: It always responds when a response is required, and it always provides the correct response.

For instance, the software system controlling a train’s brakes must be available whenever required — a delayed response could result in an accident. The software system must also apply the brakes appropriately — too little can result in a collision, and too much can damage the train or cause a derailment.

To meet these requirements, the software system needs to use a real-time OS (RTOS) that meets specific claims of reliability and availability. But the software that runs on top of the OS (i.e. the part you design) must also embody these qualities. Which is where my colleague Chris Hobbs comes in.

Chris spends a lot of time thinking about the design of safe software systems — when he isn't actually helping people design them. So, not surprisingly, he has produced a series of articles and white papers to ground developers in key concepts and to help companies develop a safety culture. Electronic Design magazine has published three of his pieces so far, and I wouldn't be surprised if they publish more in the future.

Without further ado, here are the Electronic Design articles:

The Limits of Testing in Safe Systems — Key takeaway: Testing can prove the presence of faults, but it can't prove their absence. It isn't enough to test your systems; you must use other methods, such as design validation, as well. That said, testing can tell you a lot, especially when you apply statistical analysis to your test results, and when you use techniques like fault injection to estimate remaining faults and to observe how the system behaves under fault conditions.

Define And State Your Safety Requirements Before Design and Test — Key takeaway: Safety must be built into a system from the start, and everything you do should follow from the premise that all software contains faults and these faults may lead to failures. As you build your system, you must reduce the number of faults included in the design and implementation, prevent faults from becoming errors, prevent errors from becoming failures, and handle failures when they do occur.

Clear SOUP And COTS Software Can Reliably Serve Safety-Critical Systems — Key takeaway: Some device manufacturers want to use COTS software, but worry that COTS means SOUP — software of uncertain provenance. And SOUP can make a mess of safety claims... or perhaps not. If you take a nuanced approach and distinguish between opaque SOUP (which should be avoided) and clear SOUP (for which source code, fault histories, and long in-use histories are available), you may, in fact, discover that COTS software is a good choice for your safety-related project.