AI is moving into aircraft, ground vehicles and other systems, where a wrong answer can cost lives. That creates a tough question for engineering teams: how do you prove an AI model is safe enough to fly, and how do you guarantee it runs predictably once deployed?
Lynx and Ansys, part of Synopsys, tackled these topics in an Oct. 20 webinar, Lynx's third in a series hosted by Military Embedded Systems. Titled “Building End-to-End AI/ML Workflow Blueprints for Safety- and Mission-Critical Systems,” Gabriel Pedroza, Principal Trustworthy AI R&D engineer at Ansys, part of Synopsys, walked through a model-based workflow for designing, validating and certifying AI-enabled systems. Bob Monkman, Director of Product Management at Lynx, followed with a look at how the LYNX MOSA.ic.AI platform runs those AI workloads deterministically on edge hardware.
If you'd like to watch or listen to the full presentation, register at https://www.lynx.com/mosa.ic.ai-webinar-series.
What the Webinar Covered
Pedroza began by looking at the traits that make AI hard to certify. Models behave statistically. Their stability, robustness and generalization must be characterized. They demand heavy compute, they can be attacked, and they increasingly drive autonomous functions with safety consequences. Standards bodies are responding with SAE ARP6983/EUROCAE ED-324 for aerospace, the European Union Aviation Safety Agency’s AI concept paper and ISO/PAS 8800 for automotive.
The Ansys autonomy architecture is built to align with all three.
To show the workflow in action, Pedroza used a joint Ansys and Lynx demonstration first showcased at the MOSA Summit. Two helicopters fly in formation. The trailing aircraft uses an AI detection model to spot the lead aircraft, and a helicopter emergency stopping (HES) algorithm issues warnings, braking commands or a handover to the pilot. The requirement: Keep at least 70 meters between the two. The first simulation failed at the 20-second mark when the model missed the lead aircraft at close range. The workflow traced the cause, the team retrained the model and adjusted its thresholds, and the replayed scenario held separation.
The system then moved to hardware-in-the-loop testing on the Lynx platform.
Monkman picked up at deployment. He noted that most commercial AI stacks lock users into closed ecosystems and lack determinism, integrity monitoring and a path to certification. He framed inference as one stage in a longer chain, from sensor arrival through preprocessing, GPU execution, post-processing and a safety gate, all within a strict timing budget.
“The right answer late is wrong,” he said.
He then covered how the LYNX MOSA.ic separation kernel, ComputeCore, and Vulkan SC keep that chain bounded.
Key topics and takeaways included:
Read on for the audience questions and answers from Gabriel and Bob
Audience Q&A
Q: Are you looking at any other AI capabilities in your products?
Bob: I’ll take a stab at that from our perspective at Lynx. In the upcoming release of MOSA.ic.AI, we're putting an LLM in the product to help automate the configuration of the partitions we talked about previously. This is typically done with a very straightforward config file approach that you would see in operating system environments in the embedded space. But all of that can be automated with AI. We’ve got a powerful LLM that we’re packaging up for the release in the first quarter of 2027. It allows you to go in and essentially prompt the LLM: "give me this many partitions with this amount of memory, these communication portals, these timing contracts," and so forth, to define the whole system, and it builds it for you.
The other thing we’re doing is building a practice in the certification area. As I said, we do certification for customers as a service, and that is the longest pole in the tent for getting to market when certification is required. These AI agents can be very powerful and effective in automating and streamlining the certification process: the testing, the validation, the generation of artifacts. Right now we’re doing a lot of work to leverage these tools to accelerate and dramatically reduce the time to certification. It’s an ongoing project that’s still in its early stages, but we’re excited about what’s possible, and we think it can turn into IP and services down the line.
Q: Any plans for other AI/ML use case demos in the near future?
Bob: Yes. Lynx in general is working with our customers and our partners to identify a whole cadre of them. We’ve actually been developing more AI use cases, and it’s not just a demonstrator. The notion here is that we want to create a workflow, a working reference solution. We refer to this as a blueprint concept. The idea is that if you’re building a certain use case, say a primary flight display or an IR camera for monitoring and interpreting what’s in the theater of operation, and there are dozens of examples we’re looking at, we can create blueprints and working examples utilizing our product, our utilities, our libraries, open-source components, operators, helpers and partner solutions to create a starting point that our customers can build upon. That’s an exciting area that we’re going to be expanding in the coming year.
Q: The workflow was demonstrated in an aerospace use case. How difficult would it be to apply it to a different domain, such as automotive?
Gabriel: This is interesting because, as I mentioned during the presentation, the aim of this workflow is to make it cross-domain. That’s why we’re actively participating in different standardization groups. The most relevant are the one for aerospace and one for automotive, and we’re also following what’s happening in aerospace. So we have those three, and part of our work at Ansys, part of Synopsys, is to identify the commonalities in the development cycles proposed by those standardization committees. The challenges we have for implementing AI/ML are cross-domain, and that helps us justify that, to some extent, what we’re proposing can be applied to other domains such as automotive.
We’re actually developing a similar use case for automotive. It’s not yet implemented, but we’re starting to use the blueprint we worked on together with Lynx to develop it. In the helicopter use case, we performed formation flying and tested the emergency stopping feature. In the automotive use case, we’re going to validate an automated emergency braking system. Those are comparable use cases, and we expect to have no difficulty applying this workflow.
Q: The datasets were synthetically generated. How should the sim-to-real gap be considered?
Gabriel: That’s a very interesting question, because for this work we essentially used synthetic data. However, we have conducted tests to enrich that synthetic data with real data. Overall, what we observe is that the performance of the trained models increases, and that’s very encouraging, because we can see convergence between the data generated in our synthetic data generator and images or data gathered from the ground. So the approach is to combine them, and that’s what we rely on to address the sim-to-real gap.
Q: What is the maximum DAL level for a safety-critical application that uses AI? Will it be DAL A sometime in the future?
Bob: From our perspective at Lynx, this is a very interesting question. The whole thing we’ve discussed today is how we can lock down and bound an AI application and make sure it executes within strict timing contracts and resource contracts. Fundamentally, our architecture allows for mixed criticality, so we can prevent that AI application from interfering with any of the other safety-critical aspects of the system. We believe we could protect the system with an AI application that could be fully certified to DAL A.
But my sense is that in this space, these applications are going to be considered a lower level and not as trusted early on, and that’s their prerogative. We believe that over time, once uses of AI are proven trustworthy and properly bounded, there will be cases where they do get certified. It’s really going to be up to the primes and the OEMs to decide, and it’s got to be proven. So it’s a bit early, but we think it’s promising.
Gabriel: Just to provide further information, the current standard on safety of AI in aerospace, ARP6983/ED-324, is limited to DAL C. So, as Bob mentioned, the first target is certification for levels C and D, and in a second step, we’re going to address levels B and A.
Q: For the helicopter retraining and validation, how can you demonstrate that you did not overfit your model? Do you have test datasets?
Gabriel: This is a very complicated question. To the question of whether we have test datasets, the answer is yes. The main aim in preventing overfitting is to avoid a trained model that is too dependent on the data used for training, meaning it’s not capable of generalizing well when new data is used, for instance, during a given scenario. This problem is really serious. We cannot claim at this point that we have addressed it in this use case, but we have created the baseline to address it, because the blueprint we have, including the target hardware, provides all the necessary elements to analyze generalization and prevent overfitting. So this is one of the targets we can address with this blueprint.
Q: Can you support any GPU from a safety standpoint?
Bob: Actually, no. The whole system has to be designed for safety and be able to be certified, and some GPUs are not designed for that and don't have the ability to be certified. So we work with our semiconductor partners on GPUs that are specifically designed for it and can be certified. They have their own requirements on the silicon, and we have our software requirements. We work with those partners on the certifiable GPUs, and then we provide the software infrastructure to ensure that applications running on those GPUs, whether AI or graphics, can do so deterministically and be certified. So it does depend on the GPU.
Explore AI for Mission-Critical Systems
Want to learn how to bring AI into your safety- and mission-critical applications? Contact our team to discuss your project, or watch the webinar series on demand to revisit the sessions.