QNX and Alcatel-Lucent were shortlisted for their collaboration on the LTE Connected Car, a new concept vehicle that illustrates how 4G LTE mobile broadband technology will bring a host of new capabilities to the automobile.
As mentioned in my previous posts on the LTE Connected Car, QNX Software Systems provided most of the software for the project, including the operating system, touchscreen user interfaces, media players for YouTube and Pandora, navigation system, Bluetooth connectivity, multimedia playback, handsfree integration, games, an app store, and a virtual mechanic. All components are based on the QNX CAR application platform.
Winners will be announced Thursday, April 8. Stay tuned for an update.
Now that multi-core processors are cheap and plentiful, many designers want to junk the second system and consolidate both operating environments on the same chip. That way, they can deploy systems that consume less power, generate less heat, use up less space, and, last but not least, cost less. It's a green approach that pays off in greenbacks.
Recently, Siemens took this very approach for their high-speed mail sorting machines. Using QWin, a virtualization solution from IBV, the engineers at Siemens were able to deploy their QNX-based realtime control system and Window-based user interface on a single PC.
Siemens seems happy about the result. According to a project manager responsible for the project, "the operational capability of the new QWin virtualizer and the easy integration to the control unit of the mail-sorting machine exceeded all our expectations.”
Read the press release for more details.
And while you're at it, check out the other virtualization announcement that appeared today on QNX's website: QNX and Real-Time Systems Team Up to Combine QNX Neutrino RTOS with Hypervisor Technology.
News Flash: The persistent publish/subscribe service from QNX has just been shortlisted for a 2010 embedded AWARD. (Yeah, I know, the capitalization is weird.) QNX Software Systems has won two of these awards in the past. Can it score a hat trick? Stay tuned for updates.
And now, back to our regularly scheduled programming...
In the first installment of this two-part series, I provided an overview of PPS and explained how it offered several benefits over the direct, point-to-point connections often used for interprocess communication. Compared to these "brittle" approaches, which tend to break when new features or requirements are introduced, PPS allows developers to create loose, flexible connections between components. As a result, it becomes much easier to add, remove, or replace components without having to modify other components.
Example: Smart energy panel
To appreciate the benefits offered by QNX PPS, consider a smart energy panel that lets a homeowner control heating, air conditioning, burglar alarms, and other subsystems. This system would include temperature sensors, an on/off thermostat, and an HMI that displays the state of the various subsystems.
In a traditional system, the sensors and the HMI are tightly coupled. The HMI often knows exactly what hardware it’s talking to, which makes changing or introducing new devices very difficult. With PPS, the sensors and other devices don’t communicate with the HMI directly; rather, they become publishers of data objects. As a result, it becomes easier to swap out underlying hardware or to add new brands of temperature or control mechanisms. Just as important, multiple panels throughout the home can subscribe to the same objects, without worrying about the impact of multiple callers to a low-level sensor API.
A smart energy panel that uses PPS.
For a whitepaper that goes into more detail on using PPS in a smart energy/building automation system, click here (registration required).
Example: Automotive instrument cluster
For another example, consider an automotive instrument cluster that includes a speedometer, tachometer, temperature gauges, and other instruments. A CAN stack acquires the speedometer and RPM data from the CAN bus and, when new data arrives, issues callbacks into the cluster’s HMI. In a conventional implementation, any modifications to the underlying stack or protocol are directly reflected in the API, forcing modifications to the HMI.
In the PPS model, the CAN stack publishes two data sources, RPM and speed. The HMI then subscribes to those data sources. This loosely coupled approach allows developers to replace or modify the underlying stack or protocol without having to make any changes to the HMI. Prototyping and parallel development are also simplified, since developers can easily simulate the RPM or speed data if the hardware is still being developed.
PPS provides a key feature for systems running in harsh or unpredictable environments: persistent storage. For instance, in a smart energy system, a user’s requested zone temperature, if implemented as a published data object, will persist across a system restart or power outage.
When the system comes back up, the data object will retain the same temperature value it held prior to the interruption. On startup, PPS will restore the data object, either immediately or on first access — the developer can choose either option.
Designed for humans
When designing a PPS service, you have to decide early on whether it will use binary or human-readable objects. The binary option results in smaller objects. The human-readable option makes for simpler development and debugging. QNX chose door number 2.
Human-readable objects allow developers to debug from the command-line using simple file system utilities, such as cat for subscribe and echo for publish. They also make it easy to create a simple program that subscribes to an object and prints out debugging information, including PPS object and attributes.
For instance, to display all PPS objects in a system, you can simply type:
ls -lR /fs/pps/
To create, query, or modify QNX PPS objects, developers can use industry-standard POSIX API calls: open(), read(), write(), and so on. For instance, to publish to a PPS object, a publisher simply calls open() for the object file. The publisher can then call write() to modify any attribute of the PPS object.
Likewise, to subscribe to an object, a client simply calls open(). The client can then query the object with read(). In response, PPS returns the object name, followed by the object’s current attributes.
For instance, if a car multimedia system publishes the metadata for the currently playing song in an object called “PlayCurrent”, a subscriber that queries PlayCurrent with read() might see something like this:
Caveat: This section provides a high-level overview. Read the preliminary PPS docs to get the full skinny.
Flexible design options
PPS keeps your options open. For instance:
- Multiple publishers to the same object — Multiple publishers can publish to the same PPS object, and each publisher can “own” a different attribute of the object. In a multimedia system, for instance, one component may be the source of a “time::value” attribute, while the HMI may be the source of a “duration::value” attribute.
- Multiple subscribers — PPS clients can subscribe to multiple objects and PPS objects can have multiple subscribers. When a publisher changes an object, all clients subscribed to that object are informed of the change.
- No artificial limits — The number and depth of PPS directories and the number of PPS objects in a directory are limited only by available memory.
- Push and pull — By default, QNX PPS functions as a push publishing system. But it also allows a subscriber to pull data from a publisher, so that publishing occurs on demand.
Persistent storage requires a reliable file system. So in addition to PPS, QNX Software Systems also provides a choice of high-reliability file systems, including a power-safe disk file system, an embedded transaction file system for NAND flash, and a fault-tolerant file system for NOR flash. PPS can also work with customer-created file systems.
So there you have it: a less brittle way to connect software components together.
p.s. To read Part I of this two-part series, click here.
p.p.s. Thanks again to Andy Gryc for all his invaluable contributions. Thanks also to Nicola Vulpe for making the PPS docs human readable. :-)
- — Jaron Lanier, quoted in an article by Jack Ganssle
- — Jerry Krasner, from an article on Embedded.com
This tight coupling makes things difficult for many embedded designs, particularly those that combine low-level control with high-level user applications. Take, for example, a realtime system for motor control that uses an HMI based on Adobe Flash. The Flash team may have little, if any, idea as to how to design a realtime system, let alone communicate with it. And the realtime team might have zero experience with Flash. The two teams live in different worlds: how do you bridge the gap?
To address these challenges, QNX Software Systems has introduced a Persistent Publish-Subscribe (PPS) service for embedded systems. Small and extensible, PPS allows developers to build loosely connected systems based on asynchronous publications and notifications. PPS also offers data persistence across reboots.
Creating decoupled designs
PPS provides an object-based system that consists of publishers and subscribers: publishers modify the properties of data objects and the subscribers to those objects receive updates when the objects have been modified.
With PPS, publishing is asynchronous: the subscriber of a service doesn’t have to wait for the publisher. This approach eliminates work for the subscriber process, as it doesn’t have to spawn a new thread to receive information from the publisher, synchronize the return of data with that new thread, or poll for a result.
In fact, the publisher and subscriber don’t have to “know” each other; their only connection is an object that has a meaning and purpose for both of them.
This “decoupling” gives the development team greater flexibility, as they can delay decisions on module connection points and data flow until runtime. Because such decisions don’t have to be hardcoded or directly linked, they can be adapted as situations or requirements evolve; they can even change dynamically as the system runs.
In many ways, PPS is similar to process control systems where the objects are control values updated by hardware or software. Subscribers can be alarm-handling code, displays, and so on. In fact, PPS is well-suited to such systems, as well as to others that have a similar data model.
Scalable, persistent, and language independent
PPS offers many benefits, including:
- Loose coupling for scalable design — With PPS, you can easily plug in (or plug out) different publishers or consumers of a data source, without having to create a fine-tuned, highly synchronized API between components.
- Greater flexibility than conventional IPC — PPS goes beyond the conventional one-to-one relationship between software components. It also supports one-to-many relationships (one publisher, multiple subscribers) and many-to-one relationships (many publishers, one subscriber).
- Data persistence across reboots — PPS allows data sources to survive a reset, without the need for any special software logic. This state-saving capability, useful for a variety of industrial and automotive environments, is built in: the developer doesn’t have to design or implement any special data failsafe mechanisms to take advantage of it.
- Language independence — Because PPS leverages the services of standard POSIX file systems, it can work with any programming language or application environment, including C, C++, Java, Adobe Flash, ksh, and others. Components written in completely different languages can intercommunicate, without requiring any special knowledge of one another.
My colleague Andy Gryc provided invaluable assistance while I was writing this post. The insights are his; any errors are mine.
As you can see, the pelecinid is a nasty-looking bugger, but before you panic, that isn't a stinger looming menacingly at the end of its tail. It's an ovipositor. You know, for laying eggs.
Which brings us to the icky part. The female pelecinid jabs its ovipositor into soil to detect beetle grubs. When it finds one, it lays an egg. When the pelecinid larva subsequently emerges from the egg, it burrows into the beetle grub, kills it, and proceeds to feast on the remains.
Moral: When you see one of these wasps, don't kill it. Because it controls the beetle grubs that devastate lawns.
Just think of all the grass seed you won't have to buy.
Naturally, equipping a car with a 4G/LTE broadband connection will have huge infotainment value: Imagine accessing your favorite music, videos, social media sites, or applications wherever you go. But this connection will also let your car upload information it has gathered about surrounding road and traffic conditions, providing, in the words of WIRED's Van Buskirk, "a crowdsourced version of what traffic helicopters do today."
To learn more about the car, check out my previous posts or view the following videos, recently posted on YouTube. The first, from CNET, provides a guided tour of the car:
The second video, from TelecomTV, features interviews with Alcatel-Lucent's Derek Kuhn and QNX Software Systems' Sebastien Marineau-Mes: