Digital Standards Offer integration, Speed, and Accuracy to Engineering

EE: There's a lot going on in aerospace, especially because of this new explosion in what I like to consider middle space. So what are your thoughts on the whole aspect of the SAE aerospace digital standard discussion in the context of the new reality of constant telemetry on a 24/7 basis.

Audra: There's a lot of changes that are happening, not just in the types of products and services that are being offered now in the aerospace world, but the processes by which those products and services are developed. And so I think in the... Historically, we've always worked in a world where it was very linear. Design, develop, test, release. And rightly so, that's still happening because you have to have some controls. Those release cycles are shortening.

With the demand for speed to market a new entrance coming in. There is this increased desire to make sure that they're putting stuff out into the market pretty quickly. However, still safely. Now, on both sides, whether you are somebody who's commissioning the work, or you are a supplier within that larger supply chain, you're still having to abide by regulations, which oftentimes call out standards.

Even aside from regulatory compliance, a lot of OEMs, they are still wanting to use standards. Standards are industry adopted. They are best practices. And those standards are things that industry wants to follow. And so if you are an OEM and you are asking your supply chain to follow a particular standard, they will have to do that. And they will have to abide by that in order to win that job. And on the same token, when they agree to be compliant with the standard, they have to show that they were compliant with the standard. And so the amount of documentation, the amount of overhead in that is always been enormous. It's just an enormous lift. So when you add to that the increase in speed now that's being driven top of that, it becomes unmanageable with the current infrastructure, with PDF documents, which is what typically standards have been in the past or print documents.

It's just not manageable. Like anything else, if you're pushing people to work faster and to do more with their time, there's always a potential for an increase in transcription errors or errors in general. And so, especially when information is moving from place to place fairly manually. It makes it even more... To make it even more complex, those documents get updated on an ongoing basis. So it's not like the information that is being required within the supply chain to follow the standards. The standards are changing over time. So they're having to be compliant with the most recent version. And that's true for most, any standards, not just SAE standards. So with respect to digital standards, it's so essential that standards and their formats keep up with the changes and how products are developed within the aerospace and the speed by which they are developing. And that's really digital standards does help provide that ability.

EE: So now how much of that is driven by a desire to ensure a common foundation for technology solutions and how much of that is driven by a desire for interoperability, lingua franca, and other aspects of a multimodal, cloud-enabled IOT world?

Audra: It's not so much the common solution. It's really because standards are fairly broad, I should say. And so they are not as prescriptive as some might think. That the word standard might imply, they are fairly broad. So there is a lot of flexibility in their application. So that avoids any kind of IP conflicts between companies who are working together to create a standard. They're broad enough to say, "We're all going to follow this general framework." Although this may seem fairly specific, in general, they're fairly broad. So they're not as prescriptive as you might think. And so they're able to implement them in the certain ways that are very unique to them so that they can have a common approach where they're not competing on things like safety. And they're trying to keep costs down in general for the aerospace supply chain.

However, there's still a lot of room for things that are unique so they can have their own IP. It's more so what you had mentioned in the second half of your statement, where it's interoperability. In order to... One of the things that's always been very clear across the aerospace industry is that they will not compete on safety. Safety is always of utmost importance to both aerospace and the automotive industries. And those are the two industries that we serve. That's never been an issue for them to ever discuss things that are going to enhance safety. One of the ways that we'll be able do that is, to be able to share the information in a way that multiple systems can go towards the single source of truth, that being the standard. And that standard, the place where that data is served up is maintained by the person where the data originates, which would be SA in the case of SAE standards.

And we're able to maintain it so that they can have the correct information all the time to... In the past, it was "Here's the PDF." And then they make copy pieces out of it, put it in another system. They may put it into a database that would be inter-operable, but when the standard changes, well, now they have to go do it again. So they're having these personnel and FTEs having to do just that and spending a lot of their time doing that. And then you always have the risk of human error. And so it did help that the standards were kind of this island that really was not very accessible at all, much less interoperable. So being able to offer the standards in a version that is interoperable, they don't have to worry about keeping up to date with everything, because when you're able to have them in digital version, the community that's using them, they can connect to those standards and not have to wonder about, "Okay, let's go, keep going and checking, whatever to see if anything has changed." They can actually develop against these digital standards.

And by that, I mean, their IT departments can develop things to watch the standards, to do certain things with the standards and use them in ways that they haven't been able to use them in the past. It's just a much higher utility, much safer way to use standards, especially they're changing. And then to like you said before, when things are getting pushed down and they're being tested over and over again, how do you check after something is out in the market to see if they are still compliant with the standard? When everything is connected and you're able to start doing those checks in a much faster way.

EE: Standards creep, right? How do you address that kind of a concern? How do you make sure that standards are loose enough for innovation, but tight enough to keep everybody on the same page?

Audra: Yeah, that's a good question and that's certainly something that's probably even better answered by our standards development groups. One of the things in particular, my role is I take the outputs of our standards development groups and I'm able to create that the standards in a way that have a higher utility for the end users. Now, if, like you said, they're authored very broadly, then it doesn't matter what type of format they're in. The content is the content, is it's too broad. And like you said, the application specifics and the design specifics are done in such a way that things are not... It's not really helping, like you said, have a common solution in the sense that the end products are interoperable.

And that's certainly a malfunction of the standard itself. What I've seen is it depends on... from my experience, and again, I'm not an expert in specific types of standards, because there's so many different types. They have so many different types of standards. What I have seen in general, there's a couple of things going on.

One is that it really depends on the intent of the standard. And so I know that the standards development, the different committees are very specific on the intent. Sometimes they'll say if the intent is that it is so that equipment can talk to one another kind of like the example you just gave, then you're right. Then when that doesn't happen, then that is likely not a tight enough standard. But there are times where they say, "That is not the intent, the intent is something else." And then obviously, then that's a whole different issue.

So one of the things that I have seen to touch on what you opened with regarding how the different players in aerospace are really changing and have changed over time. The technologies... It's a really exciting time for aerospace and for the autonomous vehicle industry. But the technologies are moving very, very fast and standards... Typically, standards take a very long time. One standard might take two to five years to develop. And so to reach consensus, I should say, and have all these people reach consensus.

So by the time technology gets to a standard, the standard it's fairly mature, I should say. And so there's this disconnect of very fast-moving technologies and standards that really can't keep up. And so we're noticing a change even in how standards are being authored to accommodate for that. And so I think some of the mismatch, oftentimes that may happen, maybe a result of that happening. The standards were not keeping up.

It depends on the development and how far along certain things are. So you could be compliant with the standard, but there's so many other adjacent technologies that you're using that you can be part of the standard. But the other pieces that you're using don't have a standard yet. And so therefore that's kind of where things are breaking down. So I am noticing a lot of that, where the technologies are moving very fast and there just isn't a standard because there just hasn't been... It's just too many new emerging technologies.

EE: Or it's migrating so quickly. Which brings us to our next question. Think about a standard, like IEEE 1588, right? That's an industry clock standard timing. So that everybody's on the same sheet of music again, as it were. When I start thinking of aerospace applications, I start thinking of things like space taxis and the like. And at the present time they're treating a lot of these of micro satellites like passive cargo. Well, one day they might actually actively be talking with these packages while they're being translated from one orbit to another or from one level to another. They'd have to agree on what the data bus is going to be.

Audra: Right. And that's when there is a benefit to try and find some kind of standard for those kinds of things, that's a really good example of, there are so many things that are moving fast, even if you had all the manpower in the world to create standards, it's virtually impossible. The other challenge too is, this is really completely separate from digital standards, but just in general statement is that most standards development, happens at volunteer organizations like SAE. So there's committees... the people in those committees are also the ones that are developing the technology. So the organizations that are so generous with their employees' time to allow them to volunteer at organizations like at say... they're competing.

They have to make sure that their developers' time is being used appropriately between doing the work that they need to remain competitive and relevant in the industry, and also serving industry by providing these standards. And so there is this for the same amount of people. And then when you add the increased demand on their time for their day job to develop, and then also on the standards side, there becomes a choke point where there's just almost not even enough manpower to keep up with the standard side. So I have noticed in general, for all standards organizations that has been a challenge.

EE: Although you could make the argument that that would give the engineer a better handle on standards compliance. In other words, the engineer would become a more professional engineer by participating in professional organizations.

Audra: That's kind of what we try and encourage them to be. And that is the reason why they would want to be involved. It's really is a matter of where a lot of the development is going. If it's going into these working technology areas, there are no standards for them, that it's just moving so fast. And so there's always a balance between, "I don't readily want to work in these technologies, they're nowhere near ready for standards development."

That's when we noticed that the more mature technologies that are going through standards development, those typically have the more mature engineers that have been around for a long time. Because they understand and then they're able to make those standards. And so we see a bit of a divide even in where somebody is in their career as to where they are in participating in standards committees.

What I like to see, and I have seen happen over time, is that some of them more seasoned engineers will pull in the younger engineers so that they understand the value of standards. These are so critical, not just because their organization is saying, "Hey, you have to use it." But when you're doing your designs, consider standards up front prior to just being a mandate coming from the top down.

EE: One last question. How much do you consider your role a passive one of... Well, actually I shouldn't say curation, is it really passive? I would say a semi-active role like curation and a proactive role like indoctrination, education, assistance, formulation.

Audra: Mine is a very active role in the sense that... So when the standards are developed, the expectation is that that they're ready to be used by industry and industry is using them. In the past, like I said, it was a PDF format and that's how they were using them. My role specifically is very active in the sense that I need to understand how engineers use the standards, not just which standards they use, which is very important, but how they're using them. How is this connecting into their larger ecosystem?

So it's not enough to just say, "Okay, we take this information and then we usually put it into this little system." It's, "Okay. And then what happens and how does that impact the supply chains?" To use a buzz term, the digital thread, following all the different pieces of our standard and where they go within our customers' supply chains. And understanding what software systems, what internal systems, even if they're manual systems, what are the systems that are necessary in order to distribute the different parts of the standards so that you can operate?

So in that sense, it's very active because when we get the content from the standard, regardless of what type it is, it is my job to make sure that it is provided in the highest utility format possible for customers to use. So that they actually get some benefit from the standard beyond just the content itself and their operations. So a standard's great. But if you make it so low tech that they have to hire a bunch of people to be able to move information around and track information. You definitely have a safer product, but at what cost for our customers. And so they want to make sure... We want to make sure that they can continue to make safe products, but they also can operate with a better margin than perhaps they may have otherwise.