Profile: SME Interview on Transforming Vehicle Architectures

There's a lot of trends that are happening right now. Those trends are around electric vehicles, hybrid electric vehicles, as well as plug in. It's really about electrification. Some of the dynamics, things like urbanization, pressures for sustainability, becoming green, all those pressures have encouraged governments around the globe to drive various legislation, new regulations, things of that nature. All of that is benefiting the OEMs to drive electrification. And then there's various tax incentives that have really motivated those consumers to adopt electrification. The change is happening very quickly.

Vehicle architectures are moving towards something called a zonal approach. That zonal approach has standardized electrical and electronics-based platforms. This standardization and modularization of those electronic systems is paramount to the success of EVs. It promises a lot of different benefits. It promises, cost and weight reductions, ease of interchangeability of subsystems and components, as well as driving more advanced features in those vehicles. This quick pace of innovation for high voltage propulsion systems is driving different architectures in the vehicle. It's driving a complete radical rethinking and redesigning of low voltage electrical and electronic systems and those architectures, and the various platforms that are associated with it. There are some vehicle programs that have already shifted from the legacy distributed architecture to a domain centralized architecture, and those domain architectures are now going to have to go through yet another change to the zonal architecture, which is optimized for the future EVs. That includes complex high voltage systems that power the vehicle and allow for those automated driving functionalities.

The old systems were legacy distributed architectures. They migrated to more of this domain centralized architecture. Now in the future, they'll be moving to a zonal architecture. There are a few percent of the vehicles that are already leveraging zonal architectures, and that's some of the leaders within the industry. But it's estimated within less than 10 years, approximately 40% of the OEMs are going to be on the zonal architecture. The trend is pushing competitors to keep up and quickly adopt those changes. Today, the OEMs of the electrified vehicles utilize software not only to improve safety and comfort and features like infotainment, but also that helps to enable increased electrification and those ADAS features. In the future, vehicle functionalities and all the related software is going to be developed independently from the hardware on which it operates, and it'll be updated all throughout the entire vehicle life cycle. Thus, leading to something that is called the Software Defined Vehicle, or SDV as it's sometimes called. We are participating in this drive towards ADAS and improved functionality. One recent platform launch that we had was a high-resolution wheel speed sensor. That wheel speed sensor has over four times the resolution of legacy wheel speed sensors. This higher level of resolution gives finer control of wheel movement and allows automation of various functionalities, such as automated parking and even traffic jam maneuvering assistance. It's driving vehicle functionality to a completely new level.

The domain architectures enable systems to be logically organized and it's pretty suitable for cloud connectivity. For example, infotainment, ADAS, telematics, gateway systems, they're all grouped, and each has its own electronic control unit. However, that architecture increases the amount of wiring and connections in the vehicle. What that does is it increases the vehicle weight, the cost. And although OEMs can easily introduce new functionality with that type of architecture by adding new sensors, new electronics, and even an ECU to control all of that, that plethora of increasingly interconnected ECUs within the overall system, it's kind of costly. And it also brings about this threat of cyber-attacks due to multiple potential digital access points from external. So as a result, these domain centralized architectures that are currently pretty dominant ultimately are not the most efficient way to organize a vehicle electrical system. Therefore, a revision of the system's core architecture and the electrical distribution system, it’s a must, and it's leading to the mass adoption of this zonal architecture. And with the zonal architecture, systems are then logically and physically grouped into these efficiently organized zones. And in each zone, all systems are managed by the same processor. They have their own power distribution unit. They're all connected to the Ethernet via a gateway, and then ultimately to the central vehicle computer. Then just a few ECUs can manage the entire vehicle, while at the same time delivering all this new advanced complex functionality that the vehicles have within them.

In a zonal architectural based system, because the ECU is closer to the actuators and the sensors, less wiring and fewer connections are even required. The end result is it's a leaner, much more efficient, and scalable design. It enables efficient connectivity, reduce weight, significantly reduce costs in the vehicle systems, and much more robust cybersecurity and improved reliability. The zonal architecture promotes this well-structured, clean, safe environment that you can drive software and the software defined vehicle. You'll see things like over the air updates, like you would even see with your cell phone, subscription services, all these kinds of things. The move towards zonal architecture, it's going to make the vehicle almost like a supercomputing smartphone on wheels, allowing drivers to optimize their experience with just downloading apps. You may ask, what's that mean for sensors? In some of the vehicles today, there are sensors that have even yet today analog outputs, and they're fed into analog to digital converters that are located on the electronic boards of the customer's local control unit. In the future, I expect to see predominantly sensors with digital outputs communicating on this inherently bus based system leveraging the zonal architecture.

The shift towards zonal is really going to drive and allow the software defined vehicle. Without it, it couldn't become a reality. You're going to see OEMs in the future have basically a predominantly software development exercise. Historically, the OEMs and the tier ones have designed optimized hardware centric based systems. Then they would decide what software is required to enable the systems. With the zonal architecture, the exact opposite is going to occur. The OEMs are first going to design and evolve the software to control the zones, and then they'll consider how the hardware needs to change and adapt to support the software. The hardware now is going to follow the software, and this is going to enable a transfer of software development sovereignty from the tier ones to the OEMs. And that strict separation of hardware from software through a middle layer now enables independent software and hardware development processes and life cycles. I would say the analogy here is probably more like early PCs that were very custom and later then adopted standard motherboards. You're going to see a lot of analogies between vehicles today with where computers went through their journey in the past. And to make all that happen, what is key here is standardization and modularization. It's crucial.

The OEMs are going to control most of the software development, and they'll drive towards standardization of hardware and electronic modules. This is then going to provide greater value to the auto manufacturers, enabling them to drive maximum reuse across their various platform models. With the zonal architecture, there's also going to be this migration to a 48-volt system to support the system's higher power consumption requirements and the redundancy. And those 48-volt systems, they have less power loss. The key thing here is that then enables much lighter wire harnesses. In today's systems, you'll have a vehicle that has large cabling and a lot of different cabling all throughout the car. With the zonal architecture, you're going to see much fewer cable assemblies, and they'll be much lighter and easier to route throughout the vehicle. The overall benefit to the OEMs from migrating from the old architectures to this new zonal architecture is going to be significantly reduced development costs, significant reduction in the CapEx required for their factories to produce, significantly increased manufacturing efficiency, faster development cycle times, reduced inventory, all kinds of great benefits are going to come out of this. It's going to be tremendous for the OEMs. And with the smaller and shorter electrical wiring and sensors with the digital outputs, it's going to make it even easier for OEMs to add and subtract sensors to pretty much tailor the functionality targeted for each vehicle.

In fact, the economical drive they're going to have for trying to even combine multiple sensors into one package, like something that you would refer to as “combi-sensing,” that's typically done to minimize the cost of packaging or the associated complex cabling assemblies. That may reduce and go away because it's going to be easier to add and subtract individual sensors in the future. And additionally, there's this ever-increasing need for a mature understanding of functional safety requirements. Every organization around the globe pretty much has to have a trained and certified functional safety manager, or several actually, and also engineers and IC designers. They all need to be well versed in the topic of functional safety. Functional safety, I'm not sure if you're familiar with it. It's referring to a safety integrity level: SIL. And an SIL applies to a safety function from start to finish, and it pretty much affirms that the system is reverting back to a safe state or performs properly, even during incorrect operation or a loss of functionality. It's in fault tolerant architecture. Both the design and the process for product development must follow functional safety standards, and these are commissioned by the International Electrotechnical Commission (IEC) and governed by things like IEC 61508 and ISO 26262. And everyone needs to pass these independent functional safety audits in order to achieve the corresponding quantitative metrics that assess properly that you're meeting all those safety standards.

There is an ASIL decomposition. It's a technique that's used in the development of automotive systems that manages and mitigates risk, and that's associated with different functions or different components. The process involves breaking down a system with a higher ASIL requirement into much smaller parts and functions, each of which have to be assigned a lower ASIL rating in order to meet the higher-level ASIL within the vehicle. And that approach allows for more manageable and cost-effective implementation of these safety measures. ASIL is divided into four different levels. There's an A, a B, a C, and a D. ASIL D is representing the absolute highest degree of hazard control rigor, and ASIL A is the lowest. This classification helps in assessing the severity, the exposure, and controllability of potential hazards. And it guides the development process to focus on those critical safety measures. ASIL A is applied to systems where the risk is relatively low, but it still requires mitigation to ensure safety. ASIL B is for systems where there is moderate risk but requiring more stringent controls than ASIL A. ASIL C targets systems with much more considerable risk, and it demands more rigorous safety measures. And finally, ASIL D, being the highest, is reserved for the most critical systems where the risk of harm is highest and therefore necessitating the strictest of safety requirements. All these changes are really challenging engineers to better understand the details of the end application. What's required of the sensor in the system, the role, the value of those sensors and provides not only in terms of functionality and performance, but also in terms of safety, quality, reliability, weight, sustainability, and cost. There's a lot of factors that engineers have to consider when they're doing product development. As these OEMs push towards the software defined vehicle world and primarily focus on their software, their understanding and maturity level for these mechanical systems and sensors may decrease. In the past, they were doing very hardware centric developments and were really good at that. I think in the future when we go to software defined vehicles, more of that is going to be shifted to the tier ones and the system players as well as the sensor providers.

You spoke about reliability. I have personally institutionalized the design for reliability engineering methodology within my R&D organization, and this is globally. Design for reliability, or DIR as it’s sometimes referred to, ensures that the product performs the intended function under the specified and required conditions or loads for a defined duration and in a particular environment during which various failures can occur. This methodology really integrates reliability considerations into the product design process, and it helps minimize failures and enhance the overall product performance and the safety of the product. There's something called a mission profile. A mission profile is a detailed description of the operational conditions, as well as the requirements that the product is expected to encounter throughout its entire lifetime. Included in that mission profile are the functional loads, things like thermal and mechanical and electrical, and all of the environmental stresses, which all depend on the specific usage conditions of the final end application. Then commonly, those inputs for the mission profile are then driven into the product requirements document. We're utilizing this input from the customer to define how our product has to perform, and we're designing it and validating it accordingly. We need to understand the usage profile, the customer supplied data in the form of various simulations, or test data, or field data. We use industry standards and all those inputs then, as well as inputs from known failure modes from the past experience we have in various products. We have our product FMEAs and our design FMEAs for similar platforms and products, and all that goes into our product requirements definition for doing product development. That then ensures the sensor developer is developing a reliable product that will meet the requirements of the end application, and it will also help us to ensure that the product is neither over designed or over engineered and adding unnecessary cost. It's optimized engineering. It's just right.

We also do functional safety assessments. I spoke about the functional safety managers and how all our engineers are getting functional safety training. Our functional safety managers and our R&D engineers, they have deep discussions with the functional safety experts from the OEMs and the tier ones to ensure a full understanding and alignment regarding all the ASIL requirements of the sensors, as well as whatever decomposition methods are being applied at the system level. A proper understanding of the vehicle, the system architecture, and the flow down through the subsystems and individual components and to our sensors - it's a must. And it's a very complex topic that must be handled by properly trained and certified subject-matter experts.

I did mention that the next generation vehicle is definitely going to be much less hardware centric than the legacy internal combustion engine-based platforms of the past. Vehicles will be software-defined platforms. I spoke of the software-defined vehicle, and it'll have extreme levels of standardization and modularization of hardware. The next generation of vehicles is really going to be differentiated around the experience of drivers and the passengers. Sensors will play a key role in that evolution, providing features and functionalities on a vehicle platform that can be tailored to the specific needs of the driver and the passengers. And the experience of the driving will be much different than in the past with automated driving assisted functionality and so forth.

The SAE, or Society of Automotive Engineers, has defined six different levels of driving automation. Level 0 is fully manual. That's no automation. The driver would perform all the tasks like steering acceleration, lane changing, braking, and so on. Those are kind of the old legacy vehicles. Level 1 is driver assistance. And in Level 1, the vehicle has maybe a single automated system, things like the vehicle monitor speed through cruise control, or something like that. A Level 3, which is partial automation, also known as ADAS or Advanced Driver Assistance Systems, the vehicle's performing steering, acceleration, lane changing, braking. But the driver is monitoring and can still take control at any given time. Level 4 is referred to as conditional automation, and this is where the vehicle is performing all the driving, all the maneuvering functionality, but the driver still has override in certain conditions. Level 5 is high automation, and in Level 5 the vehicle is performing all driving, maneuvering, and geofencing is required. The driver still has an override in Level 5, but Level 6 gets to absolute full autonomy and the vehicle is performing all the driving, maneuvering functionality under all conditions. No driver interaction is required whatsoever. And I think the idea of even being a driver in Level 6 will go away because the car is the driver. Most vehicles today are operating between a Level 2 and a Level 3. And although the OEMs were extremely optimistic a few years ago, and even forecasting a fast acceleration to Level 4, most have lowered their expectations because the emphasis is really on driver and passenger safety.

There's so many key factors. Let's start with the product robustness. We spoke of that. Design for reliability and robustness validation, that’s pretty much the foundation of delivering a high reliability product and the end application and a world class experience for our customers. And those customers inclusive of the vehicle owners, OEMs, tier ones. We talked about reliability, designing for that and then validating that. Performance and functionality is obviously something that a sensor has to meet. Within TE, we're employing a Design for Six Sigma or DFSS methodology, and that helps to ensure our products are fully capable and meeting the specifications and the requirements over all the conditions of the application. Functional safety. That's another. We spoke of that earlier. Is the sensor meeting the appropriate functional safety requirements for the application? A full functional safety assessment has to be led by a certified functional safety manager, and the engineers have to be trained on functional safety. That's crucial. With standardization, the modularization we spoke of, interchangeability and standardization for software defined vehicle is going to be absolutely key. With the migration towards software defined vehicles, there's huge needs for standardization. It's very important to give special consideration to interchangeability. The OEMs and the tier ones will be looking to have sensors that can be easily and seamlessly changed, either in the application or even between various suppliers.

Becoming green, sustainability. That's another huge topic. The most glaring challenge right now to the automotive industry is definitely carbon footprint.  These traditional materials and manufacturing processes are mostly reliant on fossil fuels. All those contribute significantly to greenhouse gas emissions, and many of those are being banned. We have to come up with alternate materials, and some of those materials may not be as proven, or they may not even be as robust as some of those used in the past. But with the legislation banning utilization of some of those, it's becoming a challenge. So sometimes I think going forward, one of the bigger challenges for sensor engineers is going to be maintaining the product robustness with materials that are considered “green.” Another thing would be supply chain continuity. How reliable and robust is the overall supply chain for components, for materials, and even for the equipment? Is there a special single source or are there multiple options that are available in case of obsolescence concerns? Any geopolitical concern that would prevent easy shipment of goods throughout the supply chain, having a global footprint is key. And that's something that we have. For example, we have resolvers for electric vehicles for e-motor position, and we have a global footprint. We have resolver manufacturing in every region that can supply our customer base. And then of course we have to have technical and quality support. In automotive, driving zero defects is a top priority. Doing things like rapid root cause analysis, problem solving for driving continuous improvement, and driving zero defects, that's really a key for us.

We engage well in advance to product development life cycles to understand the existing pain points and the future needs of our customers. We ask them what's working, what's not working? And with our sensor expertise, we're also helping to identify things that maybe they were not aware of. So unarticulated needs. And often we're engaging in advanced developments with our key customers to develop the next generation technologies that are really going to be the heart of our sensing platforms for years to come. If the first time you're exposed to a new application is via a Request for Information or an RFI, or a Request for Quote or a, which is RFQ, you're about three years too late. We're engaging far up in advance with our customers. And I spoke of our systems application engineering team. We have senior technologists and subject matter experts within the R&D organization. They're all working very closely with the advanced development engineering teams of those OEMs and the tier ones. And in that regard, we've become their trusted development partner of choice.

If there’s one thing I've learned in my career, it is that the only thing constant is change. You have to learn to adapt extremely quickly. Do not get comfortable. Stay vigilant. At TE, we're constantly assessing the market, the technologies that we can choose and develop, our supply base options, the competitive offerings we're competing against. But most importantly, we continuously assess the needs of our customers to understand their problems. Their needs are constantly changing and evolving recently. And at TE, we take pride in helping our customers compete. By understanding what keeps them up at night, losing sleep, we develop solutions that truly add value. We're the sensor experts, and our customers have come to appreciate being able to partner with us to solve their absolute, most difficult sensing needs.

We have a website right, TE.com, and you can look up the transportation sensors on that website. If anyone wants to reach out to me personally, they can hit me up on LinkedIn. I'd be glad to make connections or answer any questions that someone might have. Use your resources.