Breaking Down IMA and MOSA: Unveiling the Role of Modern Avionics Systems

Hello, everyone, and welcome to another episode of the Genesis podcast. Brought to you by Genesis Aero Systems. If you're jumping into this episode, guess what? This is a part two of four of a a larger podcast with the Genesis Aero Systems team. So if you're only jumping in on part two and you miss part one, You might wanna take a second and make sure you're fully caught up on previous parts of the conversation, of course. But if you're fully caught up, Then welcome back, and we're glad to have you. This is our continuation of our conversation on IMA and Moza, their differences and their role in modern avionics systems. So we're back with more conversations with myself and with the Genesis Aero Systems team to break down those differences and break down how the technology is complementing and supplementing the avionics of today. Let's jump back into the conversation. Brought it up yourselves. Let's get more specific on some equipment examples to kind of ground this in practice. How do Arink six fifty three embedded and partitioned operating for example, contribute to IMA and play a role in a a Mosa framework. I can touch on that for you. For a moment, airing six fifty three per the standard for IMA that's been established. It it provides that common framework for everybody to add their software on top of. So it is very key to the IMA side of this MoSA IME approach. Cool. Yeah. The Arinx six fifty three, the fundamental part of Arinx six fifty three is like it's like a variety of stove pipes all running on one processor, and each one of those stove pipes is running a different a different software function. It could be a primary flight display function. It could be a navigation function. It could be an autopilot control function. It could control the temperatures of the coffee makers in the back. And those are all vastly different software criticality levels, where, you know, if the autopilot or primary flight instruments fail due to a software fault, that can have a catastrophic outcome on the aircraft. If the coffee maker fails, it's not as bad, but they want to be able to reduce cost and weight. And the size of these components, they want to run all these functions on as few computers as possible. And so the Eric six fifty three allows these different software criticality levels to all live together with no chance of one affecting the other one. Right. Now I know another important part of making sure that IMA really is an integrated and a modular avionics ecosystem is also understanding the differences between the different kinds of devices that have to be integrated that have to be interoperable and speak to each other on that common framework. So what are for audience the different classes of IMA devices and How do they contribute to a Mosa framework and foundation? Well, the the TSO for c one fifty three define seven different classes of of IMA device. Okay. Probably getting into each one of those is beyond the scope of of this production. Sure. But they vary in complexity, and they vary in function, and they vary in the way that they're physically developed. Right? So it may or may not have a display on it, and that might put it into one class of one IMA class. It might just be a power supply. It might be a series of power supplies that supplies power to multiple different devices. So it's -- there's a huge spectrum capabilities that IMA accomplishes with these seven different categories. And I guess if we're not gonna get into each one, maybe give us a high level excuse me, a high level overview of why it's important to understand the classifications in the first place. Right? How does that help make maybe more intentional decision or decision making around, you know, choosing the right systems for your aircraft. I think that would come down to the different design teams that are working on aircraft and what they need to accomplish in their area of electronics or electrical system management. Sure. The TSO has very tightly defined characteristics and performance specifications for one of those, and so that design team knows that it's when they choose. And I'm a device that meets that particular class of the TSO that is gonna perform the functions that they need. So let's talk in practice some of the roadblocks maybe that you find folks running into as they try to implement these systems. So John, I'll get your thoughts on this one. What would you say are some of the challenges of implementing not only integrated modular avionics specifically, like just the devices, but then also that foundation of a Mosa approach to integrating the system. Yeah. So similar to an earlier question, The benefit is that it's an approach. That's also the biggest challenge it's an approach. There's not a set of standard guidance available to be interpreted the same for various design teams. So there's a tremendous amount of latitude. Now that's That's absolutely a benefit. As Gordon was mentioning, there's different levels of criticality for different functions in the aircraft. So you do need that latitude to still exist. But the approach without having a a a clear set of guidelines for some decision makers -- Mhmm. -- can be a challenge. And it can actually lead to to various vendors when making proposals into most systems to demonstrate why they are meeting the approach and all they could be vastly different ways of getting to the same objective. Interesting. So the benefit that it's an approach also can be the challenge that it's just an approach. Right. It's not an architecture, for example. That makes sense. So it's a little more self defined by each participant. So what are some of y'all's suggestions or advice on maneuvering that, you know, somewhat varied approach, right, to help help folks understand how to communicate that end goal and vision to folks that are coming from different perspectives and different approaches to getting their devices on Emosa. Foundation. And anyone feel free to chime in here, but John? Yeah. I think it's important that individuals who are looking to implement a Mosa based solution. Be practical about where does the Mosa aspect really matter. If there's a commercial product you can buy from somebody off the market, it today that doesn't fit into an IMA, for example, but serves a function that you need on this aircraft, and it makes economic sense, and practical sense, and safety sense. And it operates on one of those standard interfaces. Use that product. Mhmm. Don't necessarily say, oh, because I have other elements of my architecture that are part of an IMA I should find a product to cost seven times as much and use that to get the same result. So to really make sure that you're tailoring the solution, the the design that you're evaluating, or the design that you're making, is tailored to the application. Mhmm. Yeah. Makes sense. Some intentionality. Right? Correct. There's more where that came from, but we're gonna go ahead and call it there for part two of four of this conversation with the Genesis Aero Systems team on IMA. And Moza. Make sure you're heading to our website, genesis dash arrowsystems dot com. For previous parts of this conversation, information on our solutions and services and to make sure that you don't miss out on parts three and four of our conversation. So Make sure that you don't miss out. There is more conversation to be had. You can also subscribe on Apple Podcasts and Spotify for the rest of our podcast. I'm your host Daniel Littwin, the voice of b to b, and we'll catch you on the next episode of Genesis's podcast.