In 2017, there were 1.2 million vehicle deaths around the world—90% from driver error. Driverless, autonomous vehicles promise to dramatically reduce road accidents from human error and potentially save nearly a million lives a year.
But there are also risks with connected and autonomous vehicles:
Like with any computing device, vehicle cybersecurity is a necessity rather than a luxury.Click here to learn more about how GuardKnox provides the security foundation for services
Just as mobile phones have become ubiquitous handheld computers, so too connected and autonomous vehicles are quickly becoming ubiquitous “computers-on-wheels”.
While there were
connected vehicles on the road in 2015
by 2025, there will be
connected cars, comprising 90% of all vehicles on the road
And like with the mobile phones/computers of today, consumers will desire to use suppliers in the automotive aftermarket or vehicle app stores to personalize, customize, and enhance their “computers-on-wheels” of tomorrow from the suspension to the powertrain to the infotainment system.
Computers were first added to cars in 1968 when Volkswagen introduced a microprocessor-controlled electronic fuel injection system to replace carburetors. These microprocessors or electronic control units (ECUs) precisely controlled the fuel-air mix and dramatically improved vehicle performance. Over the last 50 years, individual ECUs have been added to cars for managing specific vehicle functionality, including engine and transmission control, climate control, anti-lock braking, park assist and more.
In the 1980s, an automotive computer called a Controller Area Network (CAN) bus was introduced to enable the disparate systems to communicate with one another. While older cars may have up to a dozen ECUs “talking” to one another, a new vehicle may have 150 or more independently operating ECUs using multiple network protocols with overlapping or redundant services. From 2010-2016 software code in vehicles and their ECUs grew from 10 million lines of code to 150 million lines of code—that’s about 1000 times more code that the Apollo mission needed to put Neil Armstrong on the moon. As you can imagine, with so much code there are bound to be numerous software-related quality issues that cause millions of vehicles to be recalled each year.
One of the biggest challenges facing today’s vehicle networks is the vast amount of data that is produced—and will exponentially increase as vehicles become increasingly autonomous and are required to process vehicle-to-vehicle and vehicle-to-infrastructure communications. Transferring and hosting this data is also very costly and increases vulnerabilities to hacking. Today’s ECUs offer the computing equivalent of 20 personal computers and transmit more than 25 gigabytes of data per hour but they are severely limited by the CAN’s data transfer rate of 1 Mbps—a far cry from the 1 Gbps we receive from our home and office Ethernet networks.
With 150 million lines of code and the software-related content increasing from 10% to 30% of a vehicle’s content by 2030, the current electronic architecture does not enable the services model to support vehicle applications, functions, and data usage. With more software code in a vehicle than in a fighter jet or space shuttle, the current model cannot be sustained due to the complexity, cost, and security risks associated with so many ECUs.
At the same time, a faster network is desperately required to handle the vast amounts of vehicular data at the requisite speeds. By 2020-2021, the automotive industry is expected to release a more advanced ECU architecture, with most functionality centered on consolidated domain controllers that will especially useful for supporting autonomous driving.
The IT industry went through a similar challenge in the late 1990s with the advent of Web 2.0 and the utilization of the Internet for many business applications and processes. To solve the challenge of enabling applications on multiple platforms such as personal computers and via the web, they were broken down into specific functional components or “services” that could be remotely accessed and updated independently.
The services are independent of the vendors that implement them and of the clients that use them. Standardized functionality or services are offered by distributed networked computers (servers) and are accessed through standardized protocols and Application Program Interfaces (APIs).
This “Service Oriented Architecture” offers four primary benefits:
Code components are created and reused to decrease development time
A new standardized communication protocol enables the platforms to communicate and pass data regardless of the languages used to build them
A standard communication protocol limits the interaction between the clients and the backend services and enables web-based services to be scaled without overly taxing the application
Maintenance costs are reduced as fixes or changes to code can be performed in specific services without impact or requiring the test of end-to-end application performance.
The GuardKnox SNO™ Family offers several options for implementing a vehicle-based Service Oriented Architecture.
Central SNO™ gateway can serve as a central domain controller or ECU for managing the communication of all vehicle ECUs. It is provided to OEMs as a software stack and security core that is integrated into the vehicle’s hardware during production.
Local SNO™ controller serves as a local domain controller/ECU or remote management server and is used to protect externally connected ECUs. It is provided to OEMs and Tier-1 manufacturers for ensuring seamless and secure interoperability with other vehicle services and applications while securely reducing the cost of development through the reuse of existing code.
Including firewalls, remote server management, cryptography or the Communication Lockdown™ framework
Hosting services and downloadable applications for customization
Supporting an app store for downloadable personalized apps and features
Flexible hardware architecture (based on FPGA) for future unforeseen needs and data requirements
Ability to host and communicate with all operating systems, whether mission critical or not and containing the failure of a single app/service so that others are unaffected.
GuardKnox provides a real-time safe and secure environment for the various services to operate in isolation without unintended interference from other services or networks—or intentional manipulation by hackers.
GuardKnox cybersecurity serves as a foundation for implementing the use of “virtual machines” that enables compartmentalized functionality for microservices. GuardKnox provides a hypervisor with an unmatched level of security so that so all apps and ECUs can securely speak to one another. In addition, it empowers developers to securely integrate new applications without compromising the security and safety of the rest of the system.
Using the GuardKnox Communication Lockdown™ framework, the GuardKnox hypervisor verifies each message between the vehicle services on three different layers:
This compartmentalization will enable easy changes to the vehicles’ software and hardware, enabling OEMs, aftermarket service providers and vehicle owners to add, delete and update vehicle apps, including:
Most importantly, the migration of the current vehicle architecture to a Service Oriented Architecture will eliminate millions of lines of redundant code, increase overall security, and make updating, adding or deleting vehicle apps as easy and as transparent as updating our smartphones.