QNX CAR comes bundled with reference applications that demonstrate the power of HTML5 and the QNX CAR architecture. These applications include a home screen, media player, phone, web browser, and navigation app that can be adapted to meet specific automaker requirements.

Home screen

The home screen showcases how an HTML5 engine can be used to render displays from disparate sources. It displays a summary view of current activity, network and Bluetooth connection status, audio volume, and other information and controls. Tabs at the bottom of the Home screen provide access to other applications or groups of applications. For example, the Apps tab, at the far right, opens a screen displaying all available applications.

Media player

The media player is an HTML5 UI with native media player capabilities, including media detection (e.g., USB, CD), metadata retrieval and synchronization, media streaming, etc.

The media player lets the user search, select and play digital media from a variety of sources, including connected devices, radio, Internet streaming radio (Pandora and others) and CDs. Other entertainment options include YouTube and AM/FM/HD Radio.

Communications

The communications component is an HTML5 UI managing native phone applications. These applications include Phone, Messaging and Address Book for Bluetooth connected phones.

Virtual mechanic

The virtual mechanic is a framework for retrieving and displaying information from the vehicle, including the CAN bus. The virtual mechanic provides an automobile diagnostic center with graphical displays showing the state of critical vehicle functions (lubricants, brakes, etc.), as well and maintenance alerts.

Climate control

The climate control component is a framework for receiving information and sending instructions to the vehicle HVAC system. It provides multi-zone climate control in the vehicle.

Weather

The weather application renders information from on-line sources: weather information for selected locations, updated regularly through the vehicle's Internet connection.

App World

App World demonstrates how users can download and install pre-packaged applications on the QNX CAR platform. It offers an entry point into a cloud-hosted App World.

Navigation

QNX CAR provides three third-party navigation engines, using a combination of HTML5, OpenGL and Qt graphical frameworks, and on-board and off-board mapping engines. Information from the engines is published to a PPS object, making details about the route available to other applications. For example, trip information can be made available to the weather application, which can then display the weather forecast for the estimated arrival time at the destination. Navigation applications include TeleNav off-board, Elektrobit embedded, and TCS off-board.

Browser chrome

QNX CAR includes a reference browser implemented with HTML5, CSS3 and JavaScript. The browser chrome is also implemented in HTML5, and uses an interface similar to that implemented on the BlackBerry Playbook. QNX CAR developers can customize or replace this chrome, as required by their projects.

The QNX CAR HMI frameworks include the HTML5 Engine and other HMI Frameworks such as Qt. The User Interface (UI) Core combines input from multiple rendering engines into one physical display.

HTML5 application environment

The QNX CAR HTML5 application environment allows developers to create and deploy applications built from web technologies (HTML5, CSS3 and JavaScript) with extensions that can access to the underlying device hardware and native services, just like native C/C++ applications.

In contrast to previous iterations of HTML, the HTML5 standard expressly attempts to ensure compatibility between browsers, making the QNX CAR environment compatible with mobile, desktop and web environments: the same HTML code can be used in all these environments. In fact, in order to ensure broad adoption of HTML5 in a manner that will be compatible across platforms, the W3C is specifying HTML5 down to the implementation level when needed to ensure compatibility.

QNX has extended the standard web development environment through a JavaScript framework that provides user interface widgets and controls with access to selected device hardware and services.

Support for multiple HMI technologies

The QNX CAR user interface doesn't need to be in HTML5. QNX CAR supports other HMI technologies, such as:

• Elektrobit GUIDE – popular in the automotive industry
• Qt – a lighter-weight comprehensive framework
• Crank Storyboard – a full design-to-execution environment

HTML5 is the recommended way to bring post-production content in to QNX CAR. However, a non-HTML5 environment may be appropriate when the automaker prefers a different HMI tool, where legacy assets exist in other tooling frameworks, or if a system is being built without extensibility.

The QNX CAR architecture supports easy integration of multiple HMI technologies simultaneously.

QNX CAR uses Persistent Publish/Subscribe (PPS), a loosely coupled asynchronous messaging architecture, to communicate between its layers (HMI to services) and most of its components. The QNX implementation of PPS is an object-based service with publishers and subscribers where any PPS client can be a publisher only, a subscriber only, or both a publisher and a subscriber, as required by the implementation.

Minimum APIs

PPS messaging is technology- and language-agnostic, with only a small number of APIs needed to provide the interfaces between the QNX CAR HTML5 HMI and the underlying components. Specifically a PPS API handles communications between the HMI and the PPS service.

UI core APIs handle communications between the HTML5 layer and a user-interface core component, and between this component and other HMI technologies, such as Qt and Elektrobit GUIDE.

JavaScript wrapper classes

Communication between the QNX CAR HTML5 HMI and the hardware is handled with JavaScript wrapper classes.

C/C++ programs interface directly with the vehicle hardware, and read and write the relevant PPS objects. The wrapper class exposes a natural class-based JavaScript API to other callers. Internally, the wrapper makes calls to an instance of a PPS class. The PPS class uses an internal mechanism to allow the JavaScript to call into the native code, and read and write relevant PPS objects.

The QNX CAR mobile device gateway enables passengers to link mobile devices to QNX CAR using technologies such as Bluetooth, USB, DLNA, MirrorLink, 3G, LTE, and Wi-Fi. Each such connection has associated PPS objects which QNX CAR applications can use to interact with the linked mobile device, so applications don't need to know the details of the physical connection that links them to QNX CAR.

Bluetooth

QNX CAR supports connections to external devices over Bluetooth. It is able to initiate a Bluetooth connection or accept a connection request. The supported profiles include:

Network interfaces: Wi-Fi, WAN (3G/LTE) and wired

QNX's io-pkt resource manager is a low-level networking interface used for handling connectivity to wired Ethernet, Wi-Fi and other radio devices (3G/LTE). It integrates low-level drivers and the TCP/IP stack, as well as a number of network connection management technologies.

USB connections

QNX CAR handles USB connections in the same manner as Bluetooth and the networking interfaces: with a combination of PPS messaging and low-level support (io-usb). USB connections can be used to integrate CDC-ECM (USB Ethernet dongle), CDC-NCM (for Mirror Link), Android Accessory Protocol or USB Blackberry MUX.

Digital Living Network Alliance (DLNA) support

QNX CAR includes pre-integrated support for Digital Living Network Alliance (DLNA), which provides media streaming capabilities from smartphones and tablets.

Apple iOS interfaces

QNX CAR provides a Made for iPod interface (iAP) for Apple iOS products (iPods and iPhones), and provides the iPod Out protocol for Apple devices that support it.

BlackBerry interfaces

QNX CAR can be paired with BlackBerry smartphones over a Bluetooth connection.

When QNX CAR is paired with a BlackBerry device a web server on the BlackBerry device uses standard web protocols (HTML5/HTTP) to serve content to the QNX CAR head unit, enabling access to and rendering of content from BlackBerry applications.

MirrorLink

QNX CAR relies on the RealVNC Mobile Solution for MirrorLink interfaces. RealVNC provides the VNC protocols and MirrorLink-specific protocols. The QNX composition manager is used to scale the VNC graphics output and integrate them into the QNX CAR HMI.

Android interfaces

QNX CAR can connect with Android devices through Bluetooth (supported profiles include HFP, A2DP, AVRCP), DLNA, and MirrorLink where available.

QNX CAR automotive services includes interfaces for phones, radio, navigation systems and speech recognition. This component also manages software updates and multimedia synchronization, playback, etc.

Service	Details
HMI settings	Configuration settings for the system HMI, including support for swipe gestures, display update behaviors, menu animation and other behaviors, media player HMI characteristics
Application controls	Application navigation and launching
App World installer and uninstaller	Application installation and removal
Media player and multimedia manager	Track session creation and managements, media playback (play, import, rip), attaching output devices and zones, etc.
Digital Living Network Alliance (DLNA) services	Digital Rights Management (DRM) services, including network state changes, playback state (play, pause, etc.), Digital Media Server (DMS) playback and subscriptions, DMS settings
Mobile device gateway	Connections to mobile devices via Bluetooth, USB, DLNA, MirrorLink, 3G, LTE, and Wi-Fi
HVAC and climate control	Controls for fan temperature and speed, seat heating, defrosting, air conditioning and air circulation
Vehicle/Virtual mechanic	Key vehicle sensors accessed through the vehicle CAN bus, including fuel level, washer, transmission and brake fluid levels, brake wear and ABS status, oil pressure and level, engine RPM, status of lights, and transmission temperature, fluid life and PRNDL

QNX CAR runs on the QNX Neutrino RTOS, a full-featured, robust real-time operating system that is the foundation of thousands of mission- and safety-critical systems running in environments ranging from spacecraft to automotive head units – and almost everything in between.

Designed for the constrained resource requirements of embedded systems, the QNX Neutrino RTOS provides unparalleled dependability and performance on single- and multi-core systems, and low total cost of ownership. Board Support Packages (BSPs) are bundled with the OS, and are available for all the more popular board architectures.

Microkernel

The QNX Neutrino RTOS is so reliable because it is a true microkernel operating system. Every driver, protocol stack, file system and application runs in the safety of memory-protected user space, outside the kernel. Virtually any component can fail – and be automatically restarted – without affecting other components or the kernel. No other commercial RTOS offers this degree of protection.

Instant device activation

QNX offers instant device activation (IDA), allowing in-vehicle systems to perform intelligently even before the operating system is operational.

With IDA, code is directly linked into the startup component of the boot loader so that it can perform all the functions necessary to meeting critical 50 millisecond startup requirements: responding to external events, accessing hardware, and storing data for use by the full driver. For example, a system can be configured to provide immediate response to power mode messages transmitted over the CAN bus.

Reduced hardware costs

IDA allows system developers to manage data from buses such as CAN without adding external hardware. Conventional operating system implementations often take several seconds to boot up from a cold or low-power state, so they require auxiliary communications processors in order to meet timing and response requirements. Using QNX IDA technology, this problem can be solved in software, eliminating hardware components and decreasing BOM costs.

File systems

Infotainment systems typically use a large amount of data storage for media, music metadata, map data and points of interest. In addition, consumers bring media in a variety of formats into the vehicle on portable devices. To accommodate this data, the operating system must provide a variety of file systems on numerous types of media.

Media formats

QNX provides a full set of file systems on common media formats, including:

• QNX power-safe file systems for hard drives
• FAT, ext2, NTFS, and HFS for USB sticks, hard disk drives and mobile devices
• embedded file systems for flash memory (managed NAND and NOR)
• ISO9660, Joliet, and UDF for CDs and DVDs
• NFS and CIFS (SMB) for network file systems

The QNX NOR Flash File System (FFS3) provides the convenience of saving persistent data to the same Flash drive that holds the system firmware image. Managed NAND media with FAT, ext2 or QNX6 file systems can be used for larger storage needs.

Networking

The QNX Neutrino RTOS supports IPv4 and IPv6 over Ethernet, as well as Wi-Fi 802.11. The standard complement of network services are available, including DNS, DHCP, inetd, firewall, FTP, TFTP, HTTP, Telnet, PPP, NFS and NTP. Thanks to its support for POSIX APIs, incorporating additional open-source networking components (e.g. Asterisk for VoIP) is a simple matter.

Wi-Fi

QNX Software Systems provides a full Wi-Fi access point as part of the QNX CAR reference implementations. This access point can be used in conjunction with a Bluetooth-capable mobile phone to provide an Internet gateway for use throughout the cab of an automobile.

Transparent distributed processing

When it is used as a distributed operating system, the QNX Neutrino RTOS uses Transparent distributed processing (TDP), an underlying networking approach also known as Qnet. All TDP-connected nodes can share devices and operating system resources. For example, any node on a network can transparently communicate with a Bluetooth connected phone, even if that particular node doesn't have a Bluetooth interface. This capability provides overall cost savings by reducing the system memory footprint and removing the cost of duplicating software that already exists somewhere in the distributed system.

The QNX Porsche concept car provides just one example of how TDP can simplify design and reduce overall system cost. This car has running on the head unit a multimedia library that the two rear-seat entertainment units can share. On the head unit, the library is accessed through a POSIX path such as /db/mmlibrary.db. When accessed from the two TDP-connected rear-seat units, however, the path for this resource would be /net/headunit/db/mmlibrary.db. The simplicity of TDP allows the underlying source code to remain the same for the head unit and the rear-seat units. The only change required is to the resource path, even when accessing resources across the network. Note that even the name change can be avoided by using a file system soft link.

Fast boot

The QNX Neutrino RTOS has a very light footprint, which naturally leads to faster boot times. The QNX kernel can be up and running in as little as 250 milliseconds. The microkernel design gives system architects the flexibility to control, which operating system and application components start, and in which order, making it easy to rearrange the system startup sequence to suit specific design needs.

This approach allows the system to meet startup audio and video requirements on each and every reboot. By starting specific device drivers and applications early in the startup cycle, the software can respond to events quickly and give audio (or other) responses shortly after power-up.

The QNX Neutrino RTOS also supports instant device activation requirements. See "Instant device activation".

Fault detection

The QNX Neutrino RTOS makes many debugging and tuning tasks easier. Keeping components isolated through memory protection lets the operating system do the hard work of finding stray pointers and crashes, and finding difficult bugs that can elude a system deployed on monolithic operating systems.

QNX also provides a powerful, instrumented kernel. This kernel traces all system activity, including interrupts, thread scheduling and inter-process communications. The QNX Momentics Tool suite's system profiler can be used to visualize this trace log to help diagnose system problems and optimize the software.

High availability framework

The QNX Neutrino RTOS modular, microkernel architecture enables the isolation of faults right down to the driver level. QNX's high availability technology provides:

• Instant fault notification – the watchdog automatically detects process faults and triggers recovery procedures. Heart beating is also used to detect non-fatal errors.
• Customized failure recovery – using the high availability framework library, the system can tell the watchdog actions to take in the event of an error: specific recovery procedures, move to a design safe state, etc.
• Instant reconnections – the high availability framework provides a client-recovery library so that, after a component failure, the system can instantly re-establish broken connections.
• Post mortem analysis – if a process faults, the high availability framework can generate a full memory dump for analysis.
• Resilience to internal failures – the watchdog employs a self-monitoring “guardian” that can take over if the watchdog fails.

When the watchdog detects component failures, it notifies the system and manages recovery. Together with its backup "guardian" process, the high availability framework provides the basis for self-healing systems.

Adaptive partitioning

Task or process starvation is a fundamental concern for any embedded system. Services provided by lower-priority threads – including diagnostic services that protect the system from software faults or denial-of-service attacks – can be starved of CPU cycles for unbounded periods, compromising system availability.

Increasing CPU power can help, but it comes at the cost of increased power consumption (hence heat generation), and cost – and it offers no guarantees that processes will not be starved.

QNX's adaptive partitioning technology provides an efficient and low-cost mechanism for ensuring that critical processes always get the CPU cycles they need, and that no CPU cycles are wasted. It allocates unused CPU cycles to processes that can benefit from them, while at the same time guaranteeing that all partitions get their budgeted share of CPU time when they need it.

Supported hardware

The QNX CAR automotive reference platform has currently been implemented for the following processor types:

• Freescale i.MX6x Sabre Lite
• Texas Instruments J5 Eco
• Texas Instruments OMAP 4430 Panda

Each chip includes a Graphics Processing Unit (GPU). OpenGL ES drivers are available for each chip.

Other platforms may become available, based on customer demand.

Memory requirements

Specific requirements for any system will of course depend on expected capabilities (e.g. 3D graphics) and performance.

System profile	Expected features	Estimated system RAM
Headless	Vehicle features, speech recognition, navigation, multimedia, webserver	256 MB
Low-end	Headless + fixed HTML5-based HMI	512 MB
Mid to high-end	Low-end + downloadable applications	1 GB
High to ultra-high	High-end + application sandboxes, and room for growth	2 GB
The table above shows estimated memory requirements for running QNX CAR

The QNX CAR HTML5 engine is the foundation for the QNX CAR HTML5 HMI support. It is based on the WebKit (www.webkit.org) open source web browser engine, which QNX has optimized for embedded environments, and to which QNX has added numerous capabilities to provide a full-featured web browser.

Perfomance optimizations

The QNX performance optimizations to WebKit include:

• power consumption management to decrease CPU temperature (and extend battery life in hybrid vehicles); for example by throttling background threads so that they use less CPU cycles and hence less power
• improved JavaScript execution to improve performance and reduce CPU utilization
• overall speed optimizations; for example, by selective image down-sampling and file size reductions (e.g., not loading a large image when a thumbnail will do)
• intelligent tile system for scrolling and zooming while reducing RAM use

QNX CAR web browser

QNX has added numerous capabilities to its optimized WebKit browser in order to provide a full-featured web browser that includes:

HTML5 engine features

The QNX CAR HTML5 engine is a fully-featured web engine that QNX updates regularly with the latest WebKit technology. It supports HTML5-specific features such as WebSocket, WebGL, session storage, offline applications, worker threads, DOM improvements, and the <canvas>, <audio>, and <video> elements.

Both QNX CAR and next generation BlackBerry devices running BB10 use the QNX HTML5 Engine.

Support for HTML5

The QNX CAR HTML5 Engine provides support for the HTML5 standard and related standards and technologies, such as CSS3, the JavaScript scripting language and associated standards, such as AJAX, JavaScript Object Notation (JSON), and XML.

HTML5 applications can support a variety of user interface technologies, including interactive displays, audio, video, speech recognition and haptic controls. With HTML5, developers can use a common toolset to build applications for QNX CAR or mobile devices, or that will be hosted on the cloud.

Partitioned UI and sandbox

With the QNX CAR architecture, each WebView (equivalent to a tab in a desktop browser) runs in its own HTML5 engine instance. Each WebView can be implemented with a separate (and different) JavaScript application framework (e.g., jQuery Mobile or Sencha Touch).

Applications running within the same instance of the HTML5 engine would not be isolated from each other. Incorrect behavior in one application could impact all other applications. For example, a hung or stalled JavaScript thread in one application would hang all other HTML5 applications. This is why the QNX CAR architecture runs each application in its own, private HTML5 engine instance (its "sandbox"). This design isolates applications so that any problems they encounter do not impact other applications. It does, however, increase the system's memory footprint.

The UI core consists of components that allow dynamic loading, launching and screen sharing of applications developed with a variety of HMI technologies.

The components in UI core are not tied to the HTML5 application environment and can be used with other, third-party HMI frameworks such as Qt, Elektrobit GUIDE or Crank Storyboard, which QNX CAR supports in addition to HTML5. The UI design is modular, and allows for straightforward support of additional technologies to be added in the future.

Combining multiple HMI technologies

With an open list of HMI technologies to choose from, system developers can choose the technology that works best for each application.

When multiple HMI technologies are active concurrently, their outputs are merged together with the QNX composition manager, as decided by the primary controlling application (the home screen for QNX CAR). The composition manager was designed to provide the most highly optimized path from the applications to the screen.

UI core components

The main components of the UI core are the application installer, the authorization manager, the composition manager and the launcher.

Application installer

The application installer un-packages the application, validates its signature, and installs the application on the QNX CAR platform.

Authorization Manager

The authorization manager controls which APIs and system services can be used by each application, enforcing the security model defined by the system developers. This authorization ensures that downloaded applications cannot use interfaces they are not authorized to use.

Composition manager

The composition manager integrates multiple graphics and user interface technologies into a single scene that can be rendered on screen. User interface technologies that the composition manager can combine include HTML5, Elektrobit GUIDE, Crank Storyboard, Qt and native (e.g. OpenGL ES) code.

Launcher

The launcher enables any application to launch any other application in any user interface environment (subject to system permissions).

A unified HMI

The composition manager allows developers to create of a separate pane for the output of each rendering engine (HTML5, Qt, Video, or OpenGL ES). Each frame buffer can be transformed (scaling, translation, rotation, alpha blend, etc.) to build the final display.

To build the display as optimally as possible, whenever possible the composition manager uses GPU accelerated operations, falling back on software only when the hardware cannot satisfy a request.

The image below shows how each application that supplies a portion of the HMI allocates a separate window and frame buffer from the composition manager:

• An HTML page provides the background wallpaper and navigation controls
• iPod Out, which digitizes a video capture chip into a frame buffer, brings in analog video from an iPod or iPhone
• The underlying OpenGL ES map rendering software builds the navigation display on the right
• Qt overlays the navigation control on the navigation display