Bridging the AI Deployment Gap with MOSA.ic.AI: Your Trained Model, Deployed for Deterministic Inference in Constrained, Safety-Critical Environments
When we wrapped up our recent joint webinar with Military Embedded Systems, moderated by Group Editorial Director John McHale, we realized the Q&A session at the end was packed with gold. Our audience asked incredibly sharp, practical questions about real-world deployment, GPU support, and safety certification. We figured if these topics were top-of-mind for our attendees, chances are they’ll be valuable to you, too. Below, we’ve published the full list of audience questions along with answers directly from Ernie Harrison, Principal Software Engineer at Lynx. He dives deep, covering everything from signal processing and operator fusion to safety certification (DAL levels) and supported hardware.
If you’d like to watch or listen to the full presentation on "Bridging the AI Deployment Gap with MOSA.ic.AI," register here.
What the Webinar Covered
While AI innovation is accelerating rapidly, deploying trained models into mission-critical, embedded environments remains a massive engineering hurdle. Traditional AI frameworks excel at model development, but they simply weren't built for the deterministic inference, workload isolation, and strict certification requirements of aerospace, defense, and safety-critical systems.
In this session, Bridging the AI Deployment Gap with MOSA.ic.AI: Your trained model, deployed for Deterministic Inference in constrained, safety-critical environments, we explored how LYNX MOSA.ic.AI solves these challenges. We demonstrated how to optimize AI inference for Size, Weight, and Power (SWaP)-constrained embedded platforms while keeping AI models executing predictably alongside real-time, safety-critical workloads.
Key topics included:
- Seamless Workflow Integration: How to bring your own trained AI models into MOSA.ic.AI without altering your existing development toolchains.
- Deterministic Inference: Achieving predictable execution behavior and mixed-criticality support on edge devices.
- Unified CPU/GPU Execution: Running AI alongside real-time applications using hardware-portable, open-systems architecture.
- De-Risking Integration: Leveraging Vulkan SC and open standards to simplify certification and enable long-term mission evolution.
Audience Q+A
Q: At the start, you mentioned signal processing, but is that supported?
Ernie: That's a good question! Yes, it is. As a specific example, our ONNX model supports Discrete Fourier Transforms (implemented as Fast Fourier Transforms), so we start processing directly through ONNX Fourier transforms. It’s data processing fundamental to a lot of the problems we solve for customers, so we definitely have support for it.
Q: What GPUs are currently supported?
Ernie: The Compute AI supports E9171 and IrisXe. Our VulkanSC supports ARM Mali and that is the next target GPU for Compute then Versal 2
Q: How do you preserve traceability between the original ONNX model and the GPU code that executes?
Ernie: That's a really good question. Traceability is supported through ONNX metadata. ONNX natively supports a very large amount of metadata within the model and is passed through and is part of the runtime asset package. An integrator can generate a model, have the metadata for requirements, and that same metadata will get populated again in the output in the runtime asset.
Q: Does Vulkan SC make an AI application certifiable, or does it just make certification more practical?
Ernie: That’s true about Vulcan SC, OpenGL SC1, and OpenGLC2. They in and of themselves do not make the application certifiable. What they do is provide a stack that’s certified. The application itself still needs to go through typical certification activities, just like any other application.
For instance, if you write an application to a POSIX standard and put it onto a certified RTOS (like LynxOS-178), which is certifiable, you have certification evidence you can leverage as part of your certification program. You can utilize POSIX to write a portable application, test it on a desktop system to make your life easier, and then bring it over to your target environment—but you still have to certify it at the system level. You would be able to leverage all the evidence from Lynx-OS178, Vulcan SC, GLC1, GLC2. All of those types of APIs are so you write your application by API. Something we are doing as part of our MOSA.ic AI Discovery product, we are working towards qualifying the tool. Our expectation is that the output itself will carry certification evidence with it, which will simplify things for the application developer. Something else we’re doing that's unique with this product is we’re outputting sources. A lot of times when you're dealing with software, it’s binary. We are targeting a source deliverable and source generation because we’re at the point now where AI is just an accepted standard in the industry. Everybody’s using it, so we think there’s more value in generating source with safety certification evidence that customers can pull into their AIs, use and understand and leverage as opposed to a binary that their AI can’t consume directly.
Q: How does the tool handle operator fusion and other model optimizations?
Ernie: Operator fusion is based on pattern recognition. Over time, you observe that certain operator sequences repeat constantly across model architectures. Because of these predictable chains, fusing operators into a single dispatch to save execution time is relatively straightforward for the tool. It’s not difficult for the tool to say, “Oh, I see this pattern, lump it together, do it in one dispatch, save time.” Now that can of course introduce errors and it can introduce difficulty in determining runtime and accuracy. To address this, our tool allows you to turn fusion off. We also support the ability to dump intermediate tensors; if you are concerned about output accuracy at a specific step, you can turn on more sophisticated debugging to inspect the exact data.
Q: What ONNX operators and model architectures are currently supported?
Ernie: Well that would be a long list because ONNX is so large. ONNX supports over 160 operators that the standard supports, so we have taken a practical, targeted approach based on primary customer needs, mostly around object detection and video processing and things like that. Specifically, we support the YOLO category of models, along with Discrete Fourier Transforms, and we support linear algebra operations. That said, there are certain operations we will likely not support for determinism reasons. For example, I’ve heard some discussion around a standardized subset of the ONNX operations for safety critical applications. There are some there that potentially swill generate random numbers if you want them to, there're nodes that introduce branching We’ve had some discussion around not supporting branching -- when you have a shader, if you branch in a shader, because coverage is difficult in a GPU or a source object analysis is difficult in a GPU, adding branching just raises the level of being able to certify that.
Q: In terms of safety criticality, what is the current maximum certifiable Design Assurance Level (DAL)? If DAL C, do you see DAL A in the future?
Ernie: We actually have a colleague on the FAA board for AI, and that is currently the DOW level we’re talking about. While there are discussions about moving up the DAL level up (and there is a different gentleman in the product management group who is working with the European Union equivalent of the FAA around that), those roadmaps are roughly 5 to 10 years out. In the short term, I don't foresee anything beyond DAL C simply because when we talk about DO-178 certification, we need to be able to quantify the input. It's very difficult to do. Such a broad amount if input to feed into AI. In theory, if you could exhaustively prove and quantify inputs/outputs, you could certify them. For something like an FFT, I could see a certification for that because it’s finite. But when we talk about more traditional AIs, there is a reason that DAL C is the maximum level right now.
Q: In SOSA-compliant radar systems, how can designers leverage ONNX models to classify RF signatures for drone-like RSC?
Ernie: That's interesting. I assume that ‘s specifically trying to do signal processing to identify specific drone signals. That would be a very good application. Identifying RF signatures based on something that a drone broadcasts or receives could be done in a compute model that is relatively finite and a safe, critical system. If you can define that in an ONNX model – which is why we put ONNX as a forefront model we support -- ONNX is not limited by any means to AI. That name is a little misleading. Despite the name (Open Neural Network Exchange), ONNX is not specifically for neutral networks. It will describe virtually any math you can think of. If you can turn a mathematical formula into a a tree of operations, inputs, and outputs, you can create an ONNX model for it.
Q: What happens when the compiler encounters an unsupported ONNX operator?
Ernie: It fails. That is a best practice: fail early and fail loud. We provide a concise list of supported operators we support alongside conformance test results. Because ONNX is an open standard backed by Meta, Microsoft, and the Linux Foundation, it’s very well supported and it includes robust conformance tests. As part of our deliverables, we provide conformance results directly so if you have a model it should be pretty easy to figure out if you’re going to have any issues, long before running it through the tool.
Q: Can you measure the execution time of individual internal parts of a neural network?
Ernie: You can measure the dispatch and the action itself. The dispatch has an overhead of the time it takes to load and run. Just like any process on a CPU, you can only measure parts of it internally. We don’t have that resolution with a GPU. But we can measure the entire dispatch. If the dispatch is fused, then you’re measuring all of the actions plus the overhead dispatch.
Continue the MOSA.ic.AI Series
Watch Part 2: Lynx Technical Account Manager, Ethan Salehi, explores how to make AI execution predictable in safety-critical systems. Watch the recording here.
Join us for Part 3: Hear how collaboration can help accelerate AI deployment in this partner spotlight (more details to come!) Tuesday, October 20 at 2 p.m. ET. Register here.
Questions About Deploying AI at the Edge?
Talk with Lynx about bringing trained AI models into embedded systems with deterministic inference and support for safety-critical workloads.
Learn more about MOSA.ic.AI here.
