Monday, November 28, 2016

Evolving into a Domain Controlled World

Thomas Bloor

Business Development Manager, BlackBerry

In 1859, Charles Darwin set out his theory of evolution by natural selection. He defined natural selection as the "principle by which each slight variation [of a trait], if useful, is preserved." The concept is simple but powerful: individuals best adapted to their environments are more likely to survive and reproduce.
Of course, the unspoken corollary is that species with extremely short lifespans, such as insects, will be more successful as they get to go through more evolutionary cycles and adapt to changes in their environment faster. Anyone who has seen the movie “Jurassic Park” knows that while the dinosaurs died out, the mosquitoes essential to the plot evolved and survived to annoy us even today.

A similar evolutionary challenge plagues automotive, with product cycles spanning three years or more, we struggle to keep up with the faster evolution of smartphones whose consumer driven life cycles can be as short as only twelve months. Now as we look forward to the fully autonomous car it’s obvious that car makers and suppliers who can adapt and evolve faster will win in these new markets. This is especially true because cars are becoming more and more software-defined.

In order to contain the rapidly rising cost of electronics innovation in the car, the industry is looking towards consolidating functions into a number of domain/area controllers that will evolve from today’s complex arcchitecture  based upon an increasing number of Electronic Control Units (ECUs) scattered throughout the vehicle.
Automakers are currently racing to bring new innovations into the car across Infotainment, Driver Assistance, Autonomous Driving, and other things.  The winners in this race will be the companies with the ability to evolve their products faster, while tackling the challenges of safety, security, and escalating system costs.

Evolving the Vehicle Architecture
With the advent of technologies such as virtualization, the industry is looking at making the first evolutionary steps towards a consolidated domain/area controller architecture. Some forward thinking automakers are looking to a flexible and scalable vehicle architecture that can be configured to support entry to premium level applications by varying the number and configuration of domain/area controllers in the vehicle and the software they run.

Now this will not be a one step process. Consolidation of systems into these domain/area controllers will be a process that takes place over several generations as the interfaces and communications become more standardized within the vehicle architecture. The ability to flexibly compile functions into different build configurations will then depend on a unified software architecture, so the choice of software architecture and platforms will become a strategic decision that can enhance flexibility and time to market. Conversely, the wrong decision, or no decision, on a consolidated software platform can slow product evolution and flexibility and potentially lead to extinction. 

Key here is the selection of a software environment that is capable enough to be the foundation across the range of applications such as infotainment, driver assist or even autonomous drive

Automakers or Tier 1 suppliers that create a unified operating system environment across multiple functions within the car will be able to consolidate faster, and with more flexibility, by avoiding the penalties of increased cost and time to market when consolidating systems with disparate software environments.

As security continues to be in the public mind, automakers are facing the reality as in corporate IT that security will evolve continuously as vulnerabilities are identified leading to a process of patch issuing that need to be applied over the lifetime of the car.

Now with a fragmented operating system environment, security costs escalate as each operating system will have its own vulnerabilities and security flaws. An entry point for a hacker can be anywhere in the car, making automotive security a system level issue that necessitates an automaker to identify and fix security vulnerabilities across all operating systems in the car. 

As the electronic modules within the car are supplied by multiple Tier 1s, ensuring system level security of the complete automobile becomes a challenge for the automaker, requiring penetration testing of the complete car. With this reality a unified operating system environment is better and simply more secure. While we may never get to a single operating system in the car consolidating from the 6 to 8 in use today to 3 or 4 is a realistic objective.

Future Proofing
The auto industries' traditional business model is being challenged by the need to quickly evolve the features in their products. Cars were traditionally sold with fixed functionality with no concept of upgradeability of electronic systems. This is changing with advent of connectivity. Manufacturers such as Tesla, who is a leader in the industry when it comes to remotely upgrading the software in their vehicles remotely.
Such remote over the air upgradeability is constrained by today’s distributed ECU architectures as each ECU performs a fixed function with defined outputs, with only limited elements of the system having the ability to be upgraded. Moving forwards, a more consolidated domain/area controller archtecture with an advanced Over the Air (OTA) update capability will enable automakers to maintain and upgrade systems in the field a lower cost than traditional software recalls.  

Unified Solutions
Known as the market leader in Infotainment and Telematics software, QNX provides a unified operating system and suite of products that help solve the challenges of the fragmented operating system environments found within today's vehicles. A family of solutions branched off of a common core ensures efficiency in investments while enabling the flexible scalable domain/area controller architectures of the future.

With a new paradigm appearing in automotive security QNX is positioned to  provide the basis of the next generation of safe and secure vehicle systems. True type 1 hypervisor solutions enable the flexibility to host cluster and infotainment functions within a single domain/area controller, while meeting ASIL requirements for the driver display. The same technology enables hosting of separate operating systems such as adaptive Autosar to extend lower body domain/area controller functionality and enable a truly flexible vehicle architecture. 
The need to evolve vehicle architectures will place critical importance on the choice of operating systems and software in the car. Over the air updates, safety and security robustness, and overall flexibility will be critical attributes determining the success or failure of automotive software environments. 

With over two decades of automotive software experience, BlackBerry-QNX is used in more than 60 million vehicles today across infotainment, telematics, advanced driver assist, vehicle control, and over the air updates. 

Looking towards the Consumer Electronics Show in Las Vegas in January we will be demonstrating any of these technologies in our demo cars. Evolving architectures with the benefit of thirty years of experience QNX is the software platform that can enable consolidation, feature evolution, safety and security at lower overall cost in response to the changing needs of the automotive industry.

Monday, October 24, 2016

Autonomous Cars – Part 3: Technology Consolidation

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

The amount of software in a car is mushrooming with there being 100 to 150 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:

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