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.

Autonomous Cars – Part 3: Technology Consolidation

Kaivan Karimi
SVP of Strategy and Business Development
BlackBerry Technology Solutions

The amount of software in a car is mushrooming with there being over 100 million lines of code in a modern car, which is more than most any other system.

Today cars are controlled via hardware electronic control units (ECUs) running the millions of lines of code.   60 to 100 ECUs are found in most newer cars today and that number is growing.  High end cars can have even more.  Reducing the number of ECUs in favor of reduced number of domain/area controllers is the new trend.  The idea is to reduce the complexities associated with software development, reduce the weight of the car, and reduce the overall cost. It also makes software upgradability less complex, where software functionalities can be enhanced to extend the life of a platform and offer a very large return on investment. 

Another benefit is that software can be more easily upgraded Over-The-Air (OTA) for minor or major fixes, respond to security issues, and provide other enhancements without the need to bring a car to the dealership.  This not only saves time, but also adds to the safety, security, and reliability of the car, while lowering the overall maintenance cost for the vehicle. According to research firm IHS, about 4.6 million cars received OTA software updates for telematics applications last year, and by the year 2022 forty-three million cars are expected to be using OTA services.  That is clearly a huge increase.

Some of the other technology components of Advanced Driver Assistance Systems (ADAS) are noted below:

Maps

While most people do not consider maps as a component of an ADAS system, in the future they will play a key role in assisting drivers to operate vehicles safely and adapt to driving changes based on location, such as changing what side of the road you drive on when you hit a border crossing. Maps provide a necessary input to augment the information that is provided by the various sensors in the car. This is not just macro-level geological data for finding directions, but also for augmenting functions such as camera-based traffic sign and roadway information detection, as well as infrastructure information. Cloud based processing will then be used to integrate the data sent by all vehicles into a global map that gets updated cooperatively by all drivers, including the road pot-holes to avoid, new roadway signs added, or rerouting due to construction.

Sensor Fusion

Sensor fusion means combining information and data from different sensors, leveraging the individual advantages of each sensor to complement and cover the weaknesses other sensors. The whole is greater than the sum of the parts, which means the individual sensors’ functions. This is very similar to what our brain does. You do not need to touch a pot of boiling water to know it is very hot, because your eyes to see the bubbling water and the steam on the top of the pot. In an ADAS system, the same thing happens: The sensor inputs are fused together for the ADAS domain controller to formulate a conclusive opinion about an event with better situational awareness, rather than just relying on a certain sensor’s data individually. This notion is at the heart of how any robot operates, but is especially important with the mission critical functionalities needed by connected autonomous cars.

HW & SW Roadmap to Consolidation

As the modern CPU increases in processing power, and decreases in electrical power consumption due to smaller process geometries, it would lead one to believe that consolidating multiple ECU functions onto one physical processor may result in significant cost savings. While that is true, consolidation needs to be balanced with a few important factors:

1.  The increase in leakage current as semiconductor process geometries get smaller (this is a downside of Moore’s Law) 
2. Thermal issues increase as clock speeds increase 
3. The extent to which the software can be multithreaded to take advantage of new multi-core  processors.

The auto industry will be going through a transformation with ECU consolidation into single powerful multi-core processors that is similar to what happened in early 2000s in the networking industry.  At that time I had a front seat to the networking debate as I was driving some products a large semiconductor company. What happened was that most network and baseband processor semiconductor suppliers for both wired and wireless infrastructure business moved from single to dual to quad-core processors.  I remember a day when people were planning to pack as many as 80 cores into a single chip.

There is a huge difference between the software requirements for mutli-core processing in the networking and automotive industries.  

The elephant in the automotive room is the need to combine mission-critical with non-mission critical functionalities into the same processor, while separating and isolating these functions effectively from each other from a safety and security perspective. This single fundamental requirement becomes the basis for what types of software framework and architecture needs to be used.

Multi-core Processing

At a very high-level, all multi-core processors pack multiple processing units (cores) into a single    physical package—just like it sounds. But, this is where the similarities end. Other architectural factors come into play and determine the application fit, throughput, bandwidth, effective horsepower, and software architectures suitable for an optimal processing environment. Some of the considerations are noted below:

• Choice and configuration of interconnect buses and shared memory schemes

• Choice of homogeneous multi-core systems with identical cores sharing the same instruction sets, vs. heterogeneous multi-core systems with identical cores (some with same instruction set, and some with different ones 

• Heterogeneous multi-core systems that mix different types of processor cores for application specific use cases (e.g. mix of MPUs, DSPs, GPUs, etc.).

• Mix of the above core with localized memories and predefined high-level functions such as micro-coded engines and vector processors

• Mix of cores and architectures that allow control and data path processing in a single core for communication applications 

• Choice of architectural implementations such as VLIW, vector or multithread processors, fine-grain vs. coarse grain processors, etc.

The improvement in performance by using multi-core processors can only happen if the software running on the processor can take advantage of every last cycle that the multiple core device can offer. It also assumes that the interconnect buses and interfaces between the cores and the world outside of the chip, as well as between the cores, and the interaction between the cores and the memory architecture are properly modeled and designed for the end application, so that there are no design bottle necks introduced. 

This situation is analogous to adding multiple streets and multiple lanes in and out of a parking lot. If the electronic door to go in and out of that parking lot is too slow to accommodate the extra traffic, you will cause bad congestion, and the traffic throughput in and out of the parking lot would be as good as the speed of that electronic door. You may need to open the gate altogether, but have a traffic cop that coordinates the flow of traffic in and out of different entrances, into different parking spots. That is exactly what you would also need in the world of software, namely a traffic cop for the processes running in the given multi-core architecture. That is where a hypervisor comes in, which is to act as that traffic cop.

QNX offers a hypervisor and other safety- and mission-critical software for make connected autonomous cars safe reliable, secure, and trusted.

The next blog will address the hypervisor/traffic cop, and describe how they make the software-defined future more autonomous and safe.

                                                  

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's wireless MCUs and IOT business unit.

The Automotive Shift to Software-Defined, Consolidated Controller Architectures

Thomas Bloor

Automotive Business Development Manager
BlackBerry QNX

Electronics in the car have come a long way from the first in-car radio in 1930, and 1978 when Mercedes-Benz introduced the first production car with an optional electronic four-wheel multi-channel anti-lock braking system (ABS) from Bosch.

Today, according to Manfred Broy, a professor at the Technical University of Munich, the cost of electronics and software has increased to 30% of a car's bill of materials. He estimates that 90% of new innovations now come from electronic systems in the car, and projections indicate the cost of electronics will surpass 50% in ten years as we move towards more advanced driver assist and fully autonomous functions in the car. These costs are driven by the electronic architecture of the modern car.

If we were to examine a modern luxury vehicle we would find a very complex interconnected network of between 60 to 100 electronic control units (ECUs) in aggregate running between 6 to 8 different operating systems with around 100 million lines of code. The distributed automotive computing architecture has evolved over many product generations as new features and innovations have been added though new hardware modules. This approach has served the industry well, but being faced with rising costs from more complex infotainment and new driver assist systems the existing model is becoming inefficient and a drag on bringing new features and innovations into the car. Complexity presents serious challenges, not the least of which are safety and security.

Additionally, the vision of urban mobility that will utilize fully electric autonomous cars has brought new competitors to the industry. These new entrants are rooted in hi-tech and are entering the automotive industry with the opportunity to architect the car from a clean sheet. Unencumbered by the burdensome legacy of traditional automotive manufacturers face,  the newcomers are architecting vehicle systems by leveraging advances in silicon technology to make designs with a smaller number of consolidated controllers with larger processing capabilities.

The evolution to these new consolidated controllers will provide a number of cost benefits. According to a study by Roland Berger associates, consolidated controllers will provide $110 of direct cost savings from hardware consolidation alone. An additional $65 of secondary savings will come from a reduction in software licensing and tools. The study did not quantify savings from software reuse, but positioned reuse as the unseen bulk of the iceberg under the water. As software development costs are often the largest single item in terms of time and manpower, a development savings in the software domain can dwarf the $175 of savings quantified by the researchers.

So, both the new entrants and established companies within the industry are moving towards a domain or area controller architecture – consolidating functions into a smaller number of more flexible processing nodes within the vehicles architecture. This consolidation opens the possibility of reducing the number of operating systems in the car to three or four and the total number of controllers to between six to ten.

This enables a more flexible architecture with a high degree of reuse of the software code base between the different domain/area controllers. In turn this allows the complete vehicle architecture to be built in a flexible manner, enabling the same code base to be reused across generations and differing variants within a model range. 

This more efficient vehicle architecture provides benefits such as reducing the number and duplication in development tools and the associated costs. Developers benefit as deeper experience in a smaller number of operating systems will reduce training requirements and improve developer skills and efficiency.  Reducing overall complexity also improves security and safety, because fewer attack surfaces are presented to a hacker with malicious intent, and  it focuses resources to find and fix security vulnerabilities in a smaller number of operating systems.

So, you can probably see that the auto industry is entering a revolutionary period in vehicle architecture.  Vehicle electronics will consolidate, and with that automakers and Tier 1s have the opportunity to build consolidated, adaptable software environments to speed time to market and enable multiple model variants to be derived from a common code base.  To realize the benefits of these changes a software architecture that is applicable across the majority of vehicle functions is desired. 

The choice of an operating system that enables increased reuse and has proven quality and reliability provides a valuable foundation upon which this architecture is built.  Wide applicability guides the choice to an operating system that is capable of providing mission-critical reliability and security for advanced driver assist (ADAS)and autonomous drive functions, while also being capable of underpinning consumer facing infotainment solutions.

BlackBerry's QNX subsidiary has a long history of underpinning the majority of autmotive infotainment systems in production today.  That is in no small part because QNX's common code base supports both safety OS and infotainment requirements, which provides an advantage in developing, reusing, and productizing code across safety and non-safety certified domains.   QNX recognizes that automakers may want to build mixed ASIL environments in their consolidated controllers as well as consumer infotainment offerings such as those from Google or other sources, so we built QNX’s hypervisor solution.

Availability of safety certification on the hypervisor with no changes adds flexibility and reduces development costs as ASIL certification can be completed after the code is partitioned between controllers, knowing that the underlying software complies with ISO26262. This enables a cockpit controller running a cluster application to have mixed ASIL A and B partitions in its software, and combine these in different informational zones in the same display. The obvious example being cluster gauges and navigational maps being displayed side by side with both partitions being run on a single processor.

Running this type of mixed environment requires full separation and isolation between domains and a safety certified hypervisor solution.  With QNX’s safe, secure, and reliable software solutions you can build an adaptable and dependable vehicle architecture. With safety certification available without the need for code base changes you can develop flexibly with the knowledge of being able to achieve ASIL certification where required.

The changes in vehicle architectures towards more consolidated domain/areas controllers enables am evolution in the software development methodology for the car, namely a shift to a continuous platform development methodology that will enable automakers to compete with new entrants from the high-tech world.  The new architectures will also allow the increased complexity of vehicle systems evolve safety and securely as we move towards the fully autonomous car. 
 

The ability to drive a flexible architecture and derive multiple vehicle platforms from a common code base and set of hardware controllers will be a competitive advantage to automakers and Tier 1s who embrace this approach.  They seem to already know that. Additional benefits of this approach include cost reduction and time to market acceleration stemming from reuse and improved security through the elimination of attack surfaces and the ability to embed cryptographic countermeasures security into the more capable controllers and ECUs.

This may be quite a challenge but we see many automakers and Tier 1s today accepting the challenge and adopting these practices.