The New MIVEC Turbo Diesel Engine

The new engine uses an aluminum die-cast cylinder block with the result that the weight of the engine is lighter by 12.5 kilograms as compared to the conventional cast-iron cylinder block. Its maximum output is 221kW (300PS)/ 6,500rpm and its maximum torque is 422Nm (43.0kgf･m)/3,500rpm (for Japan market), a higher maximum torque than the 4G63 model. The intake and exhaust side layout of this engine is also different with the intake side at the front of the vehicle body and the exhaust side at the rear. This eliminates the need to have an exhaust pipe underneath the engine, so Mitsubishi was able to lower the position of the engine by 10mm compared to a conventional model, contributing to lowering the height of the center of gravity.

Anchoring Trust in the Increasingly Software-Based Car

Bill Boldt
Business Development Manager, Security, Blackberry
wboldt@blackberry.com

Electronic Control Units (ECUs) started out in the 1970s as discrete modules with each one doing one particular thing, at that time mainly for emissions controls and mileage.  Then they became connected via in-car networks with the invention of the CAN bus in 1985.  In-car networking represented a big improvement in capability.  However, being networked means that ECUs became vulnerable to mischief and thus they, and what the connect to (such as domain and area controllers) need to be secured cryptographically to ensure that the signals being sent have not been tampered with or corrupted, and perhaps most importantly, that they are authentic.   There is also the emerging need for confidentiality (i.e. encryption/decryption).

The picture below shows the top attack points.  This range or targets indicates just how vulnerable cars have become: 

With a car having so many places to attack, how can trusted security be implemented and why is it so important?  Well, the main thing is that trust leads to safety, especially as cars become more connected and autonomous.  Hacked or corrupted signals can have dire consequences in a car, which is obvious.  In a car, safety is related to security and security comes to a  large extent from cryptography.  (Note that safety and security are not exactly the same thing, but there is tremendous overlap and interplay, and safety is becoming much more dependent on cryptographic security as cars become more connected and autonomous.  For more on functional safety look here.)

Trust
Trust is paramount in digital systems, and increasingly so in automotive. Trust comes from cryptographic solutions that:

• Securely store secret keys
• Securely issue, manage, renew and revoke security certificates
• Include a mix of software and security hardened hardware devices, and
• Are manufactured in highly secure facilities

What Creates Trust?
A major tenet of security is that each system and sub-system will have different types of threats and a range of options to provide countermeasures to those. This means that the automotive security equation has many variables and thus is difficult to solve.

However, two things are always common to trustable cryptographic security, and they form the basic foundation of modern security:

1. A proven algorithm (e.g. Elliptic Curve Cryptography (ECC)), and  
2. A secret cryptographic key  (to provide the required level of security for the selected algorithm). 

The challenge for the automaker is to choose the right algorithm and key length for the available processing resources and to securely issue, manage/store, renew, and revoke the security certificates. Cryptographic strength comes from the combination and application of these principles, processes, and techniques. 
 
Trust Anchor
On a CAN bus, which was designed without security in mind, ECUs are exposed.   So, connected cars should employ best practices for security, but cost, complexity (especially of the supply chain) and time get in the way. Having said that, best practices will eventually prevail and that will likely include a hardware trust anchor system to establish, maintain, and update cryptographic processes.

 
From the diagram you can see the four basic things that create a PKI-based hardware trust anchor:

1. A trusted hardware anchor that stores the key
2. That key, which becomes the root of trust
3. The certificate chain anchored by the root of trust, and
4. A signing mechanism that creates the anchored certificate chain

Multi-level Security

Because there are so many systems in the increasingly software-defined car, security has to be multi-layered and fit the specific application. In other words — it must be tailored. You have to figure out what you are securing, what threats that system will face, and what countermeasures should be employed. You have to pick what pillars of security to apply; namely, confidentiality, data integrity, authentication, and non-revocation. Making sure you are doing the right security things on each system is what Blackberry is positioned to help you with, from consulting, to design, testing, certificate management, securing the supply chain, making updates, and applying cryptography to the in-car and around-the-car networks.

To learn more about cryptography for automotive please contact Blackberry's Certicom
subsidiary, and for more information and/or help regarding reliable, secure, and trusted software for safety- and mission-critical applications such as automotive please contact QNX. 

The bottom line is that BlackBerry, Certicom, and QNX can help your system become not just secure, but BlackBerry secure. 

How TrueCar and other Third Party Auto Retail Vendors Work

by David Ruggles

How do the third party vendors like TrueCar, and the others, actually work? It’s really quite simple. The auto buying Consumer belongs to retail Auto Dealers. They have the money invested in inventory. They have substantial investment in facilities. The third party vendors spend large amounts of money to “hijack” those auto buying Consumers and take them “hostage.” They then “ransom” them back to the Dealers for a sizable chunk of change. In the case of TrueCar the “ransom” is about $400. on a new vehicle and $300. on pre-owned. That money is reinvested by the vendor and used to “hijack” and “ransom” even more car buying Consumers. They are able to “hijack” these Consumers by pretending to protect them from the Auto Dealers, as if the Consumers are helpless sheep. These vendors don’t lead their message to Consumers with the fact that they raise the cost of the Dealer’s sale, and the Consumer’s purchase price, by the “ransom” amount. How many consumers would knowingly pay an upfront fee to these vendors?

The ultimate customers of these third party vendors are the Dealers. That’s where their revenue is derived. Most Dealers understand what’s going on and aren’t happy about it. A large number of them, however, have capitulated. Others use the third party vendor strategy in their favor without paying for it. For example, a TrueCar customer can come to a Dealership that isn’t a TC Dealer. That Dealer can go to the TC site and use the information provided there as a closing tool to negotiate the deal with the Consumer. Because the non-TC Dealer’s cost doesn’t include the “ransom fee,” the Consumer potentially gets an even better price while the dealer makes additional profit if they split the unpaid “ransom fee.” The Consumer becomes a higher value owner to that Dealer.

All Dealers have advertising and marketing budgets. These third party vendors would like everyone to believe that their fee would be spent in other areas of advertising rather than adding to the cost of individual the vehicles sold to Consumers the vendor took “hostage.” The vendors insist that their services allow dealers to target their marketing efforts better, thereby providing savings. The fact of the matter is that Dealer advertising budgets have done nothing but rise since the proliferation of third party vendors came into being. The Internet has spawned so many “leads” that Dealers are now struggling to figure out how to “weight” them, to distinguish leads in terms of “likelihood to purchase.” Despite the fact that TrueCar has yet to make a profit, despite reaching a Dealer saturation point that they used to claim would make them money, many third party vendors DO make money. They make enough money that there is about to be a flood of new major players enter the field.

In particular, enter Amazon Vehicles, with pockets deeper than any of the existing players. They will potentially have the budget to do almost anything they want. Indeed, they can afford to fritter away a lot of money figuring things out. Relative to stand-alone players they can lose money for an extended period of time, in a market where profits are already diluted, all the while using their competitors as “pricing cover.” Dealers could call a halt to all of this by just saying no, but while a few may hold back, enough will participate because they just don't get it, and their rivals down the street will join to make sure they don't gain an advantage. So collectively they won’t say no. There will be further consolidation in this business as players with really deep pockets enter the fray. In the meantime, neither Consumers nor Dealers will be well served.

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 webinarwith QNX and RTI.

---

Do the "Jobs" Arithmetic: Trump Calls for 19 million Immigrants

mike smitka

In the first presidential candidate debate Donald Trump proposed creating 25 million jobs. Now currently 152 million people are employed in the US, out of a potential labor force of 156 million. Yes, we're short – by 4 million jobs. Now because of baby boomer retirements and lower birth rates over the past 20 years, the size of the potential labor force will rise to only 158 million by February 2021. So while he could oversee an economy that creates 6 million additional jobs, the only way to add 25 million new jobs would be to bring in 19 million working-age adults from outside the US. Yes, Trump must be pro-immigration.

...Trump can only add 25 mil jobs by bringing in 19 mil immigrants...

There are other, less palatable alternatives, such as instituting a draft of all 22 million youth of high-school age. Since relatively few of them work or have family responsibilities, that could get him to the 25 million level.

So let's assume instead that he's not engaged in sophistry but is instead being sophisticated. That is, he's arguing about GROSS job creation, not net new jobs. In 2016, on a monthly basis about 5 million people leave their jobs, voluntarily or otherwise, and 5.1-5.2 million people are hired, in what to those individuals are new jobs. Then all Mr. Trump proposes is 5 months hires at the normal rate. Using this metric, over 4 years he needs to create not 25 million but 250 million jobs.

Now does everything Secretary Clinton has said on the economy during her decades of public life make sense? Unlikely! We all spout nonsense on occasion. But she does have staff, listens to them, and mainly gets things right. Once Trump proposes actual policies, I'll look at her proposals. But so far all he has are sound bites that don't add up.

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…