Open Standards and Product Differentiation

(1)

Open Standards and Product Differentiation

Andrew Poliak

Global Director, Automotive Business Development QNX Software Systems Limited

Introduction

It is sometimes assumed, erroneously, that basing a product on open standards and delivering a distinct user experience are mutually exclusive options. Quite the opposite. HTML5, for example, offers all the benefits of a widely supported standard, including a large community of developers and the ability to integrate in-car

infotainment systems with virtually all smartphones and tablets. But it also provides mechanisms that allow automakers to control look-and-feel, modality of control, and end-user personalization. Moreover, HTML5 isn’t just for Web-connected or cloud applications. It also allows developers to build embedded in-car applications that never connect to the Internet or that access content only from connected mobile devices.

As an open standard, HTML5 is OS and hardware neutral. It allows OEMs to deliver branded applications and user interfaces, across tier one suppliers and OS

platforms. This portability across platforms doesn’t obviate the need for platform vendors to innovate. If anything, it affirms that their real value lies in offering software architectures that boast faster boot speed, higher reliability, superior middleware integration, more predictable response times, or better support for high-performance multicore processors—things that ultimately enable greater consumer satisfaction.

Figure 1.An infotainment HMI implemented in HTML5.

In effect, choosing the right open standard at the application level can help OEMs quickly deploy applications and technologies in a brand-conscious way to their end-users. It also enables them to choose the underlying platform best suited to

(2)

addressing cost and performance requirements, and to deliver an optimal user experience.

The optimal route

With embedded electronics now representing almost one-third of a vehicle’s cost, and in-vehicle infotainment systems accounting for a substantial share of that cost, the role of open software standards has never been more important. Not only can such standards promote code reuse, increase interoperability, and reduce vendor lock-in, they also provide access to a larger community of software developers and, in the case of HTML5, enable integration with fast-evolving mobile applications, content, and devices.

Nonetheless, some misconceptions remain. First, that open standards are

incompatible with achieving product differentiation. Second, that open standards are incompatible with “proprietary” software platforms and the advantages they offer. Third, that open source platforms offer the best route for avoiding vendor lock-in and accessing programming talent, when, in fact, such benefits are often best realized with open standards. Understanding these misconceptions is key to evaluating the true value of open standards and the platforms that support them.

It is also important to understand how software components written in a high-level environment like HTML5 can communicate effectively with low-level hardware components such as the CAN bus or GPIO pins, or with external devices such as MP3 players and mobile phones. An automotive software platform can, and should, provide mechanisms to bridge this gap and to allow the underlying hardware to evolve with little or no change to the HMI (and vice versa).

Open to differentiation

Anyone unfamiliar with HTML51_{may be excused for assuming it is “just a browser.”}

In fact, HTML5 comes with an application environment that has all the capabilities of a traditional HMI toolkit, including a rendering engine, content authoring and

packaging tools, a programming language (JavaScript), layout specifications

(HTML5, CSS3), and an underlying data model (DOM). CSS3, for example, facilitates company branding and driver personalization; it also supports sliding menus, fades, and other sophisticated transitions.

That said, HTML5 also provides capabilities that proprietary toolkits cannot offer, including:

• Freedom from vendor lock-in: no single entity “owns” the HTML5 standard, so

there is no single point of failure

• Access to a vast pool of developers and applications: HTML5 is the most widely

supported standard for mobile app development

• Integration with the latest mobile devices: smartphones, tablets, etc.

• A framework for building HMIs that can incorporate virtually any delivery model

(web, on-device apps, cloud-based services) and any type of content and functionality (audio, video, haptic, interactive displays, speech recognition)

1_{In common usage HTML5 refers to the HTML5 standard,}_plus_{ancillary standards and technologies: CSS3} (Cascading Style Sheets); the JavaScript language and associated standards, such as AJAX (Asynchronous JavaScript And XML) and JSON (JavaScript Object Notation); Document Object Model (DOM); and other non-proprietary standards, including XML. It is this broader definition of HTML5 that we use here.

(3)

Flexibility to differentiate

As a further benefit, HTML5 can work in concert with Elektrobit EB Guide, OpenGL ES, Qt, and a variety of other user interface toolkits and technologies. For instance, the QNX CAR application platform provides choice and flexibility for implementing automotive HMI frameworks. Developers can work with these native technologies and blend them with HTML5 on the same display, at the same time.

This flexibility offers almost limitless options to achieve brand differentiation while leveraging industry standards. It also permits a more responsive end-user experience by allowing designers to choose the most appropriate technology for each

application.

Just as important, HTML5 is OS and hardware neutral. It doesn’t lock the user into a specific proprietary or open source OS. As a result, OEMs and tier one suppliers are free to differentiate further down the software stack, where they can choose or implement software architectures that offer faster boot speed, higher reliability, more predictable response times, or optimized support for high-performance multicore processors—things that ultimately enable a better user experience and greater consumer satisfaction.

Moreover, if the underlying platform supports POSIX, developers can leverage open-standard APIs at the system level as well as at the HMI level. For instance, the QNX OS, which forms the basis of the QNX CAR application platform, is certified to the POSIX PSE52 Realtime Controller 1003.13-2003 product standard. This certification provides the assurance that the OS provides both the code portability and the realtime determinism needed for a variety of automotive systems.

Open standards versus open source

Automotive OEMs consider open source platforms for several reasons: to avoid vendor lock-in, to gain access to a community of developers, to leverage a rich toolset, and to avoid the costs of run-time licensing. But, often, an approach based primarily on open standards, not open source, is better suited to addressing these requirements.

Let’s compare the differences. An open standard is, by definition, vendor neutral. It is typically the product of a collaborative and transparent process free of domination by a single company or interest group. Likewise, it isn’t controlled or maintained by a single, self-interested entity. HTML5, for instance, is a standard embraced by Apple (Safari), BlackBerry (BlackBerry 10 browser), Google (Chrome and Android), Microsoft (Windows 8), Mozilla (FireFox), QNX Software Systems (QNX CAR platform), and many others.

An open source solution may or may not share these characteristics. Even though the source code is accessible to developers, the technology’s roadmap and licensing terms may still be under control of a single entity. If that entity unilaterally decides to change course, so can the direction of the technology. Compare this to an open standard, which is defined collaboratively and then maintained over a long period of time—the POSIX standards, with their 20+ year history, come to mind.

In effect, an open source OS solution can still constitute a single point of failure for the OEM. Open standard APIs don’t share this issue. They give the OEM greater freedom to choose an underlying OS platform, and to migrate their solutions across platforms, if required.

Moreover, open standards like HTML5 are unencumbered by the protective licensing terms often associated with open source OSs—terms that can lead to greater system

(4)

costs and complexity. For instance, the GNU Public License (GPL) that governs use of the Linux OS ensures that any modifications to the original program are also released to open source. This requirement poses a problem for any OEM that doesn’t want to “open source” its technology (for instance, vehicle bus information). It is also incompatible with the certifications and licenses of consumer device manufacturers whose licensing terms are designed to prevent integration of their code (for instance, iPod IAP) with GPL code bases. Such technologies must, as a result, be separated into another virtualized OS or onto expensive external hardware modules.

Because open standards like HTML5 aren’t encumbered by such licensing issues, OEMs and their suppliers gain more flexibility to choose or develop solutions of greater performance, efficiency, or cost effectiveness.

Bridging the gap

We’ve discussed how automotive developers can leverage open standards at both the user-interface level and the system level. The question is, how do you connect the two? For instance, applications developed with HTML5 reside in a high-level environment, but they may need to retrieve information from the CAN bus, GPIO pins, I2_{C and SPI devices, or other low-level components; they may also need to}

communicate with iPods, smartphones, or other external devices.

Figure 2.Using Persistent Publish/Subscribe messaging to implement communications between the HMI and low-level components.

(5)

Attempting to write interfaces that provide communication with each low-level service is a costly proposal. Moreover, the direct, point-to-point connections often used for such communication are "brittle" and tend to break when new features are introduced, on either the HMI or system level.

Our experience has shown that an HMI-agnostic, asynchronous messaging model such as Persistent Publish/Subscribe (PPS) offers a more flexible solution. With PPS, underlying hardware devices don’t communicate with the applications or the HMI directly; rather, they become publishers of data objects to which the HMI can subscribe. As a result, it becomes much easier to swap out or modify underlying hardware, as well as the HMI itself.

Consider, for example, a digital instrument cluster. In the PPS model, a software process interfacing with the CAN stack would publish data to two data objects, RPM and speed. The cluster HMI, perhaps based on OpenGL, would then subscribe to those objects. 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.

A PPS service like the one implemented in the QNX platform can utilize APIs that access standard POSIX file systems, allowing developers to use virtually any programming language that can read and write files. As a result, the service can work with any programming language or application environment, including C, C++, Java, and ksh. Components written in completely different languages and

environments can intercommunicate (for instance, HTML5 applications can communicate with C programs) without requiring any special knowledge of one another. And because the QNX implementation of PPS leverages POSIX

mechanisms, it can also take advantage of the security and access controls inherent to POSIX.

Because PPS can be technology- and language-agnostic, it needs only a small number of APIs to provide the interfaces between the HMI and the components:

• a PPS API to handle communications between the HMI and the PPS service • an SQL API to interface with local media databases

• JavaScript wrapper classes and JNEXT to handle communication between the

HMI and the hardware

• C/C++ programs interface directly with the vehicle hardware, and read and write

the PPS objects

Because the PPS messaging model is loosely coupled, the resulting system architecture can be very flexible. If a new component or device is added, very little work is required: the new component simply needs to publish data and subscribe to the relevant PPS objects; existing components must do the same for this new component if they need to communicate with it. Even changing the HMI technology wouldn’t cause great disruption in the underlying layers.

Also, sensitive information like vehicle bus data doesn’t have to be shared with the general application community. Rather, it can be abstracted and only information approved by an OEM can be published for applications to subscribe to.

(6)

Summary

It is often assumed that open source platforms offer the best route for avoiding vendor lock-in and accessing programming talent. But such benefits are often best realized with open standards. These standards promote code reuse, increase interoperability, provide access to a large developer community, and, in the case of HTML5, enable integration with fast-evolving mobile applications and devices. Also, by definition, open standards are vendor neutral, and free of domination by a single company or interest group. An open source solution, on the other hand, can be under control of a single entity, and its use can be governed by a license such as the GPL, which poses a problem for any OEM that needs to avoid “open sourcing” its technology or to offer integration with consumer devices whose licensing terms prevent integration with GPL code bases.

Some assume, erroneously, that open standards are incompatible with “proprietary” software platforms optimized to provide fast boot speeds, high reliability, predictable response times, mobile-device connectivity, and other capabilities that enable successful infotainment systems. In reality, open standards like HTML5 are OS and hardware neutral, and can be implemented on such platforms to provide developers with the best of both worlds. Moreover, the software platform can use a messaging model such as persistent publish/ subscribe, which enables software written in a high-level environment such as HTML5 to communicate easily with low-level hardware such as the CAN bus, or with external devices such as MP3 players and smartphones.

In summary, choosing the right open standard at the application level can help OEMs quickly deploy applications and technologies in a brand-conscious way to their end-users, while also enabling them to use a platform suited to their cost,

performance, and reliability requirements.

Glossary

CAN (Controller Area Network) —A serial bus system for automotive applications, originally developed in the early 1980s.

CSS3 (Cascading Style Sheets) — A style-sheet language typically used to control the style and layout of pages written in HTML and XHTML. It can be used in infotainment systems to control look-and-feel, modality of control, end-user

personalization, and branding.

Document Object Model (DOM) —A platform- and language-neutral interface that allows programs to dynamically access and update the content, structure, and style of documents written in HTML, XTML, and XML.

EB Guide — An product from Elektrobit (EB) designed for the specification, modeling, and code generation of infotainment systems, instrument clusters, and speech-enabled navigation systems.

HMI (Human Machine Interface) — Automotive HMIs can come in many forms, including physical controls (for example, hard buttons), graphical touchscreens, voice-based commands, or combinations thereof.

HTML5 — Strictly speaking, the latest version of the HTML and XHTML markup languages. In common usage, HTML5 refers to the HTML5 standard, plus ancillary standards and technologies such as CSS3, the JavaScript scripting language, the DOM, and XML.

(7)

JavaScript — A dynamic scripting language that supports prototype-based object construction, and that can function as both a procedural and an object-oriented language. It uses a syntax similar to that of Java and C++.

OpenGL ES — A cross-platform application programming interface (API) for full-function 2D and 3D graphics on embedded systems, including phones, appliances, and vehicles. It consists of well-defined subsets of the desktop OpenGL API.

POSIX (Portable Operating System Interface) — A family of IEEE

standards created to enable compatibility and portability betweenoperating systems. Qt — A popular framework for creating cross-platform applications and user

interfaces originally developed by the Norwegian company Trolltech.

PPS (Persistent Publish/Subscribe) — An asynchronous messaging service that allows developers to create loose, flexible connections between software components. Persistence refers to the ability maintain data across system resets. XML (Extensible Markup Language) — An open standard markup language designed to transport and store data. HTML, in comparison, is designed to display data.

References

Clark, William, et al., “Magic Quadrant for Mobile Application Development Platforms”. Gartner Inc., 2012.

Gryc, Andy, “HTML5-Hardware Communication with PPS Messaging”. QNX Software Systems 2012.

Gryc, Andy and Johnson, Kerry, “Why Automakers (Should) Care about HTML5”. QNX Software Systems 2011.

Gryc, Andy and Lapierre, Marc, “Why HTML5 Is Becoming the HMI Technology of Choice”. QNX Software Systems 2012.

About QNX Software Systems

QNX Software Systems Limited, a subsidiary of BlackBerry, is a leading vendor of operating systems, development tools, and professional services for connected embedded systems. Global leaders such as Audi, Cisco, General Electric, Lockheed Martin, and Siemens depend on QNX technology for vehicle infotainment units, network routers, medical devices, industrial automation systems, security and defense systems, and other mission- or life-critical applications. Founded in 1980, QNX Software Systems Limited is headquartered in Ottawa, Canada; its products are distributed in more than 100 countries worldwide. Visit http://www.qnx.com/ and facebook.com/QNXSoftwareSystems, and follow @QNX_News on Twitter. For more information on the company's automotive work, visit qnxauto.blogspot.com and follow @QNX_Auto.