Building Embedded Industrial Applications with PPS Ben VandenBelt, B.Eng QNX Software Systems bvandenbelt@qnx.com

Abstract A Persistent Publish/Subscribe (PPS) messaging model is an excellent choice for embedded industrial systems which must integrate many disparate devices and components, as well as support a sophisticated Human-Machine Interface (HMI). PPS messaging simplifies the design of these systems and facilitates implementation of HMIs built with disparate technologies, such as HTML5, OpenGL ES, Qt, Elektrobit Guide or Crank Storyboard.

Introduction The challenges of designing embedded systems that are able to meet the ever-increasing demands of industrial applications cannot be solved by simply throwing memory and CPU cycles at them. Three characteristics of these applications present particular challenges for the system designer. Typically, they are complex, with diverse devices and software components; they must support sophisticated HMIs; and they have limited computing resources.

Persistent publish/subscribe messaging (PPS) can simplify the design of embedded industrial systems.

To demonstrate the validity of this assertion, we have implemented PPS in QNX Smart Energy, an embedded industrial reference application that brings together a wide range of components. We have concluded that this messaging paradigm is better suited for these systems than are the more common asynchronous messaging and send/receive/reply messaging models.

Asynchronous Messaging Asynchronous messaging is well known and widely implemented, and does not require detailed elaboration here. It is the solution of choice for many systems, but has some characteristics that make it less than ideal for systems that must integrate a wide range of devices and software components.

In the context of messaging models for complex embedded industrial applications, it is worth noting, for example, that asynchronous messaging is a low-level solution that pushes the burden of error handling, end-to-end semantics and buffer management up to the application level. That is, architects designing a

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

Send/Receive/Reply Send/receive/reply (synchronous) messaging is less common than asynchronous messaging. It is of particular value for real-time

Figure 1. A screen from the Smart Energy reference application.

Building Embedded Industrial Applications with PPS QNX Software Systems

2

environments, where many processes require responses to their message before they can proceed. Further, unlike asynchronous messaging, with send/receive/reply messaging, the system framework takes on the burden of handling messaging errors and message buffers.

Like asynchronous messaging, however, send/receive/reply messaging may not be the optimal choice for complex systems, especially if these systems must be designed to easily accommodate new devices, and integrate disparate applications and functionality throughout their lifespans. Send/receive/reply messaging closely couples sender and receiver. Every server communicates directly with its clients, and must know how to respond to all client messages. With messaging thus closely coupled, a change to one software component may require changes to other software components, slowing or hindering system development and increasing system fragility.

Solutions “designed and implemented based on initial connectivity requirements … are very brittle when new requirements are introduced. They typically rely on direct, point-to-point connections between communicating applications/components”1 In short, with send/receive/reply messaging, as a system increases in scale and as diverse components are added to it, that system rapidly grows in complexity and becomes increasingly brittle—difficult to upgrade and scale while ensuring performance and reliability. 1 Jerry Krasner. “Making the case for commercial

communication integration middleware”. Embedded.com (Dec. 29, 2009). http://www.embedded.com.

Persistent Publish/Subscribe Publish/Subscribe has been around in some form or other for at least 20 years. A similar messaging model, virtual synchrony, was described by K. P. Birman and T. A. Joseph in 1987 as a “a fault-tolerant asynchronous bulletin board mechanism”2. Twenty years ago, Nortel Networks implemented an analogous model for fault monitoring on telephone switches, such as the DMS-100, and used the technique in network monitoring and reporting systems. A quick search on the internet will provide many examples of Publish/Subscribe implementations, as will a search on, for instance, the ACM portal bring up hundreds of papers dealing with some aspect of publish/subscribe or other observer pattern models in computing.

Our discussion focuses on how a Publish/Subscribe model that also offers persistence across reboots, or Persistent Publish/Subscribe (PPS), can aid in the design and deployment of embedded applications that must not only support a wide range of devices and software components, but also communicate with a sophisticated HMI.

An Object-based System PPS is an object-based service with publishers and subscribers in a loosely-coupled messaging architecture. Any PPS client to the service can be a publisher only, a subscriber only, or both a publisher and a subscriber, as required by the implementation.

Publishing is asynchronous. PPS objects are integrated into the PPS filesystem pathname space. Publishers modify objects and their attributes, and write them to the filesystem. When any publisher changes an object, the PPS service informs all clients subscribed to that object of the change. PPS clients can subscribe to multiple objects, and PPS objects can have multiple publisher as well as multiple subscribers. Thus, publishers with access to data that applies to different object attributes can use the same object to communicate their information to all subscribers to that object.

2 Birman, Kenneth P. and Thomas A. Joseph. “Exploiting

Virtual Synchrony in Distributed Systems”. Cornell University. February, 1987. See also Kenneth P. Birman, Building Secure and Reliable Network Applications. Greenwich: Manning, 1996.

Binary of Human-readable Objects? A PPS service can be designed to use either binary or human-readable objects.

We chose to use human-readable objects and attributes for QNX PPS, considering that the benefits to development and debugging outweigh the cost of the larger objects.

Human-readable objects allow debugging of from the command-line using simple filesystem utilities, such as cat for subscribe and echo for publish; or using a simple program that subscribes to an object and prints out debugging information, including PPS object and attributes.

QNX Software Systems Building Embedded Industrial Applications with PPS

3

PPS clients must of course know which PPS objects are of interest. If they publish, they must know what to publish and when; if they are subscribers, they must know to which objects they must subscribe, and which object attributes interest them.

However, PPS clients do not have to manage errors and buffers beyond what they need for open(), read() and write() POSIX API calls, confirming that they can make sense of what they read, and if they want their reads to be blocking or non-blocking. The PPS service handles the rest. Clients need only know that they have read a message, and that they are able to parse what they have read. Similarly, because PPS subscribers use read() calls to retrieve objects, they do not need to manage buffers for these objects. In theory, a subscriber could use a single-byte buffer and just keep reading until it had read in everything it needed.

Persistence A Persistent Publish/Subscribe service maintains data across reboots. It maintains its objects in memory while it is running, but will save its objects to persistent storage, either on demand while it is running, or at shutdown. It restores its objects on startup, either immediately, or on first access (deferred loading). Of course, the underlying persistent storage depends on

a reliable filesystem, such as a hard disk, NAND or NOR Flash, or another custom filesystem.

As well as ensuring data persistence across reboots, the PPS messaging model can simplify startups. For example, in a system that uses another messaging model, if a client comes up after the server, this client must request up-to-date data from the server, in case something changed during the period between the time the server and the client started up. This requirement is also true if, for whatever reason, a client loses contact with a server, and it is true for each and every client on the system, to which, of course, the server must respond. With PPS, however, the 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.

System Scalability With PPS, publisher and subscriber do not know each other; their only connection is an object that has a meaning and purpose for both of them. This model gives developers great flexibility when designing a system: they can, if necessary, delay decisions on module connection points and data flow until runtime. Because such decisions are neither hardcoded nor directly linked, they can be adapted as situations or requirements evolve; they can even change dynamically as the system runs.

The loosely-couple PPS messaging model also simplifies the integration of new software components. Since publisher and subscriber do not have to know each other, developers adding components need only to determine what these new components should publish, and what data they need other PPS clients to publish. No fine-tuning of APIs is required; complexity does not increase as components are added.

Push or Pull? In its default implementation, the QNX PPS service acts as a push publishing system; that is, publishers push data to objects, and subscribers read data upon notification or at their leisure.

However, some data, such as packet counts on an interface, changes far too quickly to be efficiently published through PPS using its default push publishing.

QNX PPS therefore offers an option that allows a subscriber to change PPS into a pull publishing system. When a subscriber that opened an object with this option issues a read() call, all publishers to that object receive a notification to write current data to the object. The subscriber's read blocks until the object's data is updated, then returns with the new data.

With this pull mechanism, the PPS subscriber retrieves data from the publisher at whatever rate it requires—in effect, on-demand publishing.

Language Independence A PPS service can be designed to use either binary or QNX PPS leverages the services of standard POSIX file systems, and can thus work with any programming language or application environment, including C, C++, Java, Javascript, ksh scripting language, and so on.

A component written in one language can communicate with components written in any other language. No special knowledge of the other components is required.

Building Embedded Industrial Applications with PPS QNX Software Systems

4

Reference Application As part of our Industrial Automation program at QNX Software Systems, we designed and built the QNX Smart Energy reference application on systems running the QNX® Neutrino® RTOS. This reference application is specifically designed for the limited computing resources available to embedded industrial applications. It brings together a wide range of devices, such as sensors and cameras, and software components; it uses a sophisticated smart screen HMI built with diverse technologies; and it must allow the integration of new devices and components as well as

multiple upgrades over several years.

Simplified Architecture One of the key benefits of using PPS messaging for our reference application is that we only needed two extensions to link the HMI with the rest of the system: one for PPS and one for the QDB, the QNX database server. Had we used another messaging model, we would have had to write extensions for all the various software components that in our system communicate with the components in each technology through PPS, enabled by a single extension. Similarly, the PPS

Figure 2. A Smart Energy reference configuration with PPS messaging. Note that it requires only a single extension for communication between each HMI technology and all the software components in the system. A second extension enables direct communication between the HMI and the QDB.

QNX Software Systems Building Embedded Industrial Applications with PPS

5

messaging model will allow us to add more components to the system as we need them without writing new extensions, or revisiting the communications between system components. The figure on the previous page shows one possible configuration of the Smart Energy reference.

In a system using another messaging model, the sensors and components would be tightly coupled to each other and to the HMI. Each component would know about every other component with which it needs to exchange data—an architecture which of course makes changing or adding anything difficult, time-consuming and fraught with risks.

With PPS, components do not even need to be aware of each other’s existence on the system. Adding, for example, a burgular alarm or new application that controls feeds to the grid from solar panels would require only that these new components publish data they need to share to PPS objects, and subscribe to objects that would supply them with data they need. The application controlling feeds to the grid could read the PPS objects already in use to communicate the grid load and energy prices to the HMI in order to obtain the data it requires to know when it should send electricity out to the grid.

A further benefit of the PPS messaging architecture is, of course, that it simplifies testing, because adding new components does not require revisiting the messaging between all other components.

Conclusion The PPS messaging model is ideally suited for embedded industrial systems that must bring together disparate devices and software components under a sophisticated HMI. For a system with multiple technologies in the HMI, a single extension for PPS is all that is required to enable communication between each technology and the rest of the system components. Further, since components simply publish and subscribe to PPS objects as required by the needs of the implementation, they do not require knowledge of each other, and thus little work is required to scale or modify the system. In fact, PPS’s loose coupling of components makes changes, upgrades and expansions a relatively benign task, reducing risk and improving long-term system viability.

About QNX Software Systems QNX Software Systems is the leading global provider of innovative embedded technologies, including middleware, development tools, and operating systems. The component-based architectures of the QNX® Neutrino® RTOS, QNX Momentics® Tool Suite, and QNX Aviage® middleware family together provide the industry’s most reliable and scalable framework for building high-performance embedded systems. Global leaders such as Cisco, Daimler, General Electric, Lockheed Martin, and Siemens depend on QNX technology for vehicle telematics and infotainment systems, industrial robotics, network routers, medical instruments, security and defense systems, and other mission- or life-critical applications. The company is headquartered in Ottawa, Canada, and distributes products in over 100 countries worldwide.

www.qnx.com © 2011 QNX Software Systems Limited, a subsidiary of Research In Motion Ltd. All rights reserved. QNX, Momentics, Neutrino, Aviage, Photon and Photon microGUI are trademarks of QNX Software Systems Limited, which are registered trademarks and/or used in certain jurisdictions. All other trademarks belong to their respective owners. 302215 MC411.101