Hello, I'm your host Grayson Brulte. Welcome to another episode of SAE Tomorrow Today, a show about emerging technology with leaders and innovators who make it all happen. On today's episode, we're absolutely honored to be joined by SAE Aerospace AS7140A committee members Robert Taylor from Bell Flight and Dave Larson of Collins Aerospace. On today's episode, Robert and Dave will share how the AS7140A is helping to standardize rotorcraft health and usage data to improve interoperability. We hope you enjoy this episode. Gentlemen, welcome to the podcast.
Good morning. Glad to be here.
It's great to have you here. I've said this on many episodes and continue to say this on many episodes going forward, because I'm going to say it right now. Standards make the world go round. Without standards, you're not flying an aircraft. Without standards, you're not driving in an automobile or riding in an automobile. We're going to dive into standards today, gentlemen. To kick things off, the AS7140 standard, what is it from an engineering perspective, and then how would you simplify that for perhaps a non-technical audience?
Yeah, sure. So, the 7140 data standard, it's actually a digital data standard. It's a model and with a, you know, written document to go with it. And the problem here with 7140 on a technical level was to reduce the variations of data coming from helicopter platforms to the ground so that more simplified and unified ground systems could be utilized to read and visualize that data across multiple platforms. So, whether it's a Sikorsky Black Hawk or, you know, a Bell Boeing, you know, whatever platform, that would give the opportunity to visualize all of that data across the fleet using a single ground-based system or cloud-based.
I'm sitting here and I made some really good food last night. I'm like, 'Oh, the kitchen's going to be a mess.' But I'm looking at the data being a mess. Robert, I'm curious. Variations of data. It's like, 'Oh, there's a lot of ingredients, a lot of different ways this could be interpreted.' Before the AS7140 standard came about, how many different variations of that data were there, and how complex was it for the ground to ingest that?
Pretty much everyone had their own version of it. I mean, everyone had their nuances on it, their terminology. You know, so there's been that, and that's, you know, whenever we formed this group and we were having these conversations and we started realizing that sometimes terminology didn't exactly match up, right? So, we were always, you know, looking at each other and having to get into deeper conversations to try to understand, you know, what we're each saying and why we built kind of systems the way we did, and to try to get to the heart of what we needed to do.
Yeah, I would say quantitatively there's probably seven to 10 different data standards, which means there's no standard, right? Coming off of aircraft today.
But gentlemen, I have to ask you, terminology. Some individuals get their heels dug in. Sorry to say that, and that nope, nope, it's this word and that means this, and then there is no moving. Even if you were to dot the I and cross the T, they're still moving there. Standards take consensus. How did you move the group towards a general consensus when there are certain individuals that say, 'Nope, this is what it means and I'm not budging'?
Yeah, so when we first started this committee, and the committee was formed to solve this specific problem, you know, within SAE. And basically the 800-lb gorilla in the room was the US Department of War, known at the time as the Department of Defense, and specifically the US Army. And they were getting ready to kick off Future Vertical Lift Platform, which is a brand new, first time in 50 years, Army helicopter spec. And they said, 'Look, this cannot continue like this. We have, you know, operators or maintenance engineers who are using five or six different systems to, you know, inculcate and ingest all this data and visualize it, and we want to be able to compare data across the fleet. And since we are, by a factor of 100, your largest customers, you will adhere to our request to come together and make a unified standard.'
Robert, this with the data coming off of the aircraft, this sounds very familiar to the OBD port in a traditional car. Am I thinking about this the right way?
Um, mostly. I mean, we don't have the same like hardware necessarily on the backside, but as far as being able to interface with the vehicle and being able to get the data off, you know, to kind of look at it similarly, you know, like a lot of tools that you see that when you plug it into your car to get diagnostics. Um, we kind of see that very similar to kind of along that same line.
It's interesting. So, some of the data that you're gathering is rotorcraft health. You're also getting usage monitoring systems off of it. How is that data being used? Is it to determine the outcome of a mission, to determine the health of an aircraft, or how is that like to the US Department of War, for example? Not classified. I don't want anybody knocking at my door, but from an unclassified standpoint, how is that data being used?
Yeah, so the data is used to determine the overall health of the aircraft, and so that is on a component level and a vehicle-wide level. So, there would be monitoring of bearings and shafts and gears to make sure no sudden vibration is coming up or slight vibration that could lead to a longer-term failure. So, think of it, if you can go back to the automobile analogy, right? So, you know, you have tire pressure monitoring in your car. This is like that, okay? So, it alerts the maintenance engineer or in some cases the pilot and crew in real time that you have a problem and you need to land, or you have a problem that we can address, you know, sometime within the next 3 months. And, you know, we're basically continually providing and then analyzing data on different aspects of the mechanical health of the system.
If you look over at data over time, right? Sometimes you start seeing certain trends. So, you might go, 'Hey, I see this problem getting worse. Maybe within 50 flight hours you might need to, you know, replace something before it turns yellow and then it causes other things, right?' Or get to a better repair shop because, you know, as you know, like if something happens mid-air, you can't just pull over on the side of the road.
And then for, you know, military aircraft, in this case we're talking about military helicopters for the most part, or oil and gas in the commercial arena, or EMT helicopters or whatever, you know, aircraft availability and the predictability of that availability is a big aspect of it as well, right? So, you know, it's not like you can necessarily land the aircraft, pull another one out of your garage, and take off like you're using your wife's or husband's car. So, you know, it's very key to understand, you know, tactically the health of the aircraft and strategically the availability of the aircraft.
And so, obviously, either civilian or military use of the standard, there's a common denominator: data, and a lot of data. Are you gentlemen seeing or hearing about any specialized data engineering roles that they're specifically focused on analyzing this data, either for the companies or for the division of the military that they work for?
Yeah, so, you know, of course, data science, you know, is a rapidly evolving engineering role now, and, you know, there's a tremendous opportunity with getting all of this data in and ingested in a, you know, standardized manner. So, again, you know, at the fleet level or at the enterprise level, there's opportunity to use big data techniques to analyze this information and get useful information out of the data. And then, of course, as with everything else today, you know, the more data you have and the more robust it is, the better opportunities there are for true AI analysis of the data. And so that is going to be certainly growing. And of course, there are some people who would say that, you know, use of this data is artificial intelligence by definition, but, you know, we'll just take it as actual legit utilization.
Is one of the key benefits of the standard just across the board to increase uptime?
Yeah, I think that having the data enables preventative maintenance to occur. So, again, if you go back to your car situation, if your oil light comes on or your tire pressure monitors indicates you have an issue, you can get it handled in advance. So, not during a mission or a crisis scenario, you can do it on your own schedule. Maybe perhaps you need to route parts to a location to do a repair, you can do that. So, there's performance-based logistics aspects of this as well. So, the goal is with any of this type of health information is to transfer unscheduled maintenance into scheduled maintenance.
Which I think is a beautiful thing because I'll just use one of my terms and it optimized the product and optimized the experience. And Robert, this is an interesting thing that stood out to me reading the document. The AS7140 standard defines a data structure without prescribing a specific physical format for it. Why was that decision made?
Yeah, so if you go back to a lot of the failed standards, right? Is that they were prescribing something very detailed and, you know, how the bits and bytes were written. One of the things, you know, once we got over our, you know, getting into the right jargon and, you know, the right, you know, what the terms mean, we created the data model. So, we're the first standard that actually has a MBSE standard, you know, which is also now causing a lot of further work for the other standards. But the core part of it is that if we can at least start talking, well, you know, the same language, and specify this as our data structure, now we can when we get to the serialization part. And serialization is more of a secondary thing on this, and as long as your serialization is following, because as, you know, technologies progress, you're going to find better ways to serialize, or you have cases of, you know, like the requirements to get the data off the aircraft, I want to be a file as small as possible. But once it's on ground station, you know, it can be a SQL database, it can be a NoSQL database, it can be XML files, right? And open up how someone wants to serialize that in the most optimal way for their processing. So, that is why we went with lean more on a focus first and then serialization second.
And this is an aerospace and general question I have, but how important is flexibility?
Very important. I mean, if you look at that's why a lot of standards were not selected because, you know, they were hardwired as in like you can only have these fields and these capabilities versus a lot of our serialization standards allow for flexibility. So that if someone says, 'Hey, I need to add this extra field. I need to add this extra data.' You know, as long as you're kind of putting the general data, you know, in the similar spots, right? Then your data looks very similar to everyone else's to be compared. But also allow for adaptability to add additional fields and add additional data elements to extend what's not there. And, you know, as we were working through this, right? We still know that there's still some areas, you know, like engine performance, right? That we haven't touched yet in the standard and some other things. So we still have, you know, some gaps here, but I see this as this is the initial, you know, skeleton that we can kind of start hanging things off of that have the core concepts that need to be there for our HUMS systems, being vibration data and also parametric data.
Yeah, another thing to consider with regard to flexibility. So the model as it is now can handle, as Robert was pointing out, you know, added pieces of data without changing the model itself. And in the aerospace industry, you know, especially commercially but also on the military side, it's a very slow process to roll new things out into the field, right? So, you know, as opposed to automotive where, you know, you might retool a car every two or three years if you're Chevrolet, you know, new even a software update can take five years to get into the field for aerospace. So having the flexibility in the model and unspecified serializations allows the accommodation of changes without recertification.
If there's somebody that plays in large data sets all day, the ability to customize the data set, add your own elements, add your own fields is a complete game changer because you have to customize it for what your needs are. Is that very similar, I mean that's very simple terms, is that what you're seeing with your customers that either for a civilian aspect, a private ownership aspect, a commercial aspect, or a military aspect, that they need to be able to get different pieces of data depending on what their mission or what the application is? Is that how we should think about that?
I think that the base data set on the military side for rotorcraft is probably 90% constant and 10% might vary back and forth. I think the broader aspect of it is as we move the standard from rotorcraft to fixed-wing. So, we're already having the US Air Force applying this to a fixed-wing platform. So, by definition, you know, they're looking at different things than a helicopter manufacturer's analysis would want to be looking at, and, you know, there's opportunity to apply the standard to, you know, unmanned vehicles or even ground vehicles going forward, and they'll each have different things. So, yeah, that definitely applies.
So, it's funny because right now the standard's primarily focused on rotorcraft drivetrain systems. Where do you see it going next, and why did you focus on that little niche to start?
So, the drivetrain is the most sensitive or likely to fail, I guess I could say, area of a helicopter, right? I mean, a helicopter's basically a bucket of bolts trying to shake itself apart at every opportunity.
