Cyber security and connected cars

What does cyber security mean, what does it affect, why is it becoming critical, and what can you do about it? Those were some of the questions I addressed in a recent webcast on automotive cyber security, hosted by SAE International. I represented the software side of things and was accompanied by my hardware colleagues Richard Soja and Jeffrey Kelley, who work at Freescale and Infineon respectively.

I’ve hosted webinars on a variety of automotive and embedded software topics, but none with such an impressive range of participants. We had people from government organizations of several countries, not to mention automakers, tier 1 and tier 2 auto suppliers, telematics companies, mobile developers, concerned individuals, and even utility companies. And the range of questions and comments was equally diverse — from specific insights about elliptical encryption to sweeping “how does this affect society” musings.

My key takeaway: QNX isn’t alone in its concern for automotive cyber security. We have years of experience in building secure trusted systems and we’re excited to help customers build tomorrow’s secure cars. Nice thing is, the rest of the world is starting to get on board as well.

If you're interested, you can download the archived version of the webinar.

Top 10 challenges facing the ADAS industry

Tina Jeffrey

It didn’t take long. Just months after the release of the ISO 26262 automotive functional safety standard in 2011, the auto industry began to grasp its importance and adopt it in a big way. Safety certification is gaining traction in the industry as automakers introduce advanced driver assistance systems (ADAS), digital instrument clusters, heads-up displays, and other new technologies in their vehicles.

Governments around the world, in particular those of the United States and the European Union, are calling for the standardization of ADAS features. Meanwhile, consumers are demonstrating a readiness to adopt these systems to make their driving experience safer. In fact, vehicle safety rating systems are becoming a vital ‘go to’ information resource for new car buyers. Take, for example, the European New Car Assessment Programme Advanced (Euro NCAP Advanced). This organization publishes safety ratings on cars that employ technologies with scientifically proven safety benefits for drivers. The emergence of these ratings encourages automakers to exceed minimum statutory requirements for new cars.

Sizing the ADAS market
ABI Research claims that the global ADAS market, estimated at US$16.6 billion at the end of 2012, will grow to more than US$260 billion by the end of 2020, representing a CAGR of 41%. Which means that cars will ship with more of the following types of safety-certified systems:



The 10 challenges
So what are the challenges that ADAS suppliers face when bringing systems to market? Here, in my opinion, are the top 10:

1. Safety must be embedded in the culture of every organization in the supply chain. ADAS suppliers can't treat safety as an afterthought that is tacked on at the end of development; rather, they must embed it into their development practices, processes, and corporate culture. To comply with ISO 26262, an ADAS supplier must establish procedures associated with safety standards, such as design guidelines, coding standards and reviews, and impact analysis procedures. It must also implement processes to assure accountability and traceability for decisions. These processes provide appropriate checks and balances and allow for safety and quality issues to be addressed as early as possible in the development cycle.
    
2. ADAS systems are a collaborative effort. Most ADAS systems must integrate intellectual properties from a number of technology partners; they are too complex to be developed in isolation by a single supplier. Also, in a safety-certified ADAS system, every component must be certified — from the underlying hardware (be it a multi-core processor, GPU, FPGA, or DSP) to the OS, middleware, algorithms, and application code. As for the application code, it must be certified to the appropriate automotive safety integrity level; the level for the ADAS applications listed above is typically ASIL D, the highest level of ISO 26262 certification.
    
3. Systems may need to comply with multiple industry guidelines or specifications. Besides ISO 26262, ADAS systems may need to comply with additional criteria, as dictated by the tier one supplier or automaker. On the software side, these criteria may include AUTOSAR or MISRA. On the hardware side, they will include AEC-Q100 qualification, which involves reliability testing of auto-grade ICs at various temperature grades. ICs must function reliably over temperature ranges that span -40 degrees C to 150 degrees C, depending on the system.
    
4. ADAS development costs are high. These systems are expensive to build. To achieve economies of scale, they must be targeted at mid- and low-end vehicle segments. Prices will then decline as volume grows and development costs are amortized, enabling more widespread adoption.
    
5. The industry lacks interoperability specifications for radar, laser, and video data in the car network. For audio-video data alone, automakers use multiple data communication standards, including MOST (media-oriented system transport), Ethernet AVB, and LVDS. As such, systems must support a multitude of interfaces to ensure adoption across a broad spectrum of possible interfaces. Also, systems may need additional interfaces to support radar or lidar data.
    
6. The industry lacks standards for embedded vision-processing algorithms. Ask 5 different developers to develop a lane departure warning system and you’ll get 5 different solutions. Each solution will likely start with a Matlab implementation that is ported to run on the selected hardware. If the developer is fortunate, the silicon will support image processing primitives (a library of functions designed for use with the hardware) to accelerate development. TI, for instance, has a set of image and video processing libraries (IMGLIB and VLIB) optimized for their silicon. These libraries serve as building blocks for embedded vision processing applications. For instance, IMGLIB has edge detection functions that could be used in a lane departure warning application.
    
7. Data acquisition and data processing for vision-based systems is high-bandwidth and computationally intensive. Vision-based ADAS systems present their own set of technical challenges. Different systems require different image sensors operating at different resolutions, frame rates, and lighting conditions. A system that performs high-speed forward-facing driver assistance functions such as road sign detection, lane departure warning, and autonomous emergency breaking must support a higher frame rate and resolution than a rear-view camera that performs obstacle detection. (A rear-view camera typically operates at low speeds, and obstacles in the field of view are in close proximity to the vehicle.) Compared to the rear-view camera, an LDW, AEB, or RSD system must acquire and process more incoming data at a faster incoming frame rate, before signaling the driver of an unintentional lane drift or warning the driver that the vehicle is exceeding the posted speed limit.
    
8. ADAS cannot add to driver distraction. There is an increase in the complexity of in-vehicle tasks and displays that can result in driver information overload. Systems are becoming more integrated and are presenting more data to the driver. Information overload could result in high cognitive workload, reducing situational awareness and countering the efficacy of ADAS. Systems must therefore be easy to use and should make use of the most appropriate modalities (visual, manual, tactile, sound, haptic, etc.) and be designed to encourage driver adoption. Development teams must establish a clear specification of the driver-vehicle interface early on in development to ensure user and system requirements are aligned.
    
9. Environmental factors affect ADAS. ADAS systems must function under a variety of weather and lighting conditions. Ideally, vision-based systems should be smart enough to understand when they are operating in poor visibility scenarios such as heavy fog or snow, or when direct sunlight shines into the lens. If the system detects that the lens is occluded or that the lighting conditions are unfavorable, it can disable itself and warn the driver that it is non-operational. Another example is an ultrasonic parking sensor that becomes prone to false positives when encrusted with mud. Combining the results of different sensors or different sensor technologies (sensor fusion) can often provide a more effective solution than using a single technology in isolation.
    
10. Testing and validating is an enormous undertaking. Arguably, testing and validation is the most challenging aspect of ADAS development, especially when it comes to vision systems. Prior to deploying a commercial vision system, an ADAS development team must amass hundreds if not thousands of hours of video clips in a regression test database, in an effort to test all scenarios. The ultimate goal is to achieve 100% accuracy and zero false positives under all possible conditions: traffic, weather, number of obstacles or pedestrians in the scene, etc. But how can the team be sure that the test database comprises all test cases? The reality is that they cannot — which is why suppliers spend years testing and validating systems, and performing extensive real-world field-trials in various geographies, prior to commercial deployment.
     

There are many hurdles to bringing ADAS to mainstream vehicles, but clearly, they are surmountable. ADAS systems are commercially available today, consumer demand is high, and the path towards widespread adoption is paved. If consumer acceptance of ADAS provides any indication of societal acceptance of autonomous drive, we’re well on our way.

Jivin' up the Jeep with a fresh new version of the QNX CAR Platform

by Paul Leroux

Reskinnable, reconfigurable,
and refreshed

If you haven’t already heard, we've announced version 2.1 of the QNX CAR Platform for Infotainment. In fact, we’re demonstrating it this week at the Telematics Detroit conference.

So what’s new in 2.1? Well, let’s start with what hasn’t changed. The platform is still based on the same, reliable QNX architecture proven in tens of millions of vehicles. (Fact: In 2012, QNX technology shipped in 11 million cars. If you put those cars end to end, they’d circle the earth — and you’d still have about 6000 miles of cars left over. That's a lot of cars.) The platform also retains its inherent flexibility, allowing infotainment system designers to use multiple app environments, connect to multiple mobile platforms, and create a wide range of systems.

Um... let me correct that statement. The new version is, in fact, more flexible. From the beginning, the QNX CAR Platform has supported both HTML5 and OpenGL ES, the two most popular open standards for mobile development. And now, with version 2.1, it also supports Android apps, as well as apps and human machine interfaces (HMIs) built with the popular Qt 5 application framework.

The QNX reference vehicle — a modded Jeep Wrangler — is the perfect, well, vehicle for showcasing these new capabilities. Take, for example, the new digital instrument cluster, which is implemented in OpenGL ES:



I enjoyed the look of the reference vehicle’s original cluster, and still do. But you know what I like about the new version? It shows how a digital cluster can deliver state-of-the-art features, yet still honor the look-and-feel of an established brand like Jeep. These features include dynamic reconfigurability and the power to display turn-by-turn directions, weather updates, and other information provided by the head unit.

Speaking of which, here is the head unit’s main screen, which serves as a one-stop information center for turn-by-turn directions, weather, music, and recent messages:



Now let’s slide over to the passenger seat for a different perspective. If you look below, you’ll see the head unit’s app tray, which shows how the QNX CAR Platform can blend a variety of apps and HMI technologies on the same display — in this case, native and Android apps running on an HMI built with the Qt 5 application framework. In case you’re wondering, the Android app icons in this image are AutoTrader and TapTu. (That's right, they can be accessed just like other apps.)



If you’ve seen images of the QNX technology concept car (you know, the Bentley!), you’re already familiar with the gorgeous 3D navigation system created by our partner Elektrobit. Well, the reference vehicle also comes with a version of Elektrobit’s nav system, seen here:



And last, here’s an image of my personal favorite, the virtual mechanic. In this case, it's displaying trip information, including duration, mileage, and average speed:



There's a lot to see in version 2.1 of the QNX CAR Platform for Infotainment, but there's also a lot you can't see — such as improved power management, optimizations for faster boot time, and support for more hardware platforms, including Freescale i.MX 6Dual and i.MX 6Quad, NVIDIA Tegra 3, Texas Instruments OMAP 5, and Texas Instruments Jacinto 5 Eco.

What's more, I haven't shown you any of the new, pre-integrated partner apps that have been added to the platform, including HearPlanet, Parkopedia, Soundtracker, and wcities eventseekr. But no worries, I plan to reveal more in coming posts.

In the meantime, I invite you to check out the press release we issued this morning.

The ISO 26262 functional safety standard: No way but up?

I was scanning some Google alerts the other day when my eyes stopped at an announcement from Freescale. The headline didn’t mince words: the Freescale Qorivva MPC5643L microcontroller, a 32-bit part based on the Power architecture, has become the first automotive MCU to receive ISO 26262 functional safety certification.

Did you notice? Freescale didn’t say only; they said first. Which suggests they see ISO 26262 as a growing trend in automotive. If so, I think they see right.

If you’re unfamiliar with ISO 26262, let me provide the Reader’s Digest version. First and foremost, it applies to automotive electronic or electrical systems that could pose a hazard (i.e. hurt people) if they malfunction. Examples include anti-lock brakes, traction control systems, adaptive cruise control systems, engine control units, and digital instrument clusters.

Will more automotive
components soon come
with stickers like this?

The standard isn’t concerned with how well such systems perform. Rather, it’s about reducing the risk, and mitigating the effects, of any malfunction that may cause injury or death. So even if something bad unexpectedly happens in a 26262-certified system — and the assumption is that bad things will happen, no matter how well the system is designed and tested — the system will minimize potential harm. For instance, consider the scenario where a high-priority software process enters an infinite loop and starts to gobble up CPU cycles. Obviously, it’s important to prevent this error from happening in the first place. But even if it does happen, the system should prevent the rogue process from starving other critical processes of CPU time. It should also achieve a graceful recovery from the failure state.

ISO 26262 applies to production passenger vehicles with a gross mass up to 3500 kilograms (7716 pounds). Anything else is out of scope. But while the scope is limited, the standard itself is comprehensive. It covers functional safety aspects of the entire development process, from requirements specification to product decommissioning. And in case you were wondering, it’s closely related to IEC 61508, the international safety standard with a very long history and which many other safety standards reference.

So why do I think that 26262 is on the ascent? For starters, the first edition of the standard was published less than a year ago, yet a silicon vendor has already spent the considerable effort to get an MCU certified. Achieving certification to a standard like ISO 26262 doesn’t come easy, so I assume Freescale did it only because they anticipate market demand. (Disclaimer: This statement isn’t based on any special knowledge of Freescale’s business, but is simply my opinion. Interpret it as such.)

TÜV Rheinland:
Also in the game

It doesn’t stop at Freescale. TÜV Rheinland, a global provider of technical services for safety-critical systems, now offers 26262 services (training, consulting, testing, certification, you name it) for a wide variety of automotive components in multiple geographies. And if TUV has gotten in the game, it’s a good signal that the 26262 standard has legs.

Meanwhile, the LinkedIn group dedicated to 26262 has more than 3600 members and grew by more than 50 members last week alone. If you visit the group, you’ll find engineers from automotive OEMs and tier ones looking for guidance on satisfying 26262 requirements — a sure sign that support for the standard is gearing up.

From what I can tell, things haven’t gotten to the point where a company has been mandated to have its automotive systems certified to ISO 26262. But it will happen. And chances are, it will snowball: the more companies that adopt the standard, the more others will feel the pressure and follow suit. Which means it’s only a matter of time before more ISO 26262 product announcements show up in my Google alerts.

Enabling the next generation of cool

Capturing QNX presence in automotive can’t be done IMHO without a nod to our experience in other markets. Take, for example, the extreme reliability required for the International Space Station and the Space Shuttle. This is the selfsame reliability that automakers rely on when building digital instrument clusters that cannot fail. Same goes for the impressive graphics on the BlackBerry Playbook. As a result, Tier1s and OEMs can now bring consumer-level functionality into the vehicle.

Multicore is another example. The automotive market is just starting to take note while QNX has been enabling multi-processing for more than 25 years.

So I figure that keeping our hand in other industries means we actually have more to offer than other vendors who specialize.

I tried to capture this in a short video. It had to be done overnight so it’s a bit of a throw-away but (of course) I'd like to think it works. :-)