PPS messaging can ease the integration of diverse components and technologies in a medical device while maintaining a consistent user interface.

when determining how best to add software intelligence to their products, medical device designers need to look beyond current requirements. Demands for human machine interfaces (HMIs), wireless networking, data storage and other capabilities are evolving quickly, and designers need to create flexible systems that can accommodate new technologies and components with minimal development effort or impact on the original design.

Choosing the right messaging model for a medical device can mean the difference between an efficient and flexible system developed and certified on schedule and under budget, and an inefficient and brittle system with all its attendant development pains. The persistent publish/ subscribe (PPS) messaging model offers many advantages over other messaging models, especially in devices with many disparate components and technologies (Figure 1).

Figure 1:This medical device proof of concept aggregates and displays data from a blood pressure monitor, spirometer, pulse oximeter, ECG and insulin pump. These components connect to a Continua interoperability manager and use PPS messaging to communicate with a Qt HMI. PPS also pro- vides messaging to a remote manager for secure Internet communication to a cloud-based database and a portable tablet.

Two other more commonly used messaging systems—asynchronous and synchronous messaging—can present challenges to the design of complex systems.

Asynchronous messaging (Figure 2) is well known and widely implemented. It is the solution of choice for many systems, but it pushes the burden of error handling, end-to-end semantics and buffer management up to the application level.

Figure 2: With asynchronous messaging, a process sends its message and contin- ues, picking up the reply when and if it arrives.

As a result, architects designing a system that uses asynchronous messaging must develop a messaging protocol or protocols to ensure the correct behavior of messaging across all applications, as they must also ensure that these applications have sufficient memory allocated for message buffers under high-load conditions. While these design tasks may require no great effort in simple systems, they can pose daunting challenges when designing or upgrading complex systems.

Synchronous, or send/receive/reply, messaging (Figure 3) is less common than asynchronous messaging. It is of particular value for real-time environ-ments, where many processes require responses to their messages before they can proceed.

Figure 3: With synchronous messaging, a process blocks until it receives a reply from the intended receiving process.

Synchronous messaging may not be the optimal choice for complex systems that must easily integrate disparate applications. Synchronous messaging closely couples sender and receiver. Every server communicates directly with its clients and must know how to respond to all client messages, so a change to one software component may require changes to other software components.

Persistent Publish / Subscribe

Publish/subscribe messaging has been around for a long time. In 1987 K. P. Birman and T. A. Joseph described a similar messaging model—virtual synchrony. Twenty years ago Nortel Networks implemented a model for fault monitoring on telephone switches, and today a quick Internet search provides many examples of publish/subscribe implementations. Persistent publish/subscribe builds upon these models by offering data persistence across reboots and can support applications that must integrate many devices and components, and a sophisticated HMI.

PPS is an object-based service with publishers and subscribers in a loosely coupled messaging architecture. Any PPS client can be a publisher, a subscriber, or both. Publishers modify objects and their attributes, and write them to a file system. When a publisher changes an object, the PPS service informs all clients subscribed to that object. Clients can subscribe to multiple objects, and objects can have multiple publishers and subscribers. Thus, multiple publishers can use the same object and its attributes to communicate information to all the clients that have subscribed to that object.

PPS clients must know which PPS objects are of interest. If they publish, they need to know what to publish and when; if they subscribe, they need to know to which objects they must subscribe, and which object attributes interest them. However, PPS clients do not have to manage errors, and the only buffers that concern them are those they need for open(), read() and write() POSIX API calls. Because PPS subscribers use read() calls to retrieve data, they do not need to manage buffers for these objects. They only need to decide if they want their reads to be blocking or non-blocking, and to confirm that they can parse what they read. The PPS service handles the rest.


A PPS service maintains data across reboots. It keeps its objects in memory while it is running, but saves them to persistent storage, either on demand or at shutdown. It restores its objects on startup, either immediately or on first access. Of course, the persistent storage depends on a reliable file system and storage media.

PPS messaging can also simplify system startups. For example, in a system that uses a conventional messaging model, if a client starts up after the server, this client must request new data from the server in case something changed between the time the server started up and the time the client started up. This requirement is also true if a client loses contact with a server, and for every client on the system. With PPS, however, the publish and subscribe service restores its objects on startup and maintains them as they change. Any client—no matter when it starts or reconnects—needs only to read these objects to acquire current data.

With PPS, the publisher and the subscriber do not know each other; their only connection is an object that has a meaning and purpose for them. This model gives designers great flexibility when creating a system. They can, if necessary, delay decisions on module connection points and data flow until runtime. Developers can adapt the connection points as they build the system, or even set them to change dynamically as the system runs, because these points are neither hardcoded nor directly linked.

PPS messaging also simplifies the integration of new components. Since the publisher and the subscriber do not need to know each other, developers adding components need only to determine what the new components should publish, and what data these components need other PPS clients to publish. They could add, for instance, ECG or EEG components to a medical device aggregator without having to fine-tune the APIs and without increasing system complexity (Figure 4).

Figure 4: System components that communicate through PPS do not need to know each other, so system designers can add new measuring devices or change the HMI without revisiting the entire system.

Proof of Concept

As part of the medical device program at QNX Software Systems, we designed and built a proof of concept to run on the limited computing resources available to a portable medical device. This application brings together a typical set of devices using a Continua-based interoperability manager, PPS, and a sophisticated HMI built with the cross-platform application and user interface framework Qt (pronounced “cute”).

We chose Qt for the user interface and the Continua Enabling Software Library (CESL) from the Continua Alliance for the interoperability manager because both of these technologies are widely known in the medical device industry. Qt offers a welldefined set of UI widgets in a C++ development environment, and has a long history of successful implementations on devices that have received FDA and other required certifications.

Qt offered all the elements needed to build clear, effective screens that support exacting design requirements, including layout, layering and multimedia support. Similarly, the communication protocols in the Continua library offered not only a simple method for communicating with disparate medical devices, but also standardized protocols with a history of successful deployment in medical devices.

Simplified Architecture

A PPS service can be designed to use either binary or human-readable objects. Binary objects are very small, but human-readable objects are preferable in all but the most constrained environ- ments. They allow developers to debug from the command-line using standard file system utilities, such as cat for subscribe and echo for publish, or to create a simple program that subscribes to an object and prints out debugging information, including a list of PPS objects and their attributes.

PPS messaging provides the application with a flexible architecture. Very little work would be required, for instance, to replace the Continua library with another library, or to replace Qt with another HMI technology. Similarly, changing the HMI technology would require no changes to the interoperability manager or to the remote manager, just as changing these managers would require no changes to the HMI.

PPS messaging also facilitates the addition of new devices, which can be connected to the system using standard Continua protocols over USB, Bluetooth, or even TCP. For example, we could add an EEG to the proof of concept simply by using Continua protocols to connect it to the interoperability manager, creating appropriate PPS objects for communication and adding the relevant displays and controls to the HMI. Further, PPS messaging simplifies testing and functional safety validation, because adding new components does not require revising and re-validating the messaging between all other components.

Finally, PPS simplifies re-branding, localization and user interface updates. Because the HMI communicates with the rest of the system through PPS objects, designers do not have to change a line of code below the HMI. They only need to ensure that a new HMI subscribes and publishes to the same PPS objects as the previous HMI. Product lines can be built with exactly the same underlying system, but with different features enabled or with different HMI designs for example, to accommodate different alphabets and writing systems.

QNX Software Systems
Ottawa, Ont.
(613) 591-0931.

Continua Alliance
Beaverton, OR.
(503) 619-0867.