Wednesday, September 28, 2016

The Secret to a Successful Autonomous Vehicle Development Program: A Data-Centric Approach to Autonomous Car Design

Bob Leigh, Director of Market Development at RTI
Romain Saha, Strategic Alliances, Manager at BlackBerry

The automotive industry is facing unprecedented changes in the coming decade. With the rise of autonomous and connected cars, software is a significant differentiator in the automotive market. As software takes a central role in the functions and features of the car the investment in software development is accelerating dramatically. Automotive companies must adopt novel software design methodologies to be competitive, as well as ensure safety, security, and a quality user experience. Fortunately, embedded system architecture is also evolving. Fueling this change is the proliferation of “system-of-systems” architectures, where connectivity and accessibility are baseline requirements. This requires interoperability! 
  
IIoT and Data-Centric Design

The rise of the Industrial Internet of Things (IIoT) is driving this need for new architectures to unify the standalone devices of the past. These changes are already happening in other market segments and are fully applicable to automotive. In ever more connected and autonomous cars, many subsystems operate in tandem, but without the benefit of a greater awareness. For example, braking systems have very little interaction with power steering.  As we connect these systems and add layers of automation, the car itself becomes a system-of-systems – where braking and steering coordinate with vision and sensor functions – and every car is then connected to a much larger system. 


These larger connected systems could support fleet management, traffic management, sharing services and other as yet undefined applications.


 
Such a new design model must provide:
  • Time-sensitive reliable transport, safety and mission-critical rigor in software design;
  • Interoperability between applications, domains, operating systems, and entire heterogeneous systems;
  • Support for high volume communication across multiple domains or compute platforms (sensors, actuators, etc.); and 
  • Code reuse and the evolution of the system as it moves from research to development, on to production and into maintenance lifecycles that span multiple model releases.
Data-centric architectures address all these requirements. A data-centric architecture offers reduced development and maintenance costs when compared to device or application-centric or object-oriented approaches. 

Data centric-architectures support interoperability between teams, application and entire network domains and foster innovation through better access to data. To be data-centric means to put data at the center of any system, which is then self-describing and accurately reflects the real-time state of the system. It abstracts the complexity of operating systems, hardware, and network programming to allow applications to focus on the core value they add to the system. It decouples applications so that they become actors that use or change the state of data but do not explicitly interact with each other. This approach supports the sharing of code and IP (since it does not depend on a specific platform) and has many advantages in scalability, interoperability and maintaining data/state integrity.

Complete Lifecycle Support Platform

 

The preeminent data-centric middleware standard for real-time systems is DDS (Data Distribution Service). DDS is an open standard maintained by the Object Management Group (OMG). This standard has been developed over decades in highly demanding applications and is in use today in multi-billion dollar product lines worldwide.

DDS offers many features that are critical to any ADAS or Autonomous Drive application. Core to DDS, Quality of Service allows developers to guarantee latency, control data flow and manage network bandwidth. All of these things are achieved within the middleware, so the application only needs to focus on the processing of data, not the delivery.

Interoperability between applications and domains creates a layer of abstraction that allows OEMs to combine systems from different Tier 1s in a way that minimizes complexity and risk. It supports multiple operating systems seamlessly to enable architectural evolution from statically to dynamically configured higher-level operating systems – moving from the idea of domain controllers to compute platforms. It provides a unified infrastructure to connect and control different domains, paving the path to sensor fusion. It supports the high volume of traffic that these architectures will demand.

With DDS, applications, teams of developers, and systems share data using a common data model defined for the entire system. Once defined, all interaction between system actors is understood through this common data model. Code development and application interactions are decoupled, which allows more efficient development and collaboration of large, geographically distributed teams. DDS can support many thousands of applications with hundreds of development teams worldwide. This is the power of data-centric middleware.

Certified Software Stack

For many years DDS has been used in air, land, and sea autonomous system projects. It provides the features needed to support time-critical, dynamic, high volume applications that are key to the next generation ADAS architectures and ultimately to autonomous drive. Using a safety certifiable middleware, such as RTI Connext® DDS Cert, with QNX ISO26262 certified RTOS and ADAS framework, you can begin development with a fully-integrated, certified software stack. The combination allows engineering teams to focus on their core value-add in application development while ensuring system performance, interoperability, security and safety certifiability.

RTI (Real-Time Innovations, Inc.) is the largest DDS vendor and is the only one with a safety certifiable version of its product. RTI Connext® DDS is used in many mission-critical and safety-critical applications and is an essential component of the future Autonomous Car.

Please contact RTI at  bobl@rti.com or QNX at rsaha@blackberry.com today to learn more about these powerful tools.

QNX Software Systems Limited, subsidiary of BlackBerry is a leading vendor of operating systems, development tools, and professional services for connected embedded systems. Global leaders such as Audi, Cisco, General Electric, Lockheed Martin, and Siemens depend on QNX technology for vehicle infotainment units, network routers, medical devices, industrial automation systems, security and defense systems, and other mission- or life-critical
applications. Founded in 1980, QNX Software Systems Limited is headquartered in Ottawa, Canada.



For more information on Connext DDS in Autonomous Vehicles, please download our whitepaper or register for this upcoming joint webinar with QNX and RTI.









Saturday, September 24, 2016

On Clusters and Infotainment



Romain Saha
Strategic Alliances Manager
BlackBerry


I think I have IAD or internet addiction disorder. I don’t argue with people anymore. I just google until I get the answer. I can’t remember anything. Why should I? It’s all out there on the internet. I barely watch TV anymore. I’d rather just learn something using the internet. 

OK – this probably isn’t textbook IAD. Maybe it’s just the new reality. Pretty much everything anyone could possibly want to know is out there somewhere on the internet. Sometimes it’s easy to find. Sometimes it’s hard. But it almost always is out there if you look hard enough. 

You would think that in this brave new world that there’s no opportunity for confusion anymore. I thought so until I started trying to figure out how one could build a safety certified digital instrument cluster and a full-blown infotainment system using a single high powered embedded processor. I see a lot of silicon road maps in my role and those indicate that a lot of horsepower is coming online. So much horsepower that it’s starting to look like using separate processors to run disparate systems in a car doesn’t make sense anymore.

You’d think that combining a cluster and infotainment system on one SoC would be a no-brainer. Dual (or more) display support is getting pretty common and even today’s SoCs have the compute cycles, so why isn’t everybody already doing this?  It seems pretty easy until you consider that the cluster is a safety critical system. It’s not even the whole cluster, mind you. It’s just what they call telltales. Telltales are those icons that light up in your car to tell you you’re in drive and not reverse, that your traction control is offline, or that your engine is about to blow up. Small things maybe, but very useful information indeed. So, that means you have to address safety concerns for the cluster.

Why not just apply safety criteria to the whole system including the head unit then and be done with it? That is one approach certainly, but the problem is that an infotainment system is pretty much impossible to safety certify. Maybe impossible is too strong. You could probably do it, but why would you? It would probably cost way more than any savings resulting from collapsing two systems onto a single chip.  Plus it would take forever.

If that’s not the answer, then what is? Finding a way to isolate cluster safety criteria from the infotainment system can do job, as long as you can ensure complete isolation. This isn’t a new concept but still pretty rare in embedded.   This is called a hypervisor, and if it is done right, it does the trick. Well, almost. Not every hypervisor can do it right. In order to ensure isolation for this use case you need a type-1 hypervisor. Type-2 hypervisors don’t cut it.  

This is where the internet starts to fail me.  I see hypervisors described as type-1 but then see things about proprietary drivers. I see people say virtualization, but when you dig a bit deeper it’s hard to say whether it’s virtualization or para-virtualization. Type-1, type-2, para, hybrid… I’m at the point where I don’t really know what I see. 

It would be so much easier if people answered simple questions with simple answers.

  • Can you share graphics and still achieve true safety isolation? 
  •  Is the hypervisor built in a way that you can reasonably safety certify your system.
  •  Is it real-time? 
  • How much overhead does it add to the overall system? 
  • What happens if a guest OS goes rogue? 
Maybe you could ask your hypervisor supplier how they address this kind of stuff. If you get an answer that makes sense, do the world a favor and spread the word.

The second thing you need is a foundation on which to build a safety certified system. QNX, as an example, has certified both its OS and tool chain to ISO 26262 ASIL D. You can find this certification on the internet. It’s  here . If you take the time to read it, it says we did the tools and the OS. The production OS used in millions of systems shipping worldwide.
  
Here’s where the internet fails me again. I have looked and looked and looked for another embedded OS company with anywhere near the same level of certification. It has to be out there. I see all kinds of anecdotal “marketing" evidence but I can’t find a certificate. The closest I have come so far is a certificate for an OS, without the tools, that was issued in 2007 for Common Criteria EAL 6+ on an old single-core PowerPC processor. I must be missing something.  Can you buy a PowerPC processor anymore? I guess you should ask to see certificates to be sure you know what you’re getting.

I’m having a hard time coming to grips with the internet letting me down. I’m certain I just don’t know where to look, so if anyone has the answers I’m looking for, I’d love to hear about it. Better yet, post it somewhere on the internet that’s easy to find.

The next thing I’m going to try to find is someone with a safety certified hypervisor because you’ll need one of those too…

Thursday, September 1, 2016

Cryptography is the New Seatbelt

Bill Boldt
Business Development Manager: Security
BlackBerry


The evolution of the car into an electronic platform started with cockpit electronics and branched into safety and locomotion, giving rise to Electronic Control Units (ECUs). ECUs are little computers that intelligently control physical things like mirrors, lights, seats, AC, and other things in the body or cockpit; and made for better control of brakes, engine systems, airbags, and other things that make the car stop and go, steer, and become safer. Cars today can have well over 100 ECUs. And that can be challenge to make truly secure.

Fortunately, that is changing. Multi-core processor technologies are being harnessed to consolidate ECUs into a platform populated by powerful domain-controllers. A major benefit of domain controllers is that they lend themselves to being secured by modern cryptography because they can run algorithms faster and store crypto keys more securely. Also, fewer controllers means fewer points for attack. In a connected autonomous car safety comes from security, and security comes from cryptography. Because attacks can come from anywhere, at any time, and on any system, automotive security must be multi-layered, meaning everything has to have some sort of cryptography to protect from attackers. Security awareness should start right at the beginning of design with disciplines such as penetration testing of the software and security audits to find vulnerabilities. And, these should be applied inside and outside of the car.

Once you have a good start you need to ensure a good ending, which means security updates, and that typically means over the air. In between the beginning and the end there should be secure manufacturing and secure distribution of crypto keys and certificates. BlackBerry can help with all of that with security design and testing, QNX's microkernel based RTOS, and Certicom's technology for securing the supply chain and managing security certificates to gain BlackBerry level security, without your having to become a crypto expert.

By now you can see that by providing the first line of defense for personal safety, cryptography is becoming like the new seatbelt.

SECURING AUTOMOTIVE 
When it comes to embedding security into the autonomous connected car of the future, it has to start with securing the supply chain. Security in and around a car has many requirements:

  • Security assets (i.e. crypto keys, serial numbers, etc.) must be installed into the devices at manufacturing time

• Devices must be distributed to and be installed into vehicles in globally located factories

• Devices must be warehoused worldwide for subsequent repairs

• Secure devices must be updateable at dealers and repair shops

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

These requirements present a logistical tangle. Making a device such as a networked ECU on a CAN bus secure means that it will become one of a kind. This is the entire objective of
personalization. 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 flexibility is a serious trade off that must be managed carefully. High profile automotive hacks have shown the world that automotive security is necessary, but it is difficult to apply especially because it makes manufacturing more difficult and costly. Because security must be injected in the factory and beyond, a secure manufacturing system must have global reach, be manageable on a distributed basis, be updatable by various entities, and remain secure for years. Secure manufacturing, including injection and updating of security assets, will touch factories, warehouses, distributors, dealers, repair shops, and aftermarket parts stores. In addition, security updates will often be over the air.
 

To maintain the maximum amount of flexibility, personalization and updating should be moved as close as possible to the very last minute. Each car maker will be faced with the same situation and will have to design and manage secure device manufacturing systems and  security certificate management systems, that are global and long term in nature.

Fortunately, the tools to do that are available from Certicom; namely, the Managed PKI system and Asset Management System. The way in which these systems get deployed will have to be designed to the specific logistical and security needs of the manufacturer. Therefore, the overall manufacturing blueprint must be designed with best practices in mind, right from the start, and BlackBerry Professional Services and help with that. Also,
in-car and around the car security systems can be developed using Certicom’s cryptographic libraries and architectural consulting services.

Blackberry brings it all together to make the software defined car more secure, and that means safer.