The amount of data being collected, processed, and stored in vehicles is exploding, and so is the value of that data. That raises questions that are still not fully answered about how that data will be used, by whom, and how it will be secured.

Automakers are competing based on the latest versions of advanced technologies such as ADAS, 5G, and V2X, but the ECUs, software-defined vehicles, and in-cabin monitoring also demand more and more data, and they are using that data for purposes that extend beyond just getting the vehicle from point A to point B safely. They now are vying to offer additional subscription-based services according to customers’ interests, as various entities, including insurance companies, indicate a willingness to pay for information on drivers’ habits.

Collecting this data can help OEMs gain insights and potentially generate additional revenue. However, gathering it raises privacy and security concerns about who will own this massive amount of data and how it should be managed and used. And as automotive data use increases, how will it impact future automotive design?

Fig. 1: Connected vehicles rely on software to communicate between vehicles and the cloud. Source: McKinsey & Co.

“Much of the data generated in the vehicle will have immense value to OEMs and their partners for analyzing driver behavior and vehicle performance and for developing new or enhanced features,” said Sven Kopacz, autonomous vehicle section manager at Keysight Technologies. “On the other hand, the privacy of data use can be viewed as a risk to some. But the real value – as already implemented and used by Tesla and others – is the constant feedback to improve those ADAS algorithms, enable a CI/CD DevOps software development model, and allow the rapid download of updates. Only time will tell if law enforcement and the courts will demand this data and how lawmakers will respond.”

Types of data generated
According to Precedence Research, the global automotive data market size will grow from $2.19 billion in 2022 to $14.29 billion by 2032, with many types of data collected, including:

• Autonomous driving: Data on all levels, from L1 to L5, including that collected from the multiple sensors installed on vehicles.
• Infrastructure: Remote monitoring, OTA updates, and data used for remote control by control centers, V2X, and traffic patterns.
• Infotainment: Information on how customers are using applications, such as voice control, gesture, maps, and parking.
• Connected information: Information on payment to third-party parking apps, accident information, data from dashboard cameras, handheld devices, mobile applications, and driver behavior monitoring.
• Vehicle health: Repair and maintenance records, insurance underwriting, fuel consumption, telematics.

This information may be useful for future automotive design, predictive maintenance, and safety improvements, and insurance companies are expected to be able to reduce underwriting costs with more comprehensive information on accidents. Based on the information collected, OEMs should be able to design more reliable and safer cars, and to stay in close touch with customer wants. For example, experiments can be conducted to gauge customer demand for subscription-based services such as automatic parking and more sophisticated voice input and commands.

“Diagnostic data for service and repair has been a core of automotive data analytics for decades,” noted Lorin Kennedy, senior staff product management manager for SLM in-field analytics at Synopsys. “With the advent of connected vehicles and advanced machine learning (ML) analytics, which enable a greater quantity of data to be routinely processed, this data has gained exponentially in value. As data drives feature enhancements such as mobile-like experiences and advanced driver assist capabilities, OEMs increasingly need to better understand the dependability and reliability of the semiconductor systems powering these new features. The collection of monitoring and sensor data from electronic components and the semiconductors themselves will be a growing diagnostic data requirement across all types of automotive technologies like ADAS, IVI, ECUs, etc. to ensure quality and reliability on these more advanced nodes.”

Anticipated updates to ISO 26262 regulations regarding the application of predictive maintenance to hardware, identifying degrading intermittent faults caused by silicon aging, and over-stress conditions in the field are areas to be addressed, as well. Those can include silicon lifecycle management (SLM) technologies, which can deliver more comprehensive knowledge about the health and remaining useful life of silicon as it ages.

“That knowledge, in turn, will enable service updates and future OTA releases that leverage additional semiconductor compute power,” Kennedy said. “Overall fleet performance will benefit, and the semiconductor and system design process will, too, as new insights help achieve greater efficiencies. OEM, Tier One, and semiconductor supplier collaboration on what the data brings to light – from silicon to software system performance – will enable vehicles to meet the functional safety design parameters that are becoming increasingly crucial in advanced electronics.”

Still, for data generated in vehicles, OEMs will need to prioritize which data can provide value for drivers immediately, and which data should be sent to the cloud via 5G connections.

“Tradeoffs between on-board processing to reduce data volume and data transmission network costs will likely dictate prioritization,” Keysight’s Kopacz said. “For example, camera, lidar, and radar sensor data for ADAS applications may have value for training ADAS algorithms, but the volume of raw data will be very costly to transmit and store. Likewise, driver attention data can have high value in UI design, and would be best gathered in a meta-data form. V2X data has a relatively lower data volume and should ultimately be a key data source for ADAS, providing in-car non-line-of-sight visibility of other vehicles, road infrastructure, and road conditions. Sharing this over V2N links can enable effective safety applications, but angle random walk (ARW) sensor data needs to be considered more carefully due to its complex nature. Infotainment streaming content into the vehicle also can be a valuable revenue stream for OEMs, and the content providers as well, as network operators working together.”

Impacts on automotive cybersecurity
As vehicles become more autonomous and connected, data use will increase, and so will the value of that data. This raises cybersecurity and data privacy concerns. Hackers want to steal personal data collected by the vehicles, and can use ransomware and other attacks to do so. The idea of taking control of vehicles — or worse, stealing them — also attracts hackers. Techniques used include hacking vehicle apps and wireless connections on the vehicles (diagnostics, key fob attacks and keyless jamming). Protecting data access, vehicles, and infrastructure from attacks is increasingly important and challenging.

Cybersecurity risks increase with software-defined vehicles. Memory especially will need to be safeguarded.

“The integration of advanced technology into EVs poses significant cybersecurity challenges that demand immediate attention and sophisticated solutions,” said Ilia Stolov, center head of secure memory solution at Winbond. “Central to the digital fortresses within modern electronic platforms are flash non-volatile memories, housing invaluable assets like code, private data, and company credentials. Unfortunately, their ubiquity has rendered them attractive targets for hackers seeking unauthorized access to sensitive information.”

Stolov noted that Winbond has been actively working to secure flash memory from hacks.

Additionally, there are important considerations in securing memory designs, such as:

• DICE root of trust: The Device Identifier Composition Engine (DICE) should be used to create the secure flash root of trust for hardware security. This secure identity forms the basis for building trust in the hardware. Other security measures can therefore rely on the authenticity and integrity of the boot code, protecting against firmware and software attacks. The initial boot process and subsequent software execution are based on trusted and verified measurements, helping prevent the injection of malicious code into the system.
• Code and data protection: Protecting code and data is crucial for maintaining system-wide integrity. Unauthorized modifications to code or data can lead to malfunctions, system instability, or the introduction of malicious code, compromising the hardware’s intended functionality or exploiting system vulnerabilities.
• Authentication protocols: Authentication is a fundamental and crucial component of cybersecurity, serving as the frontline defense against unauthorized access and potential security breaches. Employing authentication protocols to restrict access to authorized actors and approved software layers only using cryptography credentials is important.
• Secure software updates with rollback protection: Regular updates extend beyond bug fixes including remote firmware over-the-air (OTA) updates, guards against rollback attacks, and ensures the execution of only legitimate updates.
• Post-quantum cryptography: Anticipating the post-quantum computing era to include NIST 800-208 Leighton-Micali Signature (LMS) cryptography safeguards EVs against the potential threats posed by future quantum computers.
• Platform resiliency: Automatic detection of unauthorized code changes enables swift recovery to a secure state, effectively thwarting potential cyber threats. Adhering to NIST 800-193 recommendations for platform resiliency ensures a robust defense mechanism.
• Secure supply chain: Guaranteeing the origin and integrity of flash content throughout the supply chain, these secure flash devices prevent content tampering and misconfiguration during platform assembly, transportation, and configuration. This, in turn, safeguards against cyber adversaries.

Considering the transition to SDVs and connected cars, data vulnerability becomes even more significant.

“Depending on where data resides, different protection measures are in place,” said Keysight’s Kopacz. “Intrusion detection systems (IDS), crypto services, and key management are becoming standard solutions in vehicles. Especially sensitive data for safety features needs to be protected and verified. Thus, redundancy becomes more relevant. With SDVs, the vehicle software is constantly updated or changed throughout the entire vehicle life cycle. Ever-evolving cyber threats are particularly challenging. Accordingly, the entire vehicle software must be continuously checked for new security gaps. OEMs are going to need comprehensive testing solutions to minimize security threats. This will need to include the cybersecurity testing of the entire attack surface, covering all vehicle interfaces – wired vehicle communication networks such as CAN or automotive Ethernet or wireless connections via Wi-Fi, Bluetooth, or cellular communications. OEMs will also need to test the backend that provides over-the-air (OTA) software updates. Such solutions can reduce the risk of damage or data theft by cybercriminals.”

Data management and privacy concerns
Another issue to be resolved is how the massive amount of data collected will be managed and used. Ideally, data will be analyzed to yield commercial value without causing privacy concerns. For example, infotainment platform data might reveal what types of music are most popular, helping the music industry to improve marketing strategies. Who will monitor the transfer of such data, though? How will customers be made aware of the data collection? And will they have an opportunity to opt out of having their data sold?

As with airplanes, vehicle black boxes are installed to record information for analysis of the data after an accident occurs. The information recorded includes vehicle speed, the braking situation, and the activation of air bags, among other things. If an accident occurs resulting in a fatality, and the data from ADAS and ECU uncover vulnerability in the designs, could that data be used as evidence in court against manufacturers or their supply chains? Armed with this information, the insurance industry may decline claims. Would one or more manufacturers of the ADAS/ECU be required to hand over the data when ordered by the authorities?

“Quality requirements for sophisticated electronic parts will continue to become more rigid and strict, allowing only a few defective parts per billion (DPPB) due to the impact failed components can have on the safety and well-being of human life,” noted Guy Cortez, senior staff product management manager for SLM analytics at Synopsys. “SLM data analytics will continue to play a substantial role in the health, maintainability, and sustainability of these devices throughout their life within the vehicle. Through the power of analytics, you can do proper root cause analysis of any failed device (e.g., return merchandise authorization, or RMA). What’s more, you will also be able to find ‘like’ devices that ultimately may exhibit similar failed behavior over time. Thus empowered, you can proactively recall these like devices before they fail during operation in the field. Upon further analysis, the device(s) in question may require a design re-spin by the device developer in order to correct any identified issue. With a proper SLM solution deployed throughout the automotive ecosystem, you can achieve a higher level of predictability, and thus higher quality and safety for the automotive manufacturer and consumer.”

OEM impact
While modern cars have been described as computers on wheels, they are now more like mobile phones on wheels. OEMs are designing cars that do not skimp on features. Semi-autonomous driving, voice-controlled infotainment systems, and the monitoring of many functions—including driver behavior— are yielding a large amount of data. While that data can be used to improve future designs. OEMs’ approaches to security and privacy vary, with some offering stronger security and privacy protection than others.

Mercedes-Benz is paying attention to data security and privacy, and is compliant to UN ECE R155 / R156, a European norm for cybersecurity and software update management systems, according to the company. Which data is processed in connection with digital vehicle services depends on which services the customer selects. Only the data required for the respective service will be processed. Additionally, the “Mercedes me connect” app’s terms of use and privacy information make it transparent for customers to see what data is needed for and how it is processed. Customers can determine which services they want to use.

Hyundai indicated it would follow a user-centric focus, prioritizing safety, information security, and data privacy with fault-tolerant software architectures to enhance cybersecurity. Hyundai Motor Group’s global software center, 42dot, is currently developing integrated hardware/software security solutions that detect and block data tampering, hacking, and external cyber threats, as well as abnormal communication using big data and AI algorithms.

And according to the BMW Group, the company manages a connected fleet of more than 20 million vehicles globally. More than 6 million vehicles are updated over-the-air on a regular basis. Together with other services, more than 110 terabytes of data traffic per day are processed between the connected vehicles and cloud-backend. All BMW vehicle interfaces permit consumers to opt in or out of various types of data collection and processing that may happen on their vehicles. If preferred, BMW customers may opt out of all optional data collection relating to their vehicles at any time by visiting the BMW iDrive screen in their vehicle. Additionally, to completely stop the transfer of any data from BMW vehicles to BMW services, customers can contact the company to request that the embedded SIM on their vehicles be disabled.

Not all OEMs hold the same philosophy on privacy. According to a study on 25 brands conducted by the Mozilla Foundation, a nonprofit organization, 56% will share data with law enforcement in response to an informal request, 84% share or sell personal data, and 100% earned the foundation’s “privacy not included” warning label.

More importantly, are customers educated or informed on the privacy issue?

Fig. 2: Once data is collected from a vehicle, it can go to multiple destinations without the knowledge of customers. Source: Mozilla, *Privacy Not Included.

Applying data to automotive design in the future
OEMs collect many different types of automotive data in relation to autonomous driving, infrastructure, infotainment, connected vehicles, and vehicle health and maintenance. The ultimate goal, however, is not just to compile massive raw data; rather, it is to extract value from it. One of the questions OEMs need to ask is how to apply technology to extract information that is really useful in future automotive design.

“OEMs are trying to test and validate the various functions of their vehicles,” said David Fritz, vice president of virtual and hybrid systems at Siemens EDA. “This can involve millions of terabytes of data. Sometimes, a huge portion of the data is redundant and useless. The real value in the data is, once it gets distilled, that it’s in a form where humans can relate to the meaning of the data, and it also can be pushed into the systems while they’re being developed and tested and before the vehicles are even on the ground. We’ve known for quite some time that many countries and regulatory bodies around the world have been collecting what they call an accident database. When an accident occurs, the police show up on the scene collecting relevant data. ‘There was an intersection here, a stop sign there. And this car was traveling in this direction roughly this many miles an hour. The weather condition is this. The car entered the intersection in the yellow light and caused an accident, etc.’ This is an accident scenario. Technologies are available to take those scenarios and put them in a standard form called Open Scenario. Based on the information, a new set of data can be generated to determine what the sensors would be seeing in those accident situations, and then push it through both a virtual version of the vehicle and environment and in the future, and push those scenarios through the sensors in this physical vehicle itself. This is really the distillation of that data into a form that a human can wrap their mind around. Otherwise, you could collect billions of terabytes of raw data and try to push that into these systems, and it wouldn’t actually help you any more than if someone were sitting in a car and dragging those for billions of miles.”

But that data also can be very useful. “If an OEM wants to obtain safety certification, say in Germany, the OEM can provide a set of data of scenarios on how the vehicle will navigate,” Fritz said. “An OEM can provide a set of data to the German authority, with a set of scenarios to prove the vehicle will navigate in a safe manner under various conditions. By comparing that with the data in the accident database, the German government can say that as long as you avoid 95% of the accidents in that database, you’re certified. That’s actionable from the perspectives of human drivers, insurance, engineering, and visual simulation. The data prove the vehicle is going to behave as expected. The alternative is to drive around, as in the case of autonomous vehicles, and try to justify the accident was not caused by the vehicle, while facing the lawsuit. It does not seem to make sense, but that’s what’s happening today.”

Related Reading
Curbing Automotive Cybersecurity Attacks
A growing number of standards and regulations within the automotive ecosystem promises to save developments costs by fending off cyberattacks.
Software-Defined Vehicles Ready To Roll
New approach could have big effects on cost, safety, security, and time to market.

The post Increased Automotive Data Use Raises Privacy, Security Concerns appeared first on Semiconductor Engineering.

Experts at the Table: Semiconductor Engineering sat down to discuss Vehicle-To-Everything (V2X) technology and the path to deployment, with Shawn Carpenter, program director for 5G and space at Ansys; Lang Lin, principal product manager at Ansys; Daniel Dalpiaz, senior manager product marketing, Americas, green industrial power division at Infineon; David Fritz, vice president of virtual and hybrid systems at Siemens EDA; and Ron DiGiuseppe, senior marketing manager, automotive IP segment at Synopsys. What follows are excerpts from that conversation.

L-R: Ansys’ Carpenter; Ansys’ Lin; Infineon’s Dalpiaz; Siemens EDA’s Fritz; Synopsys‘ DiGiuseppe.

SE: What is the potential of vehicle-to-everything technology, and what role will the semiconductor ecosystem play in making this a reality?

DiGiuseppe: V2X is a technology that’s not just years, but decades, in the making. It initially started as a dedicated short-range communications (DSRC) type of technology, and has globally transitioned into a cellular technology, although many of those V2X applications are not just cellular. There are other spectrum allocations V2X can run on, including WiFi or other general-use technology. So it’s not limited to cellular. Also, it’s not just a technology. It’s an application, an outcome, and there are a lot of valuable uses, many of which are safety-related, but there are others, such as efficiency of traffic management notifications. V2X has a wide number of uses. The deployment will be done in stages, and there’s a lot of activity even though it’s taken a long time.

Lin: When I see the keyword V2X, it reminds me of everything about how the car can communicate with anything in the world. It’s a very exciting moment that we’re here today to be able to make some kind of technology to enable great communication between vehicles and people, in network infrastructures and car to car communications. Today, there is already something implemented. For instance, in car network systems we can connect our phone to the car already, but we’re still in the first mile. We’ve started on the journey, but we have a long way to go as far as how to connect car-to-car, how to connect the car to the entire infrastructure of networks, and to the internet. There are a lot of unknowns on the road while we start driving on this journey, and safety and security are definitely the biggest concerns. What if my network is being jeopardized?

Dalpiaz: V2X is part of a much bigger smart grid ecosystem. This will certainly play a very important role, especially as the grid becomes smart and decentralized. This is what will enable the future energy ecosystem, having renewable energies, energy storage systems all connected. And as we see more EVs being used as mobile battery storage. this is something that will certainly enable, and is part of, a smart grid ecosystem that everybody’s talking about.

Fritz: The days of independent semiconductor and software development are over. It is the need for OEMs to control their own destiny, driven by growing consumer and competitive demand, that has all but eliminated the ability to sell a one-size-fits-all product. We’ve known for a very long time that software needs to drive semiconductors, and semiconductors need to drive software. This symbiotic relationship, and the tools and methodologies needed to support this paradigm shift, are essential to producing a highly successful, complex, and competitive solution that meets consumer demands.

SE: What are the discrete pieces of V2X that need to be connected?

Dalpiaz: From the semiconductor point of view, especially with the usage of wide bandgap materials, a few companies are seeing that it’s possible to increase efficiency and power density. Being able to not only provide such solutions, but have everything connected in one box, is part of the smart ecosystem. Then, having the electric vehicles, energy storage, solar — everything combined into one box. Twenty years ago, before the iPhone, we used to have a fax machine, a camera for photographs, a computer. The future of this ecosystem is going to have one box sitting in your home, and have all this stuff connected together. So from the semiconductor point of view, especially with silicon carbide, it is something that is possible today, and it can achieve a very high level of efficiency — about 99%, very close to 100%. And of course, we need to make the system smaller to fit in a vehicle.

DiGiuseppe: One of the key stakeholders is the cellular companies. When we look at cellular V2X, one of the main challenges is interoperability. You have different devices in different model-year cars, so for the vehicle-to-vehicle communications, those different devices need to be interoperable. Then, the car will be talking to the infrastructure, so the roadside units need to be interoperable with the cars and devices in the cars. Then, of course, you have vehicle-to-pedestrians, vehicle-to-e-mobility like vehicle-to-bicycles, vehicle-to-motorcycles interoperability between all the devices over the medium. Whether it’s cellular or Wi-Fi or other technologies, it all needs to be interoperable. That will allow deployments in one locality to work in another locality, because even if they’re interoperable in one deployment in one region, we’ve got to make sure they’re also interoperable in other regions. So it’s a large scale interoperability goal.

Lin: Ron, you’re talking about interoperability, and Daniel talked about the ecosystem. From my side, I would also mention some standards are necessary. For EDA, to help build such an ecosystem and chips, we need some rules to give to engineers as to what’s to be followed. There are two important standards in my mind. One is the vehicle safety standard ISO 26262, which regulates a couple of safety standards for on-road vehicle chip design. Another is the cyber security standard, ISO 21434. If I make a tool, I probably will follow those standards, and then think about how the tool could help users decide a pass/failure criteria regarding their design, making sure to meet the security and safety target from the standard.

DiGiuseppe: In addition to standards, last October the U.S. Department of Transportation released its national V2X deployment plan. That plan, which is still in draft feedback stage, lays out — at least in the U.S. — the whole timeline for deployments. That kind of oversight plan overlays onto the standards that Lang was just talking about. That deployment plan outlines the different contributions from all the different stakeholders, from the automakers/OEMs to the software developers for the applications. So overlaid on top of standards is a deployment plan, and a government deployment plan outlines that. Plus, there are a lot of government stakeholders, like the FCC allocating spectrum, and the Department of Transportation deploying all these deployments, and that’s in addition to the technology providers.

Fritz: It would take days to adequately answer those questions, but at the core, the root design components are connectivity, power, performance, and acceleration. Connectivity with the proper protocols allows computational tasks to be distributed. This is particularly important in automotive, where the physical distance between sensing, actuating and computing nodes is critical for predictable performance. In the case of V2X, connectivity enables the normalization of external data, whether it involves smart city infrastructure or another vehicle. It’s important to note that the form of the shared data grows exponentially with the capacity to describe the environment, and therefore the compute requirements to process and understand it. For example, a data form that can describe signage in the U.S. is relatively small, but one that is universal with variations recognizable is much larger and more ambiguous. This drives design parameters that directly impact manufacturing, development, and service cost functions. Further, the normalization of the data has an impact on the overall design and design component interactions. In the case of power, it goes without saying that high compute requirements, and the associated necessary cooling, can have a significant impact on EV range and manufacturing costs. Performance can take many forms, but as software loads increase with hypervisors, specialized operating systems, and protocol stacks, not to mention very complex application software, all must meet stringent mission critical requirements. Finally, acceleration is of growing importance because it allows workloads to be handed off to specialized hardware that is better equipped to handle that load. An example is running AI inferencing on a CPU is typically far slower and more power-hungry than on an NPU, but a GPU could be idle and available to do the same task. On the other hand, a small CNN can be handled quite easily on a CPU with a few simple instructions. It is at the intersection of these major design components where an OEM will find its differentiation. Therefore, having a system capable of exploring this complex hardware and software space quickly, and with a small team, is critical for an OEM to demand of its suppliers what is required for the success of its platforms. Again, controlling your own destiny is essential to survival.

SE: With all of this interoperability, what happens when there are parts of the ‘everything’ — whether it’s the car or the infrastructure or pedestrians — that are not updated with the latest technologies or different aspects of what needs to be there for conductivity?

DiGiuseppe: In addition to that challenge, this includes backward compatibility for automotive. For someone buying a car in 2025, you would expect any V2X technology to work in 2040. But in the meantime, all those standards that we’re talking about are continuing to evolve, so they need to be backward compatible.

Carpenter: This highlights the need for a digital twin capability for modeling this infrastructure to be able to understand that when we get two years down the road, some devices may not be reprogrammable. We may not be able to flash a particular device. We need to be able to look at that, and be able to simulate that in advance to understand what will happen. What will this do? We’re seeing this show a little bit, even giving a nod to what Ron was talking about earlier with interoperability. We have customers who want to be able to validate real hardware stuff that they’re developing on the lab bench, but they want to do it with the fidelity of a real system operating on a car, in a virtual city, with the live interaction of the channel with a gNodeB 5G base station mounted up on a building someplace, and they want to know how this will work in the context of the situation that it’s supposed to serve. And if something goes wrong in that scene, can we introduce something into this device and run our real silicon development platform against it to understand what happens here. If we go into a deep shadow, a deep fade area, and I’m not getting updates, yet I’m hurtling down the road at a certain speed, how long can I do this before I receive corrective information? What if someone’s software deck out there doesn’t get reprogrammed or doesn’t get the latest version of the standard safety protocols or something like that? We’re going to need this ability to carry models of stuff that was built two or three years ago in today’s infrastructure, model that, and understand in advance what’s going to happen with it so that we have an approach to do this. This is what the Department of Defense is doing today with their digital thread enablement, to have a way to capture that with legacy models of what they built years ago, but apply it in modern missions and understand, ‘Does it work? Does it fit? Does it not fit? What do we need to do to the existing system to make sure that we’re safe here?’ That is an approach we clearly see the automakers beginning to look at as a way to future-proof some of these systems and make sure that they’ve got a way to test them as they go forward.

Fritz: It’s become very clear from several popularized incidents that simply stopping and waiting for tech support to find you and get you going again is not going to be a successful strategy. In the end, the vehicle must make decisions at least as thoughtful as an average human would make. This is entirely possible, but not if too much emphasis is placed in the design phase on the dependencies between communicating (or non-communicating) actors. For this reason, we will always require sophisticated decision-making in-vehicle to be widely accepted.

SE: How does the design team stay up to date with everything?

DiGiuseppe: On the vehicle side, they’re going to be relying on over-the-air (OTA) software updates, which is relatively new in the automotive industry. But clearly, once we identify a software update, we’re going to need to roll out that software update, and OTA is obviously going to be used hand-in-hand with the updates to V2X as it moves forward.

SE: From a developer standpoint, they have to design to these all these regulations. What are the issues here?

Lin: As a software developer, if you think about a vehicle 10 years ago, you mainly just replaced hardware. You replaced your brakes, you replaced your engine, adding some fluid. These are all old styles. Right now, if you have the V2X network, you’d expect probably daily updates because software is evolving daily, and your whole communication system infrastructure is under the whole internet evolution, so you’re going to have to keep pace with it. That’s a lot of work for developers.

Carpenter: There could be implications on edge processing. The telecommunications providers are going to need to put a lot more compute closer to the radio head, and clearly they’re already exploring the possibilities of getting not just central processing cores, CPU cores, but there will be GPU cores and Tensor Processing Units, and we don’t know what all yet for AI, that will be a part of this safety infrastructure and information/infotainment delivery. There’s a lot more compute that’s going to have to happen with a much shorter latency. Augmented reality with heads-up displays — imagine the possibilities coming in safety systems with heads-up displays in cars. Then imagine the amount of processing that it’s going to take. So the telecom providers will need to be a major part of that, together with most of the local government regulatory groups that are going to foster that safety system. Each municipality probably has to decide what do they adopt, what level of standard will they use, and deliver. Who invests in that? The future is really exciting, but there are a few things yet to be sorted out in terms of the investment needed to really deliver that promise.

Dalpiaz: I’m more in the infrastructure side, and one of the questions we always have is, ‘With all this focus on renewables and decentralization of the grid, can the grid handle such expectations or such projects?’ Having more people connecting and feeding energy back into the grid, and managing all of this, that’s always the question that you have to go through and consider.

Fritz: The fact is that keeping up to date is not practical. However, that doesn’t mean that a methodology cannot be employed to accept changes into the development system, and therefore be folded into the development process. CI/CD systems with digital twin golden models already are being developed, with nightly regressions run against complex (and possibly changing) requirements. In this way, requirement changes are automatically addressed as they occur, and solutions can be rolled into an Agile methodology through nightly regressions. This is an important benefit of a modern development methodology that has been used in other industries for years, but it’s just now finding purchase in progressive automotive companies.

Related Reading
Growing Challenges For Increasingly Connected Vehicles
OEMs have high expectations for connected vehicles and global growth opportunities, but it’s not that simple.
Software-Defined Vehicles Ready To Roll
New approach could have big effects on cost, safety, security, and time to market.

The post V2X Path To Deployment Still Murky appeared first on Semiconductor Engineering.