How do standards improve vehicle design?

0:00 Introduction to Auto Tech 2026

Today in The Garage, we’re recording live at Auto Tech 2026 in Novi, Michigan. All around the show, you’re seeing software and technology being used in exciting ways. And as technology becomes more complicated, it’s always a trade off, and we’ve talked about this many times in the podcast, between what aspects of technology are common and what aspects of technology are differentiating and different across different customers and OEMs. And that’s a difficult tradeoff that affects not only automotive and vehicles, but many industries where companies are always looking for things they can protect, innovations they can own and have differentiation.

But at the same time, if they do everything themselves, the cost can be high and there’s unnecessary duplication of efforts. One way to crack that is standards. And there are a number of different standards bodies across different industries and different sectors of the world. But in vehicles in automotive, one of the most important standards bodies is SAE.

And so we brought a senior leader from SAE to talk with us about what’s the process of creating standards, what are some important standards that exist now, and some exciting ones they’re working on. My guest today is Tim Yerdon. Tim is executive leader at SAE, and he’ll talk about this whole process. And I learned a ton in this conversation.

I hope you’ll enjoy. Let’s go!

1:35 Introducing Tim Yerdon

Welcome to The Garage. I’m John Heinlein, Chief Marketing Officer from Sonatus.

We’re here at Auto Tech 2026 in Novi, Michigan, and pleased to have Tim and the podcast with us today. Tim, welcome to The Garage. Thank you for having me. It’s a pleasure.

Yeah. Tim, we’ve managed to each other so many times. We’ve been on two panels already this year together, you and I. So I was thrilled to be able to get you to join us here at AutoTech.

It’s great. And thank you again for for having me. And it’s hard to believe we’re halfway through the year and the amount of work that we’ve already done and the amount of work that still has to be done through December. So let’s start by getting to know you a little bit.

Tell us about you and your background. So, you know, I’m unique in the industry as one of our my HR colleagues used to say, we’re all unique in the fact that I’ve lived kind of a bifurcated life. So half of my career has been very technical on the R&D chief engineer side, and the other half has been on the marketing side. And now I find myself, after a career in the supply side, about twenty years on the supplier OEM side, two stints at OEMs.

I started my career at Ford Motor Company in on the electrical side. Was at Visteon for about twenty years. Ended up going back to Ford Motor Company in a chief engineering role. And now I’m at a not for profit.

So it’s some some different turns and twists, but it’s been a great journey. Exciting. And we have to start. We always like to ask our guests a fun fact about you.

Tell us about you. I spent some time in racing, but not racing from a driving standpoint, racing from a technology transfer perspective. So while I was at Visteon, we were actually building a lot of the electronics for different racing venues for Ford Motor Company, Jackie Stewart, Formula One, off road truck, at the time, IMSA Racing, which is road car racing. But my job was to take things that either existed in the portfolio and push them into racing to test and validate or things that were invented in racing that could have a commercial life after.

So it was that technology transfer role that led me trackside that led to durability, the the mindset of going fast, driving speed, you know, making quick decisions on your feet, all the things that really help you throughout a thirty year career. That’s a great fun fact. I don’t think I can I can touch that, but I will say, resonating with your earlier point, you know, I had a PhD in engineering and I started my career in engineering before moving to marketing. And they were both exciting parts of my life.

I love what I do now, but I began my career in engineering as well. Yep. Well, and I think, you know, what led me to this was, you know, somebody that can articulate the technical things into language that people can understand. Exactly right.

And, you know, that led to, hey, can you talk to the board? Oh, wait, can you talk to our investors on Wall Street? And I kept ended up more and more with these speaking engagements that led to just a different, you know, way to use my skills. It’s precisely my story exactly.

I tell it exactly like that. And that’s how I talk with execs and investors and journalists and board members and analysts.

4:32 Understanding SAE’s Structure and Role

So tell us about SAE, the company you’re with, and your role there. Sure.

So one, I’ve been an SAE member for thirty three years, so I’m proud to state that. Now, I’ve been with the organization just two. And when I came to the organization, I knew SAE International. That’s what I’ve been a member of.

That’s what most people are familiar with, the standards, the events that they do. But what people don’t understand is there’s many other affiliates within the brand. And one of the things, if you think of it from a business flow perspective, there’s SAE ITC, Industry Technology Consortia, which convenes industry, solves technical problems on the billion dollar scale. And that’s what I run the land systems and anything that touches the ground, that’s what I focus on.

I like that… land systems. I like that. Yeah. And that helps feed the International piece, which really is the factory, the big part of the organization that helps deliver the standards, the events.

And then behind that, on the back end is what I call the reoccurring revenue model, which is PRI, Performance Review Institute, which does auditing and compliance. So think of things like, did you use the right fasteners in your manufacturing process or the right materials? So if you think of it, the ITC piece is the front end funnel. Right.

You have the factory in the middle and you have the reccurring revenue on the back end. That’s a really easy way to understand it. Thank you for sharing that. And I think many many of our listeners and including me, think, used to think of SAE as the Society of Automotive Engineers.

But it’s much more than that, and I think there’s also aeronautics and other standards as well. So tell us about the name change and and the broader scope. Yeah.

6:06 The Evolution of SAE’s Name and Scope

For for many years, it’s really been SAE, kind of like what, you know, we used to call Kentucky Fried Chicken, Kentucky Fried Chicken, and now you just say, oh, we’re going to KFC.

It’s kind of the similar vein, similar information, or similar change. But the key for us is going back even to the founding and one of my colleagues actually recently found a letter to Wilbur Wright asking to be involved in this organization to help set standards for the industry. And why Wilbur Wright? Well, today, half of our revenue and half of our standards come from aerospace.

Things in consolidating cockpit electronics across the airline manufacturers, things of that nature are standards that the SAE organization holds today that many people don’t know. That’s an incredible story and that Wilbur Wright story, I’m going to tell that, that’s very good. I like that a lot. The other thing that’s unique too is the foundation.

7:00 The SAE Foundation and Education Initiatives

So the SAE Foundation, which is really the charitable arm, if you’ve heard of things in universities like Formula SAE, Formula Baja, that’s another element to the organization as well that is very mission based on bringing that education in those STEM engineers all the way from early days of kindergarten and grade school in various programs that we have there all the way up through those college programs. That’s right. And then keeping them engaged in industry. And tell us a little bit more about your role at the organization.

So my role is under the SAE ITC piece. So I have a colleague that is his head is in the clouds because he does everything aerospace. I try to stay grounded. So everything that touches the ground, passenger vehicles, heavy truck, agriculture, off road use vehicles.

So when you look at common threads between those, like software, software doesn’t care. You know, it’s the common thread between many of these forms of mobility. And I focus in that domain on what we call the ACEs, Automated Connected Electrified Programs and Systems. So we have a variety of consortia, which is really like a table like this.

How do we get multiple OEMs or suppliers or other ecosystem partners around the table to help solve billion dollar industry problems? Well, you mentioned earlier that there’s a myriad standards from motor oil to fasteners to, you know, metal, everything and everywhere in between. But as we’re moving to a software-defined era, especially for vehicles, how is standard setting for SAE changing in the software-defined era? Yes.

8:40 Standard Setting in the Software Era

I mean, we’re we’re really at the early days and we think of organizations out there that are driving open-source software and we think of kind of the history and the rigor of SAE standards or ISO standards or other standards development organizations that are out there, otherwise known as SDOs. But it’s taking that rigor and discipline in the history, but also understanding how to be flexible and fast in the open source world. And I’m not saying open source software is the panacea of solving everybody’s problem. I think it’s like a teeter totter.

There’s a balance somewhere in between those two spectrums that we have to you know, the the the older disciplined ones need to learn how to be fast and flexible, but the ones that want to be fast and flexible have to learn a little bit of the discipline as well. So it’s it’s having the right balance so we can all move forward together.

9:28 OEMs and Standardization Challenges

We we talk a lot on the podcast and and here at the show. There’s been many conversations I know you’ve been involved in about about what should OEMs use in common versus where should they have differentiation.

And that’s a bit of a struggle, a bit of a arm wrestle continuously. What’s your view of of how of how high or what sections of the stack warrant being standardized from your perspective? Yeah. It’s, you know, it’s it’s probably the most common question that that we get in the most debated discussion that we have.

And obviously, the things that are differentiating on consumer side as you get closer to that consumer, the HMI, the experience, those are the things that make our customers, the OEMs, the people delivering the product are going to control. It’s further down in that stack. What can we do at the firmware layer or at the board, the BSP layer, board support package layer that people tend not to care about that we’re reengineering power methodologies over and over again or things that we shouldn’t have to do, that we should have a baseline or a reference design. And it may not be a standard.

It may be a framework. It may be a best practice. But how do we do things that, at the end of the day, my kind of soapbox moment is always saying, we shouldn’t be working on anything in our organization that isn’t helping our customers be more efficient. And efficiency to them is really cost through engineering.

How do we help reduce engineering hours that drives cost, which ultimately drives efficiency? So they can then focus on the features and the end functions that the consumers want versus something way down in the stack that may or may not matter. That’s excellent.

11:08 The Process of Building Consortia

Now fundamental to to your job and to the role of a standards making organization is getting competitors to sit down across the table and agree.

How is that process like? And what’s the what’s the magic secret sauce that that you use? So there’s, you know, there’s three I call it the three phases of consortia building and, know, it’s akin to, you know, as they call it, herding cats. But so for instance, if we have a you know, there might be a tabletop discussion at an event, which often happens, maybe over a beverage, and somebody says, man, we got this problem.

And then you find out another customer has the same problem and then a third and a fourth. And if you can get at least three of them around the table to help articulate what that problem is, then we can start to bring people together and convene them in neutral, safe spot where we can get the legal framework in place so they can share their information, ultimately and potentially even sharing some of their intellectual property that they put into the consortia, so then we can start to have these discussions. And by that, we have to go through the other phases, which are okay. Let’s I hate to say this, but there’s always somebody who wants to be the smartest one in the room.

Well, when you bring three or four smart people together, they’re all smart. We have to dispel that mythology that there’s just one person that has the best idea. The second is that their solution that they might have already started on is going to be the ultimate solution. It’s not going to be any one company’s intellectual property that’s the end all, be all solution.

It’s usually bits and pieces and the combination of the consortium. So after we dispel those two pieces, it’s then understanding the problem statement. And if we can all agree on what the problem is that we’re trying to solve, these things tend to take off. And then we can maybe go from three or four initial charter members to maybe ten.

Whatever it takes to go solve the problem depending on the scale and the scope. That’s a really articulate way of explaining it. I really like your your framework and your taxonomy. I know I’ve been involved in a lot of agreements where intellectual property rights or IPR, as they say, are involved, not not on a standards level, but in sort of a company to company collaboration.

I’ve always found that we could take an hour on this, so let’s not. But I’ve always found that that IPR area can sometimes be the thorniest because sometimes companies feel as if, well, I may have a patent on this or I have some trade secrets on that. And, yeah, you do. But if we work together, it’s actually going to be more valuable than that thing you have, which by itself is never going to be useful.

Exactly. And it’s getting people comfortable with that. And because of SAE being neutral, it gives us that ability because we have the history of the framework and the legal documents and the way we run these programs. It gives people comfort that they’re in a safe spot and we can actually share information and solve the technical problems because you know, it’s not about, you know, just solving the problem.

14:03 Standards as a means for industry self-regulation

It’s about what are we doing to deliver technology to the market quicker for industry and making vehicles more affordable or mobility in general more affordable for all of us as consumers. So you mentioned ACES or sometimes people say CASE. Yes. It’s the same thing in different order.

What are some of the standards you’re working on in that sector? And maybe we should sell spell out what ACES stands for. For us, ACES is automated, connected, and electrified programs. And we usually focus on the consortia side.

So we’ve got some key ones. So if we take the automated side, one of our premier ones is the Automated Vehicle Safety Consortium. And if you go to www.sae-itc.com with a dash in between SAE and ITC, all those programs are listed there.

But you can see the corporate members that are involved in each of those. You see when I go back to that herding cats, it didn’t start with eight or ten members of these orgs, it starts with three or four and then you kind of continue to build as word gets out on how these come together because they’re creating, in the Automated Vehicle Safety Consortium, the best practices that create the framework that could potentially lead to the standards that help kind of self regulate that industry. So, you know, how are we creating the frameworks before there may be a potential issue that maybe somebody from Washington is telling you what that framework needs to be?

So we’re we’re getting ahead of the game on that one. It’s it’s so good for you to say that because and I’ve said this to many people in in the past that if you don’t self regulate, the government will be happy to do it for you. And it’s much better if you can self regulate and say, hey, we’ve really thought through these safety things or we thought through these security things or whatever and we think this is the best practice. We recommend this.

And they say, okay, okay, we see that you’ve done good work. Otherwise, they’re gonna come in and and want to do it. And another really interesting one that we just started in January is around digital road rules, and it’s called the DRRC, Digital Road Rules Consortia. And in in North America and the US, each state has their book of road rules just like you would go to take your driver’s test.

You have to be take your driver’s test for California or for Michigan. Well, technically, automated vehicles have to follow these rules. In most cases, those are in a binder with fourteen hundred pages sitting on somebody’s desk at their state capital. How do we get those that information into machine readable format that can go into the software in these vehicles?

And that’s just one mechanism of it. But more important is, how do you understand what the differentiation is in these rules? Because state to state, they’re all different. Now, when the operational design domain was just in a city or a region or an area, it wasn’t a big deal.

But as these things expand and deploy across regions, across states, we have to think bigger. We have to think, how are we going to light up highway corridors across the country for automation. And these things are going to be needed. It’s true.

Today, most of the autonomous vehicles, sort of robotaxi and sort of the like is mostly within a specific region. But there’s incredible conversations and we’ve had several guests on the podcast in the past weeks and months talking about highway long haul trucking and so on like that. So crossing state lines is I would say only a matter of time and it’s not much time from now. And you know, not to talk too much detail on this, but this is a multi-million dollar problem for each OEM to have to go solve by themselves.

Sure. And at the end of the day, they could go do it, but they’re going to come up with ten different ways that they’ve done it. Yeah. But if we bring those ten people together and they all contribute a little bit of money, we we reduce their expense.

At the end of the day, we have an industry standard. The government is happy because we we have a group that’s doing this and doing it together. So it’s really a benefit for everyone. I mean, we’re we’re here based in the United States and but, of course, my company and and the industry is is worldwide.

When you look across the US versus Europe versus China, you see different levels of centers centralization and standardization. Obviously, China quite highly centralized. Europe has with its member states, you know, largely compatible, pretty much symmetric approaches. The US is not quite there.

The states are quite different, quite heterogeneous, very heterogeneous if you know much about the US, and even cities and municipalities, although that’s not so much for roads, but more for other standards. It’s a big challenge that the US system faces, unfortunately. Yeah. It’s it’s funny.

So just a quick story on that is when I started in this project, I’m like, oh, we’re just gonna call one person at each state DOT and get an answer. Oh, wait a minute. State of California, have to talk to the DOT, the DMV, the highway patrol because they have a voice in this. So often you say you’re talking to one state, but you’re really talking to three to five people per state.

And that’s just at the state level. If you’re looking at major cities, that’s another click in to go into detail. And so it’s a very complex problem, but the industry is trusting us as SAE to put this database together that controls all this information because it’s centralized and it’s kind of, you know, territory, so to speak. That’s a fantastic example.

And I’m sure there are myriad other standards which we probably don’t have time for, but I will redirect people to your website and we’ll put a link to the URL in the show notes. Now, I know people are probably very familiar, many people are familiar with the the SAE self driving levels or level one through five, and we’ve talked about that many times even just this week on the podcast. But maybe you could start by introducing that framework. But then I know you’re also working on a new effort to look at software defined vehicles and standardizing the language around that in a similar way.

Can you compare and contrast those and tell us about that new initiative? Yeah, sure.

19:37 Self-Driving Levels and Developing SDV Levels

So obviously, I think J3016 is the number for that. And it’s been around quite some time and colleagues and others in industry groups have come together to agree on that.

That has provided a framework and really, less so the standard side of it, but the framework for discussion. The language and the nomemclature. And look at how many people reference and point to it, not just the technical aspect, but the media, the government. It provides an avenue to have the right conversations or at least steer people categorically into what they may be in others.

You know, they’ve added pluses and plus pluses and minus minus and this and that, which it’s beyond what the original intention was. But those are the things that at least get us in the ballpark of having a conversation versus just having things kind of completely open ended, which is where we are today with the SDV levels. Every time I attend a conference, I’m in the audience and I’m taking pictures of somebody else’s SDV level slide. I think I’m up to eight different versions of it now.

And over the last year or eighteen months that I’ve been collecting these, you just start to realize, okay, we must have a framework for discussion around SDV levels. So we’re actively working in some various small groups on that to start to get that voice of customer and understand how do we pull that together. And this is a little bit different than the automation levels and the fact that the automation levels were, I don’t want to say pretty straightforward, but it’s a less complex. It’s clear that one of the things the automation levels give you is clarity around who’s in charge, what capabilities, what’s the operating domain, what’s the ODD that is relevant.

So I think there’s very sensible, clear things there. In SDV, and I’ve seen a number of these levels as well. They’re kind of looking at it from different angles. One angle looks at it from more of an app store angle.

One of it looks at it like how much is the software upgradable. One of it looks at you know…there’s different ways to to look at this. It starts from far end of zero all the way to very basic connectivity features all the way up to potentially AI-enabled SDVs.

And what does that all mean? As we all know, if you ask ten different people to define SDV, you’re going get ten different answers. And we just need to narrow that down so we can have meaningful conversations across the industry. And I see that as one step in a very long journey of how do we rationalize the whole world of SDV back to asking where do we work?

What do we standardize? What do we not standardize? We have to work our way through that as an industry because each OEM, each tier, each service provider always has a different view and their views are based on where is their value. So it’s hard to put something on paper from a level standpoint when everybody’s coming at it from a different perspective on where they extract value for their business.

And when we we think about the ability to add software in vehicles and the one of the things we talked about is the fundamental aspect of SDV is the decoupling of hardware and software. So as you’re decoupling hardware and software, there’s a desire, there’s a long term desire to be able to bring flexible software in, to bring in third party software. So there’s lots of different interesting, potentially valuable but complicated aspects. And I think some of those are the things you’re trying to crack into in this conversation.

Absolutely. It’s thinking of that whole spectrum. And I’m laughing because I’m thinking back, boy, about five or six years ago, I was just working on how do we bring app stores into the infotainment piece of it. And you’re thinking, man, that was a lot of work and a lot of complexity.

So that was exponentially easier than where we are today. Right. When you think of the world of SDV ranging from you know, not so much from the levels, but from the life cycle development, which of course is, you know, a lot of your business, all the way from the up early strategy and planning of the architectures, all the way through to, you know, OTAs after, you know, ninety, one hundred and eighty multiple years of deployment on the road. I mean, you have quite a spectrum Yeah.

Of the life cycle that we’ve never had to deal with in this industry before. I don’t envy the challenge you’ve taken on because I think there are multiple angles of this and and I’ll be curious as you’re able to bring this together. And we talked earlier about IPR vis a vis other kind of standards. Here, I think many different companies have brought those frameworks because, for sensible reasons, they feel like there’s some differentiation.

For example, whether it’s OTA or things like that. So bringing a common framework, I salute you for trying. Well, and quite honestly, I think it’ll never be done. It’ll never be complete.

And that’s in this digital world, we have to come to that mindset that is it really a standard or is it more of a framework that always evolves and changes under a certain cadence when we have a certain number of people that say, yes, now it’s time to update or it’s time to change this. And we have to live in this new world. It’s different. It’s somewhat uncomfortable for for some, but, you know, we we have to face a new reality.

Well, if we if if we come back to the the self driving levels, think once I really internalize that framework, I think it’s very sensible. I like the framework and it’s helped me have a mental model, but it also, as you said earlier, helps the conversation, helps you be able to say, know, the difference between, you know, L2+ and L3, as the saying goes, is like sort of who’s in control, and then L4 and L5 is really the higher ends of it I think it’s very helpful. So I think in a similar way, think your work is going be helpful for SDV. And kind of coming back to the structure of SAE a little bit, and I talked about the ITC piece.

And these are things that we can do to get out there and get something out to the market quickly and have these discussions. And then as it flows through the organization, maybe it does or maybe it doesn’t become a standard down the road. But as it gets into the larger international piece with the subcommittees and you know, others can have a more of a voice in that if they decide to do so, you can have those deeper discussions that may take two or three years to nail down. But at least we have something out there in the market that we can start to have a discussion on That’s great.

And figure out some of those lower level details later. If we wait three to five years to get everything, all the t’s crossed and all the i’s dotted, the market’s gonna move by us.

26:01 Open Source in Automotive

You mentioned earlier open source and obviously open source is just an enabling technology. But what’s your personal take on open source in automotive?

Because it’s really seemed to, in the past few years, emerge as a really viable thing. I know I’ll tell you a funny story that, you know, years ago, I worked with Linus Torvalds. He and I were colleagues together at Transmeta, which is a conversation for another time over a beer. But at that time, Red Hat and a number of these other companies were were just emerging.

And the idea was to bring it into more sort of production use. And it was crazy because most people thought you’re gonna have open source in like, production things. Well, now IBM bought Red Hat and there’s all these incredible uses of open source in daily use that’s very, very successful. We’re seeing that in automotive as well.

But of course, automotive has a safety aspect, is a little different than other markets. How are you looking at open source? We’re on a journey. I’ll leave it at that right now.

But, you know, the thing that concerns me most is the AI aspect of this. And, we can say open source, but where is it really coming from? And that is going to be the challenge of the future is somebody’s going to go into their AI tool of choice and compile a bunch of information. And that might be fine for a proof of concept or, you know, for an initial, you know, starting point.

But somewhere that’s got to be traceable back to kind of the the source. And I think that’s going to be the real challenge. And I’m sure we could talk for an entire hour just about that topic. So let’s leave it at that.

But it is an interesting, exciting area. I think open source in general has a great opportunity. But yeah, the confluence of that and AI will bring additional complexity. Tim, this has been a wide ranging chat, and I’ve learned a ton of things in the past half an hour that I didn’t know.

So I’m so glad you could join us, and thank you for your hard work and all this standardization, which ultimately will benefit all of us. Well, thank you and really appreciate the invite and and good luck with everything. If you like what you’re seeing on this episode, please like and subscribe to see more like it both from AutoTech and other shows around the world. We look forward to seeing you in another episode very soon.