BlackBerry QNX Partners with Obigo to Build a Better Browser for Your Car

John Wall

Senior Vice-President and Head of QNX Software Systems

 

  

Software plays a big role in current vehicles. The best example is your in-vehicle infotainment system. With just a few taps, you can play music from your mobile device, view and manage advanced navigation systems, make phone calls, tap into traffic reports and weather forecasts, all from your car’s center display console. Drivers and passengers love these systems and are dependent on them. However, Infotainment has its own challenges to address. Security aside, the infotainment system needs to be able to provide support for the latest and greatest web browser technology to give the users access to the content they want the instant they want it, whether on the web or off. You do not, after all, want to be fumbling with an unresponsive display when you are on the road.

At BlackBerry, we are constantly seeking ways to improve the vehicle cockpit experience and to enhance our QNX CAR Platform for Infotainment (QNX CAR). This is why we are proud to announce our partnership with Obigo a leading Korea-based provider of mobile Internet services and browser software. Obigo is working with is to deliver a powerful, Chrome Blink-based HTML5 engine, which will enhance the browser experience of your infotainment systems.

As part of the agreement, our internal HTML5 team will be augmented by Obigo’s team of experts who will help to optimize the latest Blink browser technology with QNX CAR (pictured). QNX CAR, our best in class Infotainment system, has more than 50% global market share and is present in over 60 million vehicles. With QNX bringing this new browser to market, vendors and manufacturers can enrich their driving experience through new applications and services, and drive further customer satisfaction.

“Many automotive OEMs and Tier-1s still view open source HTML browsers as lightweight,” explains Obigo CEO David Hwang. “With almost two decades of browser experience on embedded systems, we have been working to change those perceptions with highly optimized technology that address open source browser performance issues. Working with BlackBerry-QNX, we plan to develop a product that will boost interest in HTML5 technology for emerging in-vehicle applications and services.”

Obigo’s technology will also simplify the coding of HTML 5 browsers for new infotainment systems and accelerate the product development cycle. Obigo joins the ecosystem of BlackBerry QNX partners that collectively offer the best-in-class system level solution for our infotainment customers.

From Concept to Reality: BlackBerry-QNX's Groundbreaking CES Tradition

Thomas Bloor
Business Development Manager, QNX BlackBerry

The annual Consumer Electronics Show in Las Vegas has been growing in importance for the automotive industry over the years. You can hardly fail to notice that this year, as in previous years, the big automakers vie for floor space and attention with the glut of big screen TVs and other consumer goods. As always, BlacBerry QNX will be in the North Hall, proudly in the middle of the big automotive OEMs. 

At CES BlackBerryQNX has an enviable history of bringing concept cars that rival anything on the show floor, with one important difference – ours are not pure flights of fancy, and we show technologies that will become realities in the near future.

We started this trend back in 2010 with an LTE-connected Toyota Prius – 18 months before the first commercial LTE deployment in mid-2011. Working with Alcatel-Lucent to provide the experimental network, we demonstrated Google maps functionality with local search and an embedded Pandora radio app in a car for the first time. Connectivity is standard in many cars today, but in 2010 we demonstrated the future.

2012 brought us a CNET "Best of CES" award for demonstrating cloud-based natural language voice recognition, text-to-speech, and NFC based one-touch Bluetooth pairing.  Simply touching your phone to an NFC reader in the center console automatically paired the phone and car. 

In 2013 we got ahead of the trend for ever larger center stack displays – with detailed 3D maps and voice recognition Keyword Spotting – common today in smartphones but a first in a car. Simply saying "Hello Bentley" enabled you to start interacting with the natural language cloud based voice recognition Powered by AT&T’s Watson. 

2014 took literally us in a different direction. A 21-inch horizontally orientated center stack display extends across the dash, naturally extending the interaction and functionality towards the passenger.  Behind the screens the instrument cluster was integrated with the center stack running both driver information and IVI functions. With seamless controllability across the touch screen, physical buttons, and the jog wheel controls multi-modal input was highlighted across all available functionality. 

Not content with that, we foreshadowed greater integration of ADAS functionality warnings to the driver. In 2014 we warned the driver if local speed limits were exceeded through both the cluster and verbally through text-to-speech, and we followed this up in 2015 with a system that recommends an appropriate speed for upcoming curves based upon driving conditions and the radius of the bend.

So, what innovations will we be showing in 2017? I’m not allowed to tell you just yet but, in a first (for us), we’ll be showing both future and current production technologies and innovations.

Building on our products ranging from in-car acoustics through our comprehensive QNX-CAR application platform and to next generation driver assistance/autonomous drive we will be demonstrating how technology can enhance the user experience and increase safety for drivers and passengers.

While demonstrating technologies that will come to future production vehicles, these cars are not just "show floor wonders" because our automotive knowledge enables us to build demonstrators for the real world, which can be driven, thus allowing technologies to be experienced first-hand.

Holistic Security for the Software-Defined Car

Bill Boldt
Sr. Business Development Manager, Security
Blackberry Certicom

Due to high profile hacks on cars, it is hard to argue that without security you can have safety.   So, security is emerging as perhaps the most important factor in the evolution of the connected autonomous car.
 
Cars are the most software intensive systems in the universe with far more lines of code than even a state of the art jet fighter. By being such complex digital systems they have become prime targets for attack, and that is where cryptographic countermeasures come in.

Connecting the dots – in the emerging software-defined world safety increasingly
comes from security and security comes from cryptography. Robust cryptographic security implementation is how you increase trust, and when it comes to a car every system must be
trusted: inside the car, in the smart infrastructure, in emerging applications-based ecosystems, and in the manufacturing supply chain. When considering automotive security,
many factors come into play. Some are noted here:
                       

• Automotive security fundamentally depends on the security of the operating system. For example, a microkernel architecture that separates critical OS components into their own protected memory partitions, provides temporal separation, and provides network security, among other things can greatly reduce the attack surface.

• Security assets (crypto keys, serial numbers, etc.) must be securely installed into electronic devices such as Electronic Control Units (ECUs), domain/area controllers, and other processors. This process is called "personalization".

• Electronic devices will often get personalized and installed into vehicles in globally located factories, which should utilize secure equipment and processes to ensure security of the devices.

•  Devices must be updateable at dealers and repair shops. 

• Aftermarket suppliers must be able to sell and update secure devices, and

• OEMs must be able to authorize or not authorize specific electronic devices at
  manufacturing time and after the car is in use (for example to enforce warrantee policies).
  

And, there are many more.


Personalizing a device such as a networked ECU means that it will become one of a kind. However, by definition that device cannot be used anywhere else. It becomes a unique stock keeping unit (SKU), which is averse to the purpose of flexible, just in time manufacturing flows. Security versus manufacturing flexibility is a serious trade off that will play a part of any automotive security design decision.

Security robustness versus cost is another critical trade off, and applies to the manufacturing infrastructure and the design of the secure systems inside and outside the vehicle. Because security must be injected in the factory and in the field, a secure manufacturing system must have global reach, be manageable on a distributed basis, be updatable by various entities, and remain secure for years. In addition, security updates will increasingly be made over the air, and the systems that do that must by highly secure while being easy to manage. To maintain the maximum amount of flexibility, personalization and updating should be moved as close as possible to the very last minute, which is becoming a critical objective of the global manufacturing blue print. 

Blackberry Brings It All Together

In the car, outside the car, and in the manufacturing supply chain, security must be designed with best practices in mind right from the start, and BlackBerry Professional Services can help with that. BlackBerry QNX provides mission-critical automotive software proven in the automotive market.  QNX software is well known for safety and new products are setting the new standard for security.

BlackBerry's Certicom subsidiary provides certified cryptographic code and design consulting, as well as secure equipment and managed services that harden the automotive supply chain. Completing the picture, BlackBerry's secure OTA managed services make it easy to update software and security assets over the air. When it comes to automotive security, BlackBerry brings it all together.

Autonomous Cars Part 1-- And Now for Something Completely Different: The Autonomous Accident

Kaivan Karimi
SVP of Strategy and Business Development
BlackBerry Technology Solutions (BTS)

A few weeks ago a self-driving Tesla Model S in Autopilot mode crashed into a large semi-trailer in Williston Florida.   This is pretty much what lawyers call a case of first impression, and rightfully so.  This unprecedented event brought up a bunch of questions, and it is clear that we are now on the cusp of the autonomous (i.e. robot-driven) automotive future.  With that comes a completely different mix of risks, liabilities, safety concerns, responsibilities, ownership models, insurance platforms, and regulatory oversight. 

Car crashes are, and should be, a big deal. They are the number one reason for death among young people and number five overall, claiming over 32,000 American lives each year. Some news outlets have questioned the sanity of allowing driverless cars on the road all together. Fairly or unfairly, the whole notion of driverless cars is experiencing knee-jerk reactions. It is easy to see why the first known death caused by a self-driving car in the history has focused everyone’s attention on autonomous vehicles.

This incident is much like how Bridget Driscoll made the history in 1896 by being the first pedestrian being struck and killed by a gas-powered car (at a top speed of four miles per hour).   Thanks to the sensationalism of the press, the Florida crash got much more coverage in the news cycles than the more positive story about the Missouri man who used his Tesla Model X in autopilot mode to get to the hospital when he suffered from a debilitating blood clot on the highway.  Tesla Autopilot saved his life, and that is real (and good) news.  Nothing like that has happened before—a robot saving a man’s life.  Amazing.

These issues have made so much headlines that it made it to the white house, and president Obama wrote an op-ed mostly in support of the technology.  President Obama wrote that safer, more accessible driving, and less congested, less polluted roads are what harnessing technology for good can look like referring to self-driving car technologies. He also said that we have to get it right. Americans deserve to know they’ll be safe today even as we develop and deploy the technologies of tomorrow.

The accident has given rise to discussions about what types of sensors should have been in place to avoid that accident.  Also, as you would expect, there is a lot of questioning by legislators about the need for such technology, and how it can be regulated. A proper outcome of the crash has been awareness that autonomous driving is a public safety issue.  This is multi-faceted and includes technology (i.e. hardware, software, and architecture), economics, policy implementation, liability, and oversight factors.

I started following the development of autonomous vehicles when I first heard about Google’s so-called “self-driving car” project back in 2009. While I knew about DARPA’s initiative around this idea in mid 2000s, a commercial entity like Google picking up the project lends real credibility. Back in the 2010-2011 timeframe, my team and I were working on Freescale’s MCU strategies, and through that I got to understand the role of Active Driver Assistant System (ADAS) and the numerous architectural considerations and technologies needed to make autonomous driving a reality. 

Now at BlackBerry, I am working with our QNX software team on ADAS development. The QNX perspective, of course, comes from the software side with expertise in instrument clusters, functional safety, hypervisor  infotainment, and telematics. When you add that to  Certicom’s cryptographic security expertise,  and BlackBerry’s Over-the-Air (OTA),  updates for automotive security life cycle management, you have what you need for safety and security of the software-defined autonomous future. The evolution to connected autonomous vehicles is transitioning through different stages that in fact were defined by the U.S. Department of Transportation's National Highway Traffic Safety Administration. SAE has defined levels as well.  

                                                          

                                                           Source: NHTSA

Most car OEMs that we are working with have autonomous driving pilot programs in place. That is no surprise.  Even before the Tesla Autopilot accident, it was hard to open a technology magazine or website and not see a mention of self-driving cars and various pilot programs around the world. Cars are becoming cool again due to new technological evolution.   This is similar to how cellphones became cool in the early 2000s when the emergence of 3G made the notion of smartphones real.   Cars are much more than a phone, obviously, and the sky is the limit.  Software, semiconductor, networking, cryptography, sensors, communications, electric/hybrid engine, charging, display, augmented reality, smart highways, retail, and other technologies all converge on the car platform.  These things are quickly redefining the car, the highway, ownership models, insurance, and society itself. 
 
Some of the items to consider are the forms that vehicles will adopt due to automation, such as autonomous cars,  to  self-driving busses  , self-driving trucks,  and DARPA’s 132-foot long Sea Hunter unmanned Submarine-Hunter Drone .

Hardware + Software

Self-driving vehicles, or self-propelled anything, are based on an intimate relationship between electronics hardware and software to create not only a perceiving, processing, and actuating system, but a system that is safe, secure, and reliable.   While that last part seems obvious, it is not all that easy to accomplish.   Safety, security, and reliability come only from careful design based upon experience—experience that can make hardware and software work seamlessly.
 
Starting with the hardware, if you look at automotive microprocessors and microcontrollers, you can see that their complexity has skyrocketed to meet real time requirements of active safety elements such as vision processing, sensor fusion, and control algorithms, while still maintaining stringent power budgets.

Advanced driver assistance systems (ADAS) are the backbone of autonomous vehicles, obviously, and that it is based upon multiple application cores and hardware accelerators.   ADAS, software platforms must provide high performance by combining symmetric multiprocessing on application cores with support for built in accelerators such as vision processing engines or graphics processing units (GPUs).   Examples of applications range from four camera surround view systems, to a single camera forward facing collision avoidance system, to a sensor fusion hub.
Of course, the most important aspect of anything automotive is safety.  The old adage of safety first is still valid, and getting even more so as robotic cars start to drive themselves.  Therefore, there has to be real safety know-how at the core of the design and implementation of ADAS.  This is where safety standards compliance comes in.  The QNX Platform for ADAS is a great example of safety-centered software for the autonomous car.   The platform is certified by TÜV Rheinland to ISO 26262 ASIL-D.

More details will be addressed in a future blog, but are presented here to illustrate that software must be compliant with safety standards if it is to be taken seriously.  How safety is achieved by a software architecture is by ensuring that system faults in one area do not affect other areas.   This is accomplished by using a microkernel architecture the operating system (OS) to create isolation of failed components, and allowing them to be restarted dynamically while the rest of the system continues to operate. This type of adaptive partitioning technology safeguards the operation of the safety-critical components by ensuring they are never starved of CPU cycles. With a microkernal approach, traditional OS services can be contained in separate, hardware-protected address spaces in the same manner as applications.

The next blog will focus on the individual subsystems used in an ADAS platform in the connected autonomous car.    In addition, other connected autonomous car technologies will be covered in subsequent blogs, including security, Domain/Area-controller evolution, more about safety, and other technologies needed, plus use-case and financial considerations related to autonomous cars.   The story of the software-defined automotive future is just starting to be written.   For more see the QNX web site.

 

_____________________________________________________________________________

Kaivan Karimi is the SVP of Strategy and Business Development at BlackBerry Technology Solutions (BTS). His responsibilities include operationalizing growth strategies, product marketing and business development, eco-system enablement, and execution of business priorities. He has been an IoT evangelist since 2010, bringing more than two decades of experience working in cellular, connectivity, networking, sensors, and microcontroller semiconductor markets. Kaivan holds graduate degrees in engineering (MSEE) and business (MBA). Prior to joining BlackBerry, he was the VP and General Manager of Atmel wireless MCUs and IOT business unit.