skip to Main Content

Driving Innovation Podcast: S2 EP1

Modern Networks are the backbone of SDVs

In this first episode of the Driving Innovation podcast, we provide an overview of the challenges and limitations of existing vehicle networks and how modern network technologies, standards and practices can be applied to in-vehicle networks to facilitate software-driven innovation.

Listen to audio only version:

Episode Transcript | Modern Networks are the backbone of SDVs

Introduction

SANJAY: Hello. Welcome to the first episode of the Driving Innovation podcast series from Sonatus. My name is Sanjay Khatri, Head of Product. In this series, we will be talking about the technologies and solutions that are driving the industry towards software-defined vehicles. In this first episode, we’ll be talking about how modern vehicle networks are essential for this move towards SDVs. And, in fact, you can even say that they are the backbone of SDVs. At its core, SDVs promise to deliver vehicles that continuously improve and add new features through software throughout their lifetime. Say an OEM wants to add a highway mode feature in which if the car sensors you’re driving on a highway, it automatically selects the driver’s preferred drive mode, the seat position, the audio settings, and the ambient lighting. With vehicle networks today, tying all of these functions across the different domains into a single unified experience is challenging and certainly not something that can be done after the vehicle is produced and sold. But that’s the type of personalized experiences SDVs are supposed to deliver. We clearly need networks that are flexible and versatile enough to deliver these types of integrated experiences. Much the same way modern networks have enabled cloud data centers to bring together different systems and applications like databases, user accounts, billing, messaging, end-user GUIs, etc., all into a seamless e-commerce experience. And as vehicles are increasingly starting to look like data centers on wheels, a similar shift to modern networking standards and practices are needed. Let me now hand it off to my colleague James Murphy, who will go through what specific challenges modern vehicle networks address and how.

Challenges and limitations with current vehicle networks

JIM: Thank you for the introduction, Sanjay. My name is Jim Murphy, and today I’m going to be talking about some of the challenges and limitations with the current vehicle networks and some of the solutions that we have as we move to an Ethernet backbone. The first problem is that the networks are static and hardwired and as such, it’s very challenging to integrate any new features into the existing networks. The second problem is that the networks are isolated, so the different domains operate in isolation, and the promise of being able to have multi-domain applications is severely restricted in that environment. The other issue with existing networks is there’s just simply not enough bandwidth with these technologies to support the modern sensors such as video that require high bandwidth on the network. Furthermore, it’s very difficult to provide quality of service for real time applications on a network with restricted bandwidth. There’s also an issue with security. With so many different network technologies in the vehicle, and so many different sensors and actuators and different devices connecting to the network, there are too many attack services to effectively secure the vehicle. And with all these disparate technologies, it’s also very difficult to effect a uniform security framework across the vehicle. The next problem associated with the current vehicle networks is associated with their physical construction. They’re costly, heavy and complicated wiring harnesses due to the fact that the networks themselves are duplicated throughout the vehicle, and this results in a very heavy and expensive to manufacture physical infrastructure. The other problem is if you do attempt to have interconnects between the networks to support more multi-domain applications, that just adds to the additional complexity associated with the wiring. The other problem is that the networks themselves are hard to monitor, troubleshoot and repair. This is also related to the diversity of network technologies and therefore the diversity of tools required to diagnose them. And then associated with this diversity is operational complexity associated with performing any diagnostics across the vehicle.

How modern vehicles address these challenges

JIM: So how do modern vehicle networks address these challenges? We move from a situation where we have dedicated physical infrastructure for each domain to a situation where we have a single physical infrastructure that supports all the domains in the vehicles. This allows us to reduce the wiring cost of all the physical network and additionally it makes the wiring more manufacturable because the runs of the individual network components are reduced. The second thing is that we have all ECUs are IP-reachable from all the other ECUs. So this enables all the multiple domain applications because any ECU can have access to data from any other ECU subject to whatever security restrictions we might want to apply. The other interesting thing is that the compute can be centralized on fewer high performance ECUs. So what used to perhaps run on a dedicated processor in a single domain, can now run on a shared processor. And therefore, we can help to reduce some of the costs of the ECUs in the vehicle itself. We’re also able to realize the service-oriented architecture. With a service-oriented architecture, individual applications can have access to any services across the network, and therefore implement the applications according to the availability of that data. We also enable certain cloud-native concepts such as application distribution, or application balancing across different compute resources throughout the vehicle. The applications themselves are built using standard IP technology, so we can leverage a lot of existing technology and put it to use in the vehicle. For example, one of the ECUs on the periphery of the network, or on the vehicle, could be like an LED controller. The LED controller can be controlled by a centralized controller that’s running on one of the high performance ECUs that would essentially be streaming video to the LED system, and therefore reusing a lot of well-known technology to support such applications. Now, when we move all of this data onto a single infrastructure, we have certain issues that crop up because now we’re going to be mixing different criticality data, so we’ll have real time data mixed in with bulk or just general data, and therefore we need protocols to deal with this. The IEEE has standardized the time sensitive networking standardization, which allows us to run certain protocols or use certain techniques in the network to support real time traffic alongside other low priority traffic. Finally, we have high bandwidth, so we have everything from the 10BASE-T1S to gigabit Ethernet, and we can use the high bandwidth to not only support some of the high bandwidth devices such as video, but also to help us to achieve the real time QoS requirements.

Securing networks with MACsec

JIM: So as we mentioned, we have a new security issue in the vehicle now that we have a lot of different devices connected to the network and using network resources. And if the network is not secured, we open up ourselves to issues associated with safety, privacy and theft. Fortunately, Ethernet has a long history of dealing with security, and it does it through a protocol called MACsec, also IEEE 802.1AE, which is a proven security solution used in existing wired networks. It provides integrity, confidentiality and stops unauthorized access. It secures LAN segments. It’s not an end-to-end technology. So each LAN segment creates something called a connectivity association, which is comprised of a set of channels and there’s one channel for each sender on that segment. When MACsec is deployed on one of these on one of these segments, the data across a network cannot be eavesdropped, and it’s also guaranteed to have integrity, which means that it can’t be spoofed by some other device. Furthermore, a device can’t gain access to the network without being authenticated. MACsec uses 802.1X for authentication, authorization and key management 802.1X is also a proven security solution used widely, f or example, in enterprise Wi-Fi environments. With 802.1X, you can establish the authentication or identity of any device that connects to the network, and this opens up certain opportunities for identity-based networking, which is the concept of being able to apply policies to devices based on their identity. Additionally, Ethernet switches provide additional security features such as access control lists that can be applied on authenticated clients to ensure that they’re only generating traffic that’s been approved for transmission on the network. The network also provides support for mixed criticality applications.

Mixed criticality

JIM: So what does actual mixed criticality mean? Or what is critical traffic? Critical traffic is traffic that is essentially real time in nature, meaning that it has to be delivered with high priority, low latency and with very little or no loss. Now how we do this in an Ethernet network is we actually use the fact that we have a sufficient amount of bandwidth to support all of the high performance traffic or all the real time traffic, and we police that traffic on Ingress to ensure that there’s always bandwidth available to transmit the high priority traffic. And then what we do is we install at each egress point in the network, a scheduler, it could be a credit-based scheduler or a time-aware scheduler to schedule the traffic to ensure that it gets priority above any other best-effort traffic in the network. And this helps to keep the latency at a low value. Now, this can’t work well if we don’t actually have the traffic classified. And furthermore, we have to police the traffic, so on ingress into the network, the traffic is classified as high-priority traffic using various packet fields, and then we go ahead and police the traffic to ensure that the traffic fits within the bandwidth that we’ve allocated for that particular flow. And then, of course, we schedule it on the egress of all interfaces, with priority to ensure that the latency is kept at a low value. So in order for all this to work, we need to have a network that is managed centrally, and the reason we need the centralize management is because the network management needs to be aware of all TSN flows within the network. So it needs to provision the network holistically.

Centralized network management

JIM: Secondly, we need a network control plane that’s dynamic. This allows us to realize the promise of the software-defined vehicle where we can upgrade the network at any time as new applications or as problems are found in the field and we want to change the behavior of the network to address them. However, this is not going to be your typical software-defined network that we see in today’s data centers because a vehicle has certain safety and other critical requirements that we just can’t change the configuration at any time, so it has to be done in a way that’s safe, and it has to be done also in a way that ensures that we honor the existing stringent boot time requirements of the vehicle. The itself and its network needs to be cloud managed because without cloud managed, you know, it’s very difficult to be able to upgrade the vehicle in the field. And furthermore, having the centralized network that’s cloud managed, we’re also able to simplify diagnostics, because the in-vehicle network controller understands all the flows in the network, which switches they’re running through, and if there are any issues, then we can figure out based on this configuration, which switches from which to gather the stats to help to debug the problem. We can also do various things like checking for packet flows, sniffing the network and analyzing that information.

Conclusion

SANJAY: Thanks, Jim. So as you can see, modern vehicle networks can accomplish a lot of the things that software-defined vehicles are intended to accomplish, which is to provide the seamless experience to customers, where you can have multi-domain applications that provide a holistic experience to the end users. So what are the benefits to the OEM and the consumers? So first of all, the OEM benefits from simpler, cost-effective networks that help them add new features, make changes to the vehicle, even after production, in a very efficient and cost-effective manner. For the end consumer, it means getting experiences that are very seamless across the vehicle, using multi-domain functions, whether it’s ADAS, the IVI, the drivetrain, combining all of those into more personalized, safer and more convenient experiences. So that concludes our first episode of Driving Innovation. Stay tuned for more, where we will be digging deeper into some of these topics. Thank you.

Recent episodes

Driving Innovation Podcast

Introducing the Driving Innovation podcast

Related resources

White Paper

Modern Networks are the Backbone of SDVs

The rise of Software-Defined Vehicles (SDVs) promises a new era in automotive technology, where vehicles continuously improve and new features…
test
Blog

Sonatus Zonal Architecture Solution

Zonal architectures are a key building block for Software-Defined Vehicles The concept of the Zonal Architecture to support the needs…
Back To Top