In many ways the recent releases of autonomous concept vehicles by the likes of BMW and Mercedes are putting the cart before the horse; though the achievements of Google’s driverless car are undeniable, they provide only a small snapshot of what is required for a fully autonomous transportation infrastructure.

Much more than these isolated glimpses of the future, a holistic deployment of vehicle-to-vehicle and vehicle-to-infrastructure, or V2X, technology will be required to drive autonomous cars from test labs and controlled environments to mass market adoption on the open road. V2X architectures consist of elements that span all tiers of the automotive industry as well as network infrastructure (from in-car devices and applications to the cloud), and stitch together sensor information and big data with seamless connectivity to form systems of systems amidst the transit base. Though still in its early stages, V2X is the product of decades of evolution in the automotive sector, and is now reaching a tipping point in industry and government that will help usher in a new era of automobiles and connected transport, says Meg Divitto, Vice President of Future Solutions and Technology within the Internet of Things group at IBM (www.ibm.com).

“As it relates to the growth of the automotive industry, it was a mechanical system that had some control logic in the early days,” Divitto says. “That moved to a mechatronic system in the 80s and 90s, which meant that it was a mechanical-electrical system that had many more electrical things going on in the automobile – from using a push button door lock to an electrical one, to use a very simple example. All of a sudden there were more electronics, and then the era of software in the car during the 90s. Software started becoming more sophisticated and moving from basic control logic to sophisticated modules and devices, and then everybody went function crazy.

“So you saw content coming in the vehicle at rapid rates, and automotive manufacturers, due to having individual architectures and no standards, were bolting things onto the vehicle just to put things on,” she continues. “And everyone’s heard this, but there are more lines of code in a car than in a jet fighter, primarily because it’s not architected and modules are being bolted on. This is causing a huge amount of complexity as it relates to software quality and the quality of the vehicle.

“As you look at that progression you say, ‘Okay, we have to do things differently,’” Divitto explains. “There’s been a movement to go from this kind of vehicle architecture to a functional architecture. Some OEMs turned their designs on their heads starting in the 2000s to be able to go to a functional architecture where you lay out the architecture and the partitioning of the vehicle modules in a way that makes sense and doesn’t allow this big hairball of code; AUTOSAR was born in 2004 to handle this and have all the OEMs come together around a standard, functional vehicle architecture that could provide common requirements for suppliers so that common methodologies could be used to build, rollout, test, and certify.

“But if you understand that, now enter the next wave, which is telematics,” she says. “Now, vehicles are connecting to each other and the infrastructure, and there’s far more complexity. My view of the industry is that this is going to cause a tipping point where architectures are going to have to go back to an abstraction layer methodology where you abstract basic mechanical, mechatronic, and software functions from all of the other things associated with telematics, the connected vehicle, and V2V. Once that tipping point occurs we’ll be able to see a different progression of the technology and a different progression of the way in which complexity is solved. That’s when things will be done more harmoniously.

A holistic approach to V2X

As the progression of automotive technology continues, one area in particular is helping fuel the development of V2X architectures – electronic control units (ECUs). With the advent of massive multicore processors, ECUs are evolving into domain controllers that provide more performance for advanced applications in the connected car, and enable more fine-grained control over various vehicle subsystems. Though on the surface this could be perceived as a very small cog in the V2X wheel, advances in hardware technology are opening paths to innovation in software and the communications infrastructure that will serve as gateways to the connected vehicle, says Artur Seidel, Vice President of Elektrobit Automotive Americas Inc. (automotive.elektrobit.com).

“We’re currently in the early stages to get to that final goal, but the way we look at the final goal is that one has to take a pretty holistic approach to V2X,” Seidel says. “Currently when you look at some of the stories in the media where there was a system that was heavily hacked into, it tends to be a single system that was bolted somewhere to the car, added to the system. But the system itself in the car wasn’t built with connectivity in mind, so there has to be a holistic approach – that looks at the hardware, that looks at the software, that looks at the communications.

“Ultimately what we’ve seen, if you look a few years back, is that there have been lots of small ECUs that don’t have a whole lot of performance,” Seidel continues. “Now, things are shifting towards what we call domain controllers, which are much more powerful, and we see that for example in the driver assistance space; you saw at CES that NVIDIA launched a 256-core CPU called the X1, and that’s going to be used in driver assistance applications. Now you have a domain controller with all these cores, so how do you now have a software layer on top of that that takes advantage?

“Elektrobit is very active in AUTOSAR, and we have a secure OS called the EB tresos Safety OS that in essence assigns functionality to these cores in different safety levels based on what the function is (Figure 1). That’s the software piece, and the third piece of course is the communications piece, and we envision a non-symmetric encryption like public key or private key, not just from the car, but from outside and between components within the vehicle. This is a combination approach, and it’s going to be a step-by-step approach to get there, but ultimately we’re going to see these kinds of systems with powerful multicore domains, secure OS software that’s been structured by safety requirements within the car, and then strict encryption to and from the vehicle,” he says.

 

 

V2X safety and security compliance

Though the consolidation of multiple ECUs into fewer, more powerful domain controllers based on multicore silicon serves to reduce hardware cost and complexity, it also highlights security concerns that have plagued connected cars since their inception. Where today and in the past vehicle subsystems have been primarily controlled by a single ECU, when introducing connectivity for a particular set of applications running on the same domain controller that also manages safety-critical functions, you introduce the possibility of Internet-borne threats to the entire system. While malicious software that makes its way onto a smartphone or laptop can disrupt day-to-day activities, malware or corrupt files in the context of the connected car can cause catastrophic failures that result in the loss of life.

Despite the availability of safety-critical OS solutions, securely partitioning infotainment applications from steering or braking functions on a single CPU is top of mind for V2X developers, as it must be architected in a manner that complies with stringent automotive safety regulations and additionally account for security risks associated with Internet connectivity. As a result, automotive suppliers are increasingly turning to industry standards that provide best practices for V2X software development, and also help promote a uniform approach to safety and security compliance.

“One thing that has always been discussed as an inhibitor going back to the days of the telematics market is if a car has been driving down the road going 60 miles per hour and gets hacked, what happens? So there’s been a public phobia as it’s related to this space in the area of security,” Divitto says. “One way around that is through standards associated with the architecture of the vehicle that create an abstraction layer. Like in an airplane where the core of the plane functions are black boxed, other aspects above the abstraction layer are features and functions that would allow the vehicle to be connected. When you start talking about creating that abstraction layer, much like in an airplane today, the infotainment system does not share anything with the operation of the plane – not the bus, not the communication, not the devices, not anything. That’s where we will get to as an industry because it creates separation where “what do you want to secure” and “how do you want to secure it” can be secured at two different levels based on the way certain systems need to interact with the world around them.”

“Once you connect a system of course you have the possibility of security challenges, such as hacks and so forth,” says Seidel. “Therefore, communications have to be a) encrypted; b) have to meet requirements for functional safety because only certain subsystems within the car will be able to receive these updates; and c) in the same way that you have very basic system checks in a non-connected car when you start it up, with connected, more complex vehicles these checks will have to be more sophisticated, more elaborate – for example, if someone introduces incorrect map data, a connected vehicle that has sensors communicating with a V2I interface should have multiple ways of validating information.

“As we see more and more powerful ECUs, we’re going to now have to combine the compartmentalization of various vehicle systems onto one physical CPU, which gets into the requirement of combining a safety OS with infotainment functionality,” he continues. “So how do you safely implement that compartmentalization?

“We use ISO 26262, and put a lot of effort into that,” Seidel continues. “To deal with this multicore approach, it comes back to the fact that this is not your smartphone software or PC software with one big software load. These are differently compartmentalized pieces of software, which helps manage complexity. With different Automotive Safety Integrity Level (ASIL) requirements, if I have a steering system that has a life-threatening ASIL D requirement, I would treat and compartmentalize it very differently than I would a part of the infotainment system. ISO 26262 helps manage complexity because it clearly defines requirements so that when I deal with an ASIL D system, I don’t feed anything through shared memory or non-encrypted access (Figure 2).”

 

 

Beyond implementing a secure software architecture between vehicle subsystems, developers of V2X systems are also faced with the challenge of testing and validating how connected cars interact with other vehicles and the environment around them. Not only are these validation efforts complicated by the millions of lines of code in modern cars, but OEMs and Tier Ones also face the fact that it is practically impossible to test all of the scenarios a vehicle could encounter on the road. In response, organizations such as ETSI and the Car2Car Communications Consortium are actively working to define compliance tests and test scenarios for connected vehicles, while software vendors are turning to simulation techniques to help cut costs and speed time to market, says André Rolfsmeier, Lead Product Manager at dSPACE GmbH (www.dspace.com).

”V2X applications like intersection assistance, collision avoidance, or hazard warning systems are typically developed by means of a model-based design approach and tested by means of simulation,” says Rolfsmeier. “dSPACE provides dedicated tools for testing V2V and V2I applications by means of virtual test drives using open-loop and closed-loop simulations (Figure 3). By means of this, ECU software can be tested in the laboratory using realistic scenarios, and the associated software maturity level can be improved before starting real test drives. This approach allows development time and cost in the automotive industry to be reduced considerably.

 

 

“In addition, dSPACE rapid prototyping systems are widely established in the automotive industry (Figure 4). These systems allow, for example, V2X applications to be developed in short iteration cycles and experienced directly in the vehicle,” Rolfsmeier adds.

 

 

V2X drives convergence in communications

While V2V and V2I communications will not be used as the final control loop for safety-critical functions such as invasive braking, they will be essential for transmitting information about a vehicle’s immediate surroundings as well as upcoming road and traffic conditions that can be fused with other sensor data to give drivers, and someday autonomous vehicles, a more clear picture of their environment. Subsequently, V2X connectivity architectures often demand latencies under 100 microseconds, especially if applied in applications such as collision avoidance.

Currently there are several connectivity technologies that could be leveraged to facilitate the transmission of V2V and V2I data, however no definitive consensus has been reached on which, if any, will eventually be adopted on a national or global scale. This is driving industry to investigate both established and emerging types of communication for use with connected vehicles, as the lack of government regulation could force automakers to support multiple wireless standards in the future.

“For V2V, and also partly for V2I, a direct, low latency ad hoc communication between devices is required as typically the associated applications are safety-related,” Rolfsmeier says. “V2V and V2I requires vehicles and traffic infrastructure such as traffic lights, beacons, and road work signs to be equipped with dedicated WLAN communication modules. Thus, if the introduction of this technology is not mandated, OEMs will have to think about business models and vehicle equipment options, for example by packaging V2V, V2I, and certain ADAS features together in one dedicated option.”

“In the U.S., EU, and Japan different automotive-specific WLAN ad hoc network implementations are used today, so there is no global standard,” Rolfsmeier continues. “V2V and V2I may be mandated in the US in the next couple of years, however a final decision has not been made yet. As matters stand today, administrations in the EU do not tend to regulate the introduction of this technology.”

“Currently outside of the vehicle it’s going to be 802.11p. That’s at least the standard around which people are planning,” says Seidel. “The good news is that’s the standard that’s currently being embraced by North America and also Europe, but I’m also hearing that some of the cellular providers are starting to position what is called LTE Direct as an alternative. It’s early days, but this takes advantage of Wi-Fi and LTE modems, and we all know how fast those are advancing. So there we’ll see more options to increase speed and access to communication.”

“The harmonization of the individual automotive WLAN ad hoc network implementations is necessary to save development costs and time,” says Rolfsmeier. “Otherwise, automakers and tool suppliers like dSPACE might have to invest in all the different implementations if they intend to support V2V and V2I communication globally.

“We see regional-specific WLAN ad hoc network implementations as an intermediate solution for V2V and V2I,” Rolfsmeier says. “Vehicle-to-backend server (V2B) communication also seems to be an attractive use case for both automakers and car drivers. The associated V2B architecture consists of a 3G/4G LTE communication module in the vehicle, a backend server typically run by the OEM, and, for some features, an automotive cloud allowing the analysis and evaluation of thousands of vehicles using big data. In this context it is important to note that 3G/4G LTE is a common, non-automotive-specific worldwide standard, and associated communication modules will find their way into modern vehicles anyway due to the introduction of emergency call systems such as GM’s OnStar and BMW Assist. In addition, smartphones utilize 3G/4G, and a closer integration of smartphones in modern vehicles is imminent as well. Using mobile communication technology, vehicles are connected to backend servers in the cloud by means of which OEMs may provide specific services, over-the-air (OTA) software updates, or dynamic navigation data with the most recent information about maps, real-time traffic, road work, traffic signs, parking spaces, and other location-based services.

“Further, a new mobile communication network standard called 5G – the successor of 4G LTE – is currently being investigated,” he continues. “5G is supposed to be ready by 2020, and is said to also support low latency ad hoc device-to-device communication without requiring a mobile network supplier base station in between. If this comes true, 5G might be the technology of the future for V2V, V2I, and V2B.

V2X and autonomous vehicles – A two-way street

Though V2X architectures are still in their infancy, advances in technology, the evolution of standards, and collaboration across industry and government are converging to navigate the road to autonomous driving. Partnerships such as IBM and Continental’s Connected Electronic Horizon program, grassroots organizations such as Black Hat’s I Am The Cavalry (www.iamthecavalry.org), and industry consortia such as the Auto Alliance (www.autoalliance.org) are just a few examples of the synergies taking place around V2X technology in the automotive sector, the results of which are already being seen.

“At CES a term that was used by a few of the vendors was ‘swarm intelligence,’ Seidel says. “One of the applications that was shown by a few of the OEMs was parking space finders where a car used automatic parking to find a parking spot and automatic functions to leave the parking spot, and then communicated to other cars that there is now another parking spot available. So it’s not just a safety discussion, it’s an efficiency discussion – all of these things get enabled by V2X. You don’t need an autonomous car to benefit from V2X, but V2X and autonomous driving go extremely well together because you can steer an autonomous car much better than a non-autonomous one.

“Of course this is a topic where just by definition you have to resolve the conflict of there being a need for standardization while at the same time there being a need for the OEMs to differentiate their products,” he continues. “I think we’re on a good track, and this will be accelerated as the benefits of V2X in combination with autonomous driving become more clear. V2X will be developed hand-in-hand with autonomous cars, and we’re definitely working with our customers in that space. In the next 10-20 years you’ll see these two develop in parallel.”