0:01 All right, thank you very much. So hello everyone. My name is Austin Herrema. I’m going to be giving the presentation from Istari Digital. We’re calling it the digital thread in the real world. Multiple partners, multiple tools, one truth. As I said, I’m Austin Herrema. I’m not Rebecca Melber. Unfortunately, she’s fallen ill today. So, I’m going to be going it alone. So I appreciate the grace for these few slides where it’s personal experience of Rebecca’s, but I will do my best to give her perspective.

So, Rebecca has lots of, experience in the classified engineering space and a big problem there is how do you securely share data? Of course, we need to share data in order to collaborate effectively in engineering. But there’s risks that come with sharing data. So, these images, as far as I understand, are this is an Amazon Snowball on the left. I don’t know if anyone’s familiar with this device.

1:23 I was not. This is a a ruggedized device for uploading terabytes or even pabytes of data. And so what Rebecca was doing here was flying around the country for a program that she was involved in, a collaborative program, flying this thing around the country, collecting data from the different engineering partners, right, into this one location, and then eventually winding up on the floor of her vehicle with all of this data, now trying to create a single source of truth, uploading this to an S3 bucket or some secure place where all of that data lives.

2:00 So you can see how this would be extremely inefficient and and really not practical for engineering. We’re talking about all the rapid iterations that Agentic engineering enables. AI agents still can’t fly around the country and and collect data from different engineering partners. And this also creates duplicate data, right? We talk about working from a single source of truth. The second you do this and you upload to a centralized location, you’ve created duplicates of that data and you’re no longer working from the same quote unquote source of truth.

5:04 So, this is the problem. This centralized source of data. So, as I’ve articulated, siloed systems, sharing barriers, there are good reasons that sharing this data is not as straightforward as uploading to a Google Drive or Dropbox or something like that. There’s there’s real security concerns especially when it comes to classified data. IP protection is a reason that any company might be nervous about sharing their data and as I’ve said there’s now no single source of truth when we engage in these kinds of methods.

So what are we doing about it? Estari has what we’re calling the industry one program. That’s 15 members drawn from DIIB and FFR DC and URC partners. So academic and and lab partners the goal is to have connected tools and not centralized data. So each participant works in their own environment and shares only the data that they choose only the data that needs to be exchanged in order to engineer effectively.

And it’s going to be proven out through a realistic mock use case in in this case a full UAV system design spanning all of these 15 member organizations. So that part is where I come in. So I’m I’m responsible for implementing the use case for this industry one program. As I just said it’s a UAV design. UAV is a good use case for this kind of thing because it’s inherently multi-disciplinary right everyone in the room will understand that.

We have structures we have aerodynamics we have electronics. So there’s there’s a lot of engineering work to be done there across across the disciplines. We’ve divided this up roughly into four stages. Stage one being kind of the part level design things like the wing or the PMU or the engine. Stage two is higher level system modeling. So the mass prop overall mass properties of the model or the overall electrical properties of of the UAV.

Stage three is now higher level performance. What does the the flight control look like for the the full system? What is the overall airway worthiness? And then finally most importantly the mission model. Is the UAV actually capable of succeeding in the mission set out for it? And then finally a stage 4. This is the full requirements verification stage as well as we can go to scaled component prototyping.

5:04 So this is the system with the use case. I’ll differentiate between the system and the scenario for the use case. So this is the system that we’re interested in. And let me just hang on that a little bit. So this is a multi-disiplinary design problem. In theory we have good good tools for doing multiddisciplinary design analysis and optimization already. I included some images here from open mdao.

5:28 I don’t know if anyone in the room would be familiar from from NASA. And this is an N2 diagram that I have in the lower lower right here. I find it to be a helpful visual. Each of those blocks is a subsystem for a given system design. Each of the rows is a parameter. And this is showing between all of the subsystems, how do they exchange data?

5:49 How do they exchange numbers from from one system to the next? How is everything connected? And we can actually diagram out the entire system. So in theory, this is great. This combined with model based systems engineering where we have high fidelity models to simulate subsystems with a high degree of accuracy. All these things combined in theory gives us the tools that we need to do integrated systems engineering with a high degree of accuracy.

6:20 What are the real challenges though in the real world? There’s challenges when it comes to version control. So auditing how a solution is obtained that’s frequently just as difficult as obtaining that solution in the first place. I think everyone’s familiar with the underscorefinal_fal-2 kinds of issues. Engineering tool integration. So every tool is different. We have disperate disperate engineering software APIs and licensing strategies. Distributed compute. So implementation on a variety of hardware and operating systems is common and that’s due to both software and domain expert limitations.

6:57 Some software only runs on certain types of operating systems or certain types of hardware and also not everybody knows how to use every software and every operating system. So they can’t be expected to reasonably just take a a workflow that they built up and move it to an entirely different system. They might not have the skills to do so. And then cross environment collaboration. This is the big one that I just spent a lot of time talking about.

So true expertise is frequently distributed not between just different engineers but also different companies. So I think of this as like tiers of silos. We have tool- based silos compute or operating system based silos you can think of and then also company based silos. So what does offer in terms of a solution for this? I won’t spend too much time going over all the details of Astari.

7:49 There’s a team over here that would love to talk to you more about that. You can come talk to us at the the booth there. At a high level, the Aari control plane has a lot of features. Again, I won’t go into too many details, but we have our access management that’s of course critical for security. We have a front end that’s a a web UI that’s for human interaction but it’s actually a code first platform.

8:16 We have a registry which is our object storage which enables version control of of large files and large amounts of data. Version control and that comes with things like CI/CD branching change requests things that the software industry has been using for for decades now. And this all enables AI in ways that I’ll talk about a little bit more later. The thing I’d like to focus on here is our integrations, jobs, and workflows.

8:41 So first of all, when when we talk about jobs, those jobs can be run on any type of hardware that we configure within the platform. So any of us that work within an organization will understand that there might be personal computers, there might be workstations configured for FEA, another workstation configured for CFD, and then maybe an HPC cluster for larger jobs, FA or CFD jobs. The ATARI platform allows us to register all of those resources within the platform.

9:13 It will understand what software is installed and configured in terms of licensing or anything else and route jobs to the appropriate resource. So this allows a domain expert to set up maybe a very complicated analysis, but then a manager to come in later and and re-execute something, maybe update a parameter and rerun without understanding all the details. The platform understands, okay, this is an FBA analysis. This needs to go to this workstation.

So that’s that’s our jobs. You can imagine chaining those jobs together. That’s workflows. We’ve seen a couple great presentations illustrating those kinds of workflows here. Then I also want to talk about the integrations. So it was well articulated before that like interfacing with each of these software platforms. Each each software is unique right and soari provides standard modules to interact with all the major software platforms your your Crayos kias of the world as well as FAA platforms Nastran those kinds of things and also allows custom module development so to support any custom workflow that you may have those modules support any number of functions it could look like changing a parameter it could look like executing an analysis.

10:34 And one thing that we are sure to include in all of our modules is extraction. We think that this is a pretty important concept. Extraction is taking the data that exists in a vendor locked format. Could be a PRT, a Solid Works part, a Nastrand file, Ancis DB, extracting that vendor locked data into open formats, things like JSON, TXT, OBJ, PNG, things that one, humans can understand very well, but also the agents can understand very well.

11:06 Claude has no problem with JSON, even if it’s not my favorite file format to pour through as a human. So this allows us to easily extract the formats that can be easily interpreted and built upon by both human and AI agents and it allows us to extract and share only the data that we want to share. So if we want to share some aspect of our CAD model, we don’t need to share the entire CAD model.

11:27 We can extract this into its subcomponents and share only a piece of the data. So this is unlocking those silos at the software integration level and the network distributed compute level. Then let’s go back to the sharing cross organizational sharing level. This is really what industry 1 is about. So as a software is deployed within a company’s infrastructure. This is not a centralized repository where everybody uploads their data.

12:01 That won’t work in in the aerospace industry where we work primarily you can install on your own infrastructure and what I’m illustrating here is one company that might be deployed on AWS another company that might be Azure so they have their own instances they have their own machines set up their own compute workflows but they need to exchange data how do they do that has what we call the secure connection service which allows us to share digitally and securely.

And there’s some critical ways that we do that. Basically we work through an outbox and an inbox. And it’s very flexible and configurable. So, scanning is enabled during the sharing process. So, different companies will have their own requirements for security. For information to enter their network, they might need to scan it for different kinds of vulnerabilities or or attacks. And then it goes into their inbox but then it will be pulled into their estari instance along with the metadata.

13:06 So this is how we enable secure sharing across multiple companies. So back to the use case, we have all of these different subdomains of design. 15 members of this consortium. Each bubble here is one of the members of the consortium. And we’ve assigned a subdomain, an engineering subdomain or multiple to the different companies. And you can see how data is now expected to be shared between these companies.

13:34 Again, we’re not all uploading to a single source of truth, which is what you might expect for something like this. That data is being shared as a network and it’s kind of chaotic as you can tell. One of my favorite analogies for this is this puts me in mind of the nervous system, human nervous system. These are like neurons and you can see what would be like the electrical systems firing across those neurons exchanging data.

13:58 And it looks kind of chaotic. You might think like is this scalable? Well, in the lower right here, I have a picture of the internet, a 2D visualization of the internet. Very brainlike, highly complicated network, but of course, we use the internet every day. So, this is scalable. So in a sense here, we’re building the internet for digital engineering models. Another question we get when it comes to this use case is like, how realistic is is the engineering that you’re doing here?

14:32 Are you going to be able to build a UAV? The short answer is no. We don’t have the resources to fully develop a UAV. So these models are simplified to some degree. You can get a sense of what the interface looks like here. Although if you were here for the demo yesterday, you would you would have seen a star already. And this is one part here. This is a a simple generalized radial engine.

Of course an engine would actually be many many parts, right? This would be one big assembly. And so we’re not getting to that level of detail. This is just a simplified model. Where we aren’t simpl simplifying is in the formats of of these models. So this is actually a seaman’s nx CAD model and you can see on the left there that we’ve actually done the extraction so that we can understand that data within the platform and take a look at it.

15:17 And I also just want to illustrate that the platform allows uploading and version controlling of documents of of all sorts. So not only CAD files, any complex engineering system will have all kinds of different information that needs to be tracked in a system configuration. So the platform allows that. I’ll just give you here a sense. This is like a gallery of the different software and models that we’ve we’ve implemented.

15:44 So I mentioned Seaman’s NX already, Nastran, Cameo, 3D Experience, Crayo, there’s a few others. These are just the the more visually interesting models that we have in the use case. So again simplified models but when it comes to the software that we’re leveraging quite realistic like this is the soft the software platforms that our partners are using and I’ll now return to the N2 diagram concept. So Y-axis X-axis we have all of the engineering subdomains that I mentioned earlier.

16:16 On the right hand side you can see we already talked about how we’re unlocking data from the different software platforms. That’s one of those columns. We’ve also now talked about how we’re unlocking the data from different environments and different companies even I haven’t really harped on this point but some of these sorry instances are deployed in AWS commercial some are in the government AWS space some are onrem installations and we’re able to share across all of those so with those things unlocked and our secure connection service you can now enable sharing between all these different subsystems the colors of the boxes in the middle are different companies.

16:56 So any square that’s filled in the off diagonal indicates a share of data between subsystems and typically between companies. So this just would not have been feasible without this kind of network sharing and compute enabled. So on this dimension of the use case, we’ve actually made it much more complicated than what you would see in reality. Collaborating across 15 partners just would not be a good idea for a complicated program like this.

17:26 Then that finally leads us to the scenario for the the use case. So we’re setting up the system to enable collaboration. What are we going to do with that? We’re looking at a DMSMS audit which is diminu diminishing manufacturing sources and material shortages audit triggered by the department of the air force digital transformation office to evaluate the content of foreign sourced material across the airframe and evaluate domestic substitutions.

17:50 This is a very real possible scenario. A DMSS was performed for the B-52 in 2023 and the results were not great. The conclusion was that the supply chain challenges identified could impact the Air Force’s ability to keep the air aircraft flying. So just highlighting here that the full product life cycle support is one of the big value propositions for a framework like this. We talk a lot about design and that N2 diagram is typically talked about in terms of design but the life cycle support and supporting things like audits is a pretty critical use case as well.

18:24 So in this use case what we’ll do is the upstream partner will update their requirements right they’ll add a requirement actually a domestic sourcing percentage requirement and tweak some other parameters like maybe the mass allowance is a bit higher for the overall UIV and now we propagate all that data downstream. The metric is how easy is this to do and how or how much of a pain is it right?

18:50 You can imagine that this would be a pain if it turned into email threads of everybody sharing their information. And here this will be all facilitated within the platform. I won’t harp on this. This was touched on quite a bit yesterday with the demo. But we are approaching this as a code first platform to make this a GitHub software like experience for hardware. So software style collaboration means change requests.

19:17 It means continual evaluation of the requirements. This was talked about in the previous talks which I appreciated that defining those requirements and continually evaluating them is critical when it comes to AI and agentic engineering. In a sense you can imagine you can think about this as the the guard rails for AI right we’re building the system we’re building the models we’re defining the requirements but then this is a space within which agentic AI can safely operate transparently and even across organizations so in summary multiple partners multiple truths one one source of truth I’ve talked about how we extract that our data into vendor neutral artifacts those artifacts s can be shared.

They’re interoperable without standardizing the tools. Folks are developing all kinds of great tools and they should not necessarily be competing with each other but working together. And this allows auditable histories without hallucinations. We’re providing guard rails for a AI to assist us with our engineering. That’s what I have for you today. Thank you very much.