Software Defined Vehicles
Interview with Priya Muralidharan, Infineon
“Mixed-criticality workloads challenge safety architectures”
As vehicles move towards L3+ autonomy, edge AI, functional safety and open architectures are redefining system design. Priya Muralidharan, Director Marketing at Infineon, explains how validation, safety concepts and RISC-V shape next-generation automotive compute.
As automotive architectures evolve towards higher levels of autonomy, the interaction between edge AI, functional safety and compute platforms is becoming increasingly complex. What initially appeared as a question of software capability is now shifting towards system-level considerations, including safety assurance, validation and hardware architecture.
Priya Muralidharan, Director Marketing at Infineon, brings extensive experience across semiconductor strategy, functional safety and automotive systems, including ADAS, SDV and battery management. At the Automotive Computing Conference in Detroit, she addressed how edge AI, safety microcontrollers and RISC-V architectures are shaping next-generation autonomy. After the event, we spoke with her about the technical and architectural challenges of scaling SDV platforms.
ADT: How does the rise of edge AI change functional safety requirements in vehicles?
Muralidharan: AI is inherently non-deterministic, which challenges the ISO 26262 safety standard. To address aspects of AI in safety – including rigorous validation methods and verification of training data quality – additional standards are being defined to complement ISO 26262. One such standard is ISO/PAS 8800, which addresses unintended AI behaviour.
Advertisement
What role do safety microcontrollers play as autonomy levels increase beyond L3?
Safety microcontrollers are critical to achieving the highest level of safety for L2+/L3 autonomy. As autonomy levels increase, the highest functional safety requirements (ASIL D, in ISO 26262 terminology) shift earlier in the sense–plan–control pipeline. In addition, fail-safe and fail-operational requirements become necessary for L3 safety. Microcontrollers designed for low latency, hardware robustness and ASIL D compliance serve a crucial purpose in achieving high levels of safety. They enable safe and rapid initialisation, monitor critical failures such as voltage and temperature issues on ECUs, oversee failures in high-performance compute SoCs, and provide diversity and fallback by running critical algorithms, for example for vehicle control.
How do mixed-criticality workloads affect safety architectures in centralised compute systems?
Mixed-criticality workloads challenge safety architectures by requiring more advanced “freedom from interference” methodologies. This may involve, for example, running operating systems of different criticality levels on separate compute cores with sufficient isolation. This increases the need for additional hardware and software capabilities, adding cost, space and development time. Here, microcontrollers can provide a solution by enabling the separation of different criticality levels within a single ECU.
How do open architectures such as RISC-V influence long-term safety and certification strategies?
RISC-V represents an important step towards standardisation. As AI becomes more prevalent in the automotive domain, reliance on proprietary IP can pose risks, ranging from black-box designs to supply chain vulnerabilities, especially as the same IP is used across multiple industries such as consumer electronics, data centres and automotive. RISC-V, as an open standard, supports a more robust ecosystem, strengthens the developer community, fosters innovation and improves resilience to changing market dynamics. To support standardisation and enable a unified approach to safety, certification and toolchains, Infineon, together with major semiconductor and automotive players, has established Quintauris – an organisation dedicated to RISC-V standardisation across industries.
Which silicon decisions being made today will shape vehicle platforms for the next decade?
Compute performance, power consumption and memory are the key factors that will shape future vehicle platforms. Achieving the right balance between them is both critical and challenging. Higher compute performance typically leads to increased power consumption, which in turn requires more complex cooling solutions. At the same time, memory bandwidth remains a bottleneck when attempting to fully utilise the performance of high-compute AI accelerators. Innovations in these areas will drive future adoption.
Advertisement
In open ecosystems (chiplets, RISC-V), who carries the integration and certification risk – OEMs, Tier 1s, or semiconductor partners?
Integration and certification will remain shared responsibilities. The automotive value chain has already evolved beyond the traditional hierarchical Tier 2 to Tier 1 to OEM model and is moving towards collaborative and strategic partnerships. While this shift is disruptive and the exact handling of these risks will continue to evolve, responsibility will remain shared in order to ensure successful collaboration.
Which hardware constraints most often define what SDV software can realistically deliver today?
Compute capability, memory and network bandwidth, as well as the additional requirements for redundancy to achieve safety, are key constraints that can limit what SDV software can realistically deliver today.
How early must thermal, safety and system constraints be integrated into architecture planning?
These constraints must be considered from the very beginning of the design process. Too often, high-level software and algorithms are developed without fully accounting for thermal, safety and system limitations, which later hinder their implementation in a vehicle.
Partnerships are becoming essential across the automotive computing stack. Which type of partnerships will matter most in the next three years – strategic, technological, or regulatory – and what should OEMs prioritise first?
It is difficult to prioritise one type over the others. The automotive ecosystem is highly complex, and each form of partnership addresses critical aspects of innovation and technology development. A combination of strategic, technological and regulatory partnerships will be required to drive a holistic approach to innovation and successful deployment.