Tapping into multiple services, both inside and outside a car, requires a rethinking of everything from architectures to security.
Carmakers are reworking their electronic architectures so they can tap into a growing number of external services and internal options, similar to the way a data center taps into various services over its internal network.
In the past, this has been largely confined to internal services such as on-board Internet connectivity, and external traffic routing and music. The current vision is to greatly expand those offerings through faster internal and external communications. But making that all work will require changes on multiple fronts.
The complexity in chips and systems in vehicles is exploding even without considering these new services. Automotive OEMs and their suppliers have been gradually increasing the number of ECUs in vehicles, along with multiple millions of lines of code to enable new features and capabilities. Now, with increasing levels of assisted and autonomous driving being added, that complexity has skyrocketed, rendering the old approach unsustainable.
As competition heats up, the long-established tiered supplier ecosystem is starting to re-orient itself around what consumers want, some of which may be offered by automakers and some of which will become available as infrastructure is built up around vehicles. That includes smart cities, vehicle-to-infrastructure, and localized edge services, and it impacts how communications are structured within a vehicle, how that data traffic is prioritized, and how the compute infrastructure is partitioned. It also determines which ECUs get consolidated, how all of this is tied together within a vehicle, as well as the overall software-driven, service-oriented architectures (SOAs).
SOAs are relatively new in the auto sector because until recently it’s been a one-to-one match between the software and hardware from the Tier 1 or 2 supplier, and they could not be unbundled.
“That’s gone with the changes happening within the automotive ecosystem,” noted David Fritz, senior director for autonomous and ADAS at Siemens Digital Industries Software. “New vehicle architectures are designed to solve very complex problems and get around a lot of the supplier and technology limitations of existing vehicles to ask, ‘How in the world do we architect software to fit that?’ Engineering teams are used to modeling in MATLAB, pushing a button, having the tool generate some C code for their controller, then be done. In a service-oriented architecture (SOA), you don’t even know where that software is going to run. You don’t know if it’s going to run in a hypervisor. You don’t know whether or not you’re going to have full control of that microcontroller, or if something could be downloaded much later that could impact your performance. How in the world do you do that? This points back to digital twins that need to provide simulation results to indicate where the boundaries are. At the same time, the design of the whole system software architecture is dramatically different because it is dynamically allocated, not statically allocated, and meshed one-to-one to the hardware.”
Utilizing service-oriented architectures
Another way to think about SOAs is in terms of the zonal architecture concepts that have been discussed more broadly in the industry.
For a service-oriented architecture, there are a few different ways to go about it, including a zonal approach. “When you look at the geography of the car, you have to consider how to chop things up,” said Kurt Shuler, vice president of marketing at Arteris IP. “As part of the ECU consolidation discussion, zonal can be one approach such that, for example, ‘the antilock braking system is usually next to this other subsystem, so let’s put those together, and we’ll make that one electronic system that’ll cover all that stuff.’ However, there are still some who say all of this is going to go together, like a centralized architecture where there is a common brain, which makes sense from a functional safety and redundancy standpoint.”
Zonal architectures are a big deal. “The whole automotive industry is moving to that new architecture because it’s required for autonomous driving to have a more centralized computing infrastructure, but also some distributed multi-purpose, zonal controllers that can take care of all the sensors, and so forth,” said Robert Schweiger, director of automotive solutions at Cadence. “In order to have this, you need high-speed in-vehicle communication, so Ethernet will evolve toward 10 gigabit very soon from 1 gigabit, where we are now. Also, the Automotive Service Alliance is putting its own standard in place for this, which is quite interesting because at the same time last year, MIPI released the MIPI A-PHYi, which should exactly address this thing. So now there are two competing standards going forward that will take us to 16 gigabit per second to solve the connectivity from the Ethernet network to the endpoints — the sensors, for instance — using SerDes type of communication. Within the cloud from ECU to ECU, or to the central computing unit, it will be definitely Ethernet. This means more OEMs will be adopting these high-speed communication standards, because it enables so many other things. With that, you need high-integration ECUs. The central compute units are really massive computers with very complex, very powerful SoCs sitting in the middle. Then, the zonal controllers, if they will be multi-purpose, smaller computing units, basically will evolve as an incarnation of the multiple consolidated ECUs that we have nowadays in the car.”
This is the general direction, but tradeoff discussions around how to structure the architecture are still evolving. Set in the context of Automotive Ethernet (AE) and the additional bandwidth that it brings, it is possible to boot up an entire vehicle using an SOA, with each individual components having its own boot flash.
“Here, it can come up and say, ‘I need access to these services, wherever those services are.’ It could be in the same printed circuit board, it could be on the other end of the vehicle, it could be anywhere, and it actually doesn’t matter where it is. Once you register for those services, if it’s monitoring, for example, a dashboard, there would be monitoring data sent to the speedometer and tachometer. The transmission could also send information,” Fritz explained.
From a functional standpoint, this requires a number of considerations. “With an SOA, a lot of functions are being virtualized that may have some interdependency,” Shuler said. “There could be some interdependency, or they could be completely independent of each other, running out of this single architecture. SOA essentially covers those two parts of the spectrum of where the processing is done, and then what is that processing, and what kind of services? What kind of capabilities does it provide to the vehicle and the overall system. This creates a conflict between, on one end, ‘I’m going to have a microprocessor for every function in the car,’ and ‘I’m going to run everything on a centralized mainframe.’”
It also has a ripple effect on other pieces of the system architecture.
“Whenever you’re dealing with software [like AUTOSAR], it’s great when you don’t have huge meta functions, and you’re able to slice these in there,” Shuler said. “But when there are huge functions, like for autonomous driving, this is where things get maybe more zonal/hierarchical. It’s a mother-daughter type system relationship between multiple aspects. And that’s from a hardware standpoint. There’s also a software brain controlling everything. But when you look at the actual hardware, it’s literally in different places. That’s because of modularity in the architecture based on the old subsystem approach. When there are different subsystems, you want to have some flexibility. There are starting to be more standards for data interchange and different types of processing, as well as the ability to do some pre-processing on the data. Then, instead of sending all the bits over, you can say, ‘Here’s this data format that shows what objects are over there, which could be from a lidar, radar, or camera, but the object classifications have to be there.”
There are a few ways automotive ecosystem players can start exploring SOA. The primary approach was borrowed from the robot industry, called ROS, or robot operating system.
“A few years ago, companies started applying the ROS service-oriented concept to prototype cars, and it’s still very new. Most people don’t even know that it’s needed, let alone exists, but it’s in a process of being reworked and revamped, and currently there are SOA architectures based on ROS,” said Siemens’ Fritz. “Early explorations into that highlighted the pros and cons, and we’re taking that now into the OEMs, saying, ‘Until you can sort out what you want, ROS is a really good place to start.’ The only question is, even if you’re using ROS, that’s kind of like the communication layer for an SOA. On top of that, you need semantic information. For instance, how do you find the right balance between what a smart city infrastructure does, and what the vehicle does onboard?”
Security concerns
There are security implications for smart city infrastructures interacting with a vehicle’s architecture, not all of which have been fully addressed.
“In the communication between cars and their surroundings, this brings up fundamental questions about performance and security,” Thierry Kouthon, technical product manager at Rambus Security said. “Here, security is mostly about authentication. You have to make sure that the car that is talking to you is actually a car, and that it is a genuine car from a genuine manufacturer, not some hacker, or some adversarial entity trying to send fake signals or jam your reactions. This requires public key cryptography in order for cars to authenticate each other, so I know that the 100 signals that I’ve received from all those cars that are surrounding me are from actual cars from Volkswagen, Mercedes, General Motors, etc.”
In order to do that, you need two things. First, a root of trust is essential to ensure that nobody can pervasively inspect the cryptographic processing, and the cryptographic operation while being processed.
“You need that on both sides,” Kouthon said. “In addition to the communication in the V2X context, security must be inside the vehicle itself. Modern cars are more like computers on wheels than what they were conceived of 50 years ago, for several reasons. A typical car contains 50 to 100 computers for steering, cruise control, entertainment, instrumentation, brake lights, you name it. It has a lot of components, with each of these components being computerized, and 70% of those components have been provided by suppliers to the OEM, not by the OEM itself. How do you make sure that everybody that is supplying something to you is genuine and that it’s not injecting the car with something malicious?”
Second, all these computers communicate via a network — the CAN bus — which is ubiquitous in cars, and typically is not featured with any security for cost reasons, Kouthon explained. “It’s not because the OEMs and Tier 1s don’t know how to make it secure. It’s because vehicle margins are slim. It’s a big bus. It’s a lot of wiring, and making it very secure will cost money, increase the car’s bill of materials, etc. The approach now is to put the security inside the electronic control units (ECUs), because each one of these ECUs has a computer inside the processor, and since we cannot secure the network between the processors, instead the processors are secured so that when they talk to each other, regardless of the communication medium, they can authenticate each other.”
For security in a smart city, it’s essentially about electronic warfare and countermeasures, and all devices utilized must be suited for those applications, said Willard Tu, director of automotive at Xilinx. “You want to make sure people aren’t spoofing your lidar or radar data, sending you misinformation. And that’s what happens in [a military] battle zone, and none of us want to think about it, but that’s what electronic countermeasures are trying to do — confuse your sensor array and take it over if possible.”
This is familiar ground for security, even though it’s an ongoing challenge. “Fundamentally, within those types of environments security always boils down into having base properties in place,” said Jason Oberg, CTO of Tortuga Logic. “You want to encrypt everything, making sure no one can steal the information. And then you want to make sure that all your information is signed and authentic, meaning that if I send something to another vehicle, or to a building, or to a sign or part of the infrastructure, that it’s authentically coming from me — and not an attacker on the side of the road with their laptop and an antenna, injecting material into the system that causes it to think it’s me, and then my car behaves differently. It sounds simple, but because everything is so distributed, it’s a mess of key management, and how to update who is who. How do I know that the keys that I have to say ‘I’m Jason,’ are the most up to date keys? Who’s the central owner of all that? On the Internet there are certificate authorities that say, ‘This is Google,’ so that when you go to Google, you can trust that it is Google. Everything that’s coming from them is signed. That same kind of infrastructure is needed for automobiles.”
All of this needs to be stored down at the hardware level in a vehicle. “In your laptop, you control it, unless someone steals it, and with infrastructure someone could just climb up a telephone pole and muck with something so it’s a different attack model,” Oberg said. “For this reason, it is really important to have everything routed down into the actual chip, and that’s where the root of trust is really important. Those keys need to be stored securely somewhere.”
Additionally, the level of communication that will be required to make it possible for vehicles to interface with any and all manner of infrastructure will be massive, and 5G is the obvious technology to enable it. That will ratchet up the need for edge computing, AI, and increased verification.
“The complexities involved with making sure these communications happen safely and securely will be astounding,” said Jorg Grosse, product manager for functional safety at OneSpin Solutions. “Formal verification will play a crucial role in the verification of the integrated circuits that will power this intelligent communication. The technology will go beyond simply making sure designs operate as intended. It also must ensure that safety and security vulnerabilities and weaknesses are eliminated.”
As smart cities evolve alongside autonomous developments, 5G is emerging as the common denominator.
“For V2X, they want to use 5G for the communications,” said Ron DiGiuseppe, automotive IP segment manager at Synopsys. “In fact, the 3GPP implemented specific features in 5G that would make it more useful for automotive, one of which is improved reliability, and of course, improved bandwidth. It’s important to make sure that if there’s also policy-based data rates, that they’ve added some prioritization. This means when data gets communicated over that 5G link, if someone in the back seat is streaming a movie for their rear seat entertainment, the last thing you want is that streaming data to interfere with the safety-critical data such as V2X or autonomous driving. 5G has specific features that allow it to prioritize the data. That helps for safety applications. When it comes to V2X and autonomous, the autonomous application uses 5G for that very high resolution mapping for the path planning, and the V2X uses 5G for the V2X communications. Then, the rear seat entertainment would be using 5G to stream the movie smoothly. This means we have to make sure both of those applications, the V2X and the autonomous — since they’ll both be running over 5G and need to share the bandwidth — will run simultaneously.”
Further, Grosse expects continuous product lifecycle verification to be adopted, as well, because there will be a wide range in the age of devices communicating with one another, while keeping up with the constant evolution of security requirements.
Conclusion
Given the complexity, and still-evolving SOA solutions, making the transition to SOA may be a nightmare.
“If you’re a traditional automotive player, you’re not used to dealing with a billion lines of code, or hundreds of millions of lines of code, or tens of millions of lines of code, but now you’re having to deal with that,” said Arteris IP’s Shuler. “If you’re a startup and you’re entering automotive, maybe you came over from some AI point of view. Or maybe you worked at a Qualcomm on digital baseband modems, and then you have all these other requirements, expectations, information sharing and things that you used to have 100% control over. Now you don’t, because of what your customers’ customer is saying is totally different. Everybody in the automotive ecosystem has to change. Traditional car suppliers have to get a little bit more flexible. The car companies have to learn to be more nimble, but that requires more risk. And then the folks who are coming into the industry from industries where risk was acceptable, they have to be more diligent about process and put in more bounding boxes.”
Link: https://semiengineering.com/big-changes-ahead-for-connected-vehicles/
Source: https://semiengineering.com