Webinar: Digital Mission Engineering Part 2

0:00 good afternoon and welcome to the webinar everyone I'm Josh I'm gonna be your host doing some of the logistical things while our presenters can focus on delivering you the message the presenters here today are Jeff Baxter who's here with me in Exton office for AGI Jeff heads up our engineering department and he's gonna be doing the first half the presentation and then with us on the line is Joshua Edwards senior Application Engineer from Phoenix integration and he's gonna be taking

0:22 over the second half of it so with that Jeff hand it over to you and you guys do your thing all right Thank You Josh and thanks to Joshua for joining us from Phoenix integration today's topic is going to be connecting engineering and mission analysis to systems models across the lifecycle I definitely want to encourage any questions throughout today's presentation at any time please enter those in the chat Joshua and I will be ready to answer them at the end of the

0:47 webinar so today's webinar is part two of a four part series focused on digital mission engineering and in part one we introduced what digital mission engineering is and why it's important so this webinar will then begin to answer the question on how to apply digital mission engineering so for those of you that didn't see the first webinar or even for those that saw it we're gonna do a quick recap on the what and the why and then quickly move over into the how

1:17 so well first discuss after the recap will discuss STK systems toolkit and how you can build mission models very quickly using SDK and how that fits into the overall digital mission engineering ecosystem and we'll introduce a quick demonstration that we'll be building on throughout the course of the webinar series and focusing it on constellation design in this first webinar I'll then pass things over to Joshua at Phoenix integration to give an overview and demo

1:47 of integrating the SDK mission model with the accept with an Excel cost model and running architecture trade studies using model Center and from there we'll share some indie industry examples of folks already using these tools to get today then we'll do a quick wrap-up and a summary and move into QA and talk about the rest of this sessions where we're going to be focusing heavily on sysml MA integration as well as engineering simulation with with ANSYS so let me

2:20 start today's webinar by defining what digital mission engineering is so really what the definition is is the use of computer-based modeling simulation and analysis tools to design build and operate systems to achieve mission objectives and it's bolded thereat mission objectives it really is all about the mission these programs these systems are created in response to a need or a requirement or a gap that is needed to achieve some desired mission

2:50 objectives so we really want to put the focus here on the mission and the reason digital mission engineering is so important right now and really all the digital transformation initiatives going on in the industry is that our competitors and adversaries are rapidly advancing their capabilities and becoming much more sophisticated and as a result the missions are becoming more complex the systems are becoming more complex and the engineering processes are more

3:21 demanding to deliver those systems and at the same time you also have customers that are demanding more advanced missions and requiring delivery at a much tighter time line and so the graphic here kind of illustrates that with complexity on the y-axis you see is increasing while delivery time on the x-axis is decreasing so that's really what's causing the need for this digital transformation is to deliver the most

3:53 more complex capabilities and systems more rapidly and so one of the biggest challenges in doing that is the ability to influence outcomes it significantly decreases over time and so if you identify critical issues later in the program lifecycle your ability to change them actually decreases significantly so this really applies to any phase of lifecycle whether you're designing a new system or planning an operational mission you need to identify those critical issues as soon as possible so

4:25 that you're able to still deliver and effective solution after identifying those critical issues so let's start by looking at a an example program life cycle and here it all begins with again the mission the customer identifying a capability gap or a mission need at which point the next step is to come up with a conceptual idea to then meet that mission need and that should then flow throughout the entire rest of the program from system requirements and

4:54 early design to detailed engineering design implementation all the way through testing and operations and sustainment and what we see today across the industry is a lot of isolated models a lot of reinvention and stovepipe tools and not really a common thread across the entire program lifecycle so starting at the concept development phase there are typically some basic mission models that may depend loosely on physics to help understand the overall concept of the system and as the program atures a

5:24 new mission model is created to handle more the detailed physics models you see there's broken lines that are indicating there's typically multiple tools that are used to perform specific functionality for their areas of expertise and then these models are then ultimately used to define the requirements thread which is then used throughout the rest of the design implementation manufacturing and testing so and this is the part of the program that is typically further separated from

5:54 the mission model and the mission need and so once the system is finished the new mission models will then be created to then test and see how well that built and delivered system accomplishes that mission and there's typically a new mission model for this and the same thing happens in the training operations and sustainment areas and so as you can see this leads to typically a lot of isolated tools reinventing of the wheel and it makes it very hard to tie

6:21 everything together and the thing that compounds this problem is this is just talking about a single program or a single project and when you get additional projects or programs even if they're very similar there you kind of go through this same process from beginning to end as well so the vision of digital engineering is to have combined in and persistent models throughout the program lifecycle and in order to do that you need to have a good mission

6:48 model that defines how effective your system is at meeting the initial mission needs at the beginning so from there you can define your system model your subsystem model platform model component model all the way down to the component model and as you work through the rest of the program life cycle in order to do to have an enduring authoritative source of truth you need to tie all those models into a multi domain physics environment and

7:18 another aspect is that it's important too as we discussed earlier to identify those critical issues as early as possible and so bringing as much of that fidelity as early as possible in the life cycle ideally during that concept development phase so that can be done by either using the higher fidelity tools earlier in the process or by using previous models for existing systems and finally another important aspect of the digital engineering is the concept of a

7:49 digital thread so you can think of each of these models as individual strands and for all this to work together they need to be integrated like a thread so that way when you change individual parts of one model it pulls through the rest of the models as well at any point in a life cycle and in the previous webinar we discussed and we quantified some of the impacts of not applying digital emission engineering which mostly fell into three high-level

8:12 categories of tool reinvention model could recreation between those different phases and lack of tool integration and in the net and the webinar we discuss how addressing these issues can accelerate the timeline by a factor of two and a half to up to six times so that's again kind of the what and the why of digital mention engineering so now what I really like to focus on is a how so how do we go about doing this and

8:37 although the digital engineering initiative is still fairly new agey i has spent the last thirty years developing a digital mission engineering framework what we call STK systems toolkit and SDK allows you to quickly build computer-based models of platforms and their performance sensor models communication models threat models in the environment model and bring those and combine them into a physics-based multi-domain system of systems simulation and analysis environment and underlying this

9:09 framework is a time base geometry engine that provides a common reference frame for time and coordinate systems that allows us to analyze all of these different systems in the same environment and also SDK has a a modern search version control security and scalability environment that helps you manage your modeling and simulations and most importantly STK allows you to calculate over 40,000 metrics out of the box that quantify that mission

9:40 effectiveness and you can then output those parameters as text reports as graphs as surface plots as you see here or communicating the mission effect in terms of images and videos showing the system's performing an emission environment is very very powerful and compelling and so while that is a lot and it covers a lot it is still there's always going to be a need for additional customization on top of what's commercially available through SDK so

10:10 that's where its SDK has an open API and in where it becomes easy to extend customize and integrate with other industry standard tools programming environments and and other data formats as well so to help illustrate how the SDK can be applied to digital mission engineering we've come up with the notional demonstration that will be building throughout this webinar series and the objective of this demo is to design a cost-effective constellation of satellites that provides communications

10:42 missile defense and Earth imaging and the requirements here that we're going to look at in this webinar are the communications and specifically we want to provide 24 hour continuous communication over a selected group of ground locations and we're going to design this with a series of constraints listed here which are one to five orbit planes one to five satellites per orbit plane and the altitude between 500 and thousand kilometers with a payload field of view of 110 degrees so so let's go ahead and

11:16 start building out this scenario and to help illustrate the the the timing savings and how quickly you can build up these mission models we're actually going to be building this from scratch so if you're new to STK it has an integrated 3d graphics and 2d graphics environment and allows you to bring in a wide variety of systems so aircraft satellites missiles ground vehicles ships as well as ground targets and then attach all of the payloads to those

11:46 sensors communications equipment radars and and there's a variety of methods for doing that so for a satellite in this example we're going to use the orbit wizard which allows us to select from a list of common satellite orbit types in this case we'll just do a 1000 kilometer circular low-earth orbiting satellite as our initial satellite for consideration and here we can see this satellite in the 3d graphics window the ground track

12:16 in the 2d graphics window and now we can insert our payload and in this case we're gonna do a pretty simple geometric field of view and we're going to give it that 55 degree cone half angle based on our mission requirements and from here you can see the the sensor field of view you can see the footprint on the ground which is the areas on the ground that we can communicate with and you can then begin to play through the simulation and

12:41 you can see as that satellite orbits as a footprint changes over time so we're gonna go ahead and bring in a target deck and in this case we just have a group of the top 15 most populated cities in the world and we want to look at how well we can communicate from our satellite to those ground locations how often can we see those points we can visually inspect the scenario and see we've got a certain amount of coverage

13:03 but what we want to do is really calculate and quantify that mission effectiveness so how long can we see those two ground targets and the way that we're going to do that is by grouping all of the targets together in a collection which we use a constellation object and a grouping of all of our sensors now right now we just have a single sensor but we're going to quickly look at other satellites with additional sensors soon

13:29 for later and then what we can use is a chain object which is a very pail for object in SDK that allows you to perform this group analysis from one grouping of objects to another grouping of objects you can have multiple hops you can have different constraints in this case when is my sensor see any of my targets and then I have a variety of data providers I can choose from such as when can I see

13:54 any of these targets but more importantly what we're interested in looking at is when can I see any of the targets throughout my entire 24-hour time interval from any of my sensors so this graph is now showing you all of the communication times and all of the gaps so the gaps are just the empty spaces and the communication times are the green bars and so what we want to do is design a system that has continues

14:20 24-hour communication over the entire scenario so to do that we're into a quick design orbit trade study where we're gonna vary some of the orbit parameters of our satellite that we built from from pretty much default settings so here we can use analyzer to select any of the inputs from SDK and any of the outputs from SDK and then one run a wide variety of trade studies on those inputs and outputs so the input that we'll look at here is our

14:49 satellites inclination and the output we're going to look at is the total duration of the contact times from our sensors to our ground targets and then we can define starting and stopping values for that inclination so in this case we'll look from 0 degrees to 90 degrees of inclination and we'll do a step size of 5 degrees and see how that impacts our overall communication times and so we can see here as the trade study begins you can see the the plots

15:21 returning results and you can also in the 2d window see the orbit ground track changing as the trade study is executing SDK in the background and here you can see the data again pop you the scatterplot which is showing me my best communication time at a given inclination so so that's a very quick trade study inside of SDK and what we want to look at is the extending that to

15:52 multiple satellites so rather than just a single satellite which can't provide complete 24 coverage let's create a constellation of 25 satellites let's look at the max conditions and let's create a walker constellation and let's see how well that performs against it so here we just created the Walker constellation it inherited the same sensor from my original satellite and I can then animate my scenario to see what that looks like and what that coverage looks like so the thing we need to do

16:22 now is update our grouping of sensors to include all of those satellites all 25 of them and now we can simply refresh our report and see if we got that continuous communication which it looks like we did in this case that that we have a solid line meaning we have communications at any particular time and then furthermore we can visualize that with the yellow lines from the ground targets to our satellite constellation we can begin animating and

16:49 getting a visual understanding of the design that we came up with that meets our communications requirements so so this was a very quick example of using STK to provide that mission model to design your satellite orbits your payloads and quantify that mission effectiveness of how well can I cover all of those ground targets and while this was a good quick notional example it didn't really get into that in trade

17:20 study to answer how many satellites did actually take and we looked at one satellite and 25 but we now want to explore that trade space a little bit more completely and we want to look at other factors such as integrating maybe a cost model just because all of these satellites can provide it that doesn't mean that this is the best design so at this point what all I'm gonna do is I'm gonna go ahead and turn things over to

17:42 Joshua and at Phoenix integration thank you Jeff my name is Joshua Edwards I'm a senior application engineer from Phoenix integration I just want to thank AGI for having Phoenix and myself on this webinar all right so let's hop into it and continue on the great demo that that Jeff just gave for SDK so first off I just want to level set the audience so

18:15 if you've ever attended a Phoenix integration webinar before in the past you may be very familiar with this image this is something we used to give everyone an understanding of what model center does and so this is an image of a symphony orchestra it's comprised of expert musicians who are very talented in their craft but it is also made up of a conductor and so the conductor himself themselves don't play an instrument but

18:45 they are very vital to the to the orchestra in that they can duck and keep the the rest of the the orchestra in sync and produce a ammonius result so what if you had a conductor for your engineering tools and analyses you'd be able to to keep them in sync and keep them for working together so that they could produce a very valuable result

19:15 across multiple disciplines so our answer for that is Monell Center specifically we have three capabilities of model Center model Center integrates model Center Explorer and model Center and BSC and so what I'm going to do is I'm going to dive a little bit into each one of these just to give everyone an understanding of which each capability does so that there's understanding and then we'll move into the demo and you'll be unable to understand where and which

19:48 pieces are working together so to start out with model Center integrate model Center is a vendor-neutral tool so we're able to run anything with a API badge and scripting up to allowing users to develop their own plugins so you can see here in this little diagram we have just a very small set small subset of tools our customers have automated but that's

20:18 not an exhaustive list so we allow the users or mouth center allows users to automate any engineering analysis - whether it's a cots or in-house tool 20 year old Fortran code using blackbox execution so for models to integrate - to run any execution it just needs to know how to execute that engineering analysis and which input and output variables to expose so treating it like I said as a traditional blackbox

20:48 methodology once we have automated a tool in this fashion we can then integrate them together into a workflow this is still with model Center integrate so you see here in this example workflow we have a bunch of blocks tied together so each each block here as we call a component represents a blackbox analysis and then by bringing

21:19 them and integrating them to the workflow we're allowing each one of these components to pass data from each other from one to the other so in this case we can see in the top left corner the data from from that top component will pass its data down to the subsequent components in the workflow this allows for the automated execution and transfer of data for multiple engineering tools once we have a integrated workflow of all these

21:50 components and analyses we can then run a trade study so this is an example of a do-e tool that we have as one of our many trade study tools so our trade studies will drive the workflow once it's been integrated so as you can see here we allow the specification of your design variables and your response you can then set the balance for your design variables from loaves to highs you can give them discrete options to

22:22 choose from and you can select different designs that you'd like to run so when you do finally configure your trade study and you execute we'll hit the Run button it will produce a table of data so we see here in this little snippet of a table we have two thousand one hundred and ninety seven runs each column here each run represents the execution of the work flow so we executed the previous

22:56 workflow that you saw two thousand one hundred ninety seven times automatically just by setting up a couple bounds specifying the design variables and the responses in ending the run button moving on to the second capability which is model Center Explorer this allows you to take that data all this large amount of data that you've that is produced in this table and allows you to visualize it visualize it so when I show just a couple quick

23:27 visualizations here to give a taste one right here being a parallel coordinates plot of the data we can do things like variable importance or sensitivity summaries of the data to show which variables are most important to which responses and then we can see here we have a tool or a visualization called our prediction profile called contour plot where we can apply constraints and look at our designs base in an interactive way and we can move around

23:52 the little black dot you see to to show what that design represents and where it is in the design space explorer also has capabilities such as response surface models probabilistic sand optimization but I won't touch on that at the moment so moving into the third capability model Center NBIC this allows the integrations of systems models such as the one shown here this

24:23 is a parametric diagram and so the way we do that is we connect the system model value properties two variables in a model center workflow so one that we saw previously that we've automated and integrated we can tie those two together and essentially it's tie the systems engineering world to the domain engineering world the way we're actually able to execute this is with the the tool MBC analyzer and what this does is it gives a representation of our

24:56 value properties here in this dashboard allows us to modify these and give different values to our value properties once we've done that we can hit the Run button and we see here that it actually with these little arrows will actually go and execute and build the workflow that's associated with that with the diagram or the elements in the system male model magic draw model go and build

25:26 a workflow using the value properties that we've specified execute return update it results for the responses and then lastly we can check to see if requirements were met if we had satisfied relationships implemented in our magic draw model the NBIC tool nbac analyzer will go and verify if those requirements were met so we can see here represented with the green check marks

25:56 and the red x's whether or not a requirement was met or failed other capabilities for model scenario C include the execution of behavior diagrams and I'll touch a little bit on that later in the presentation so as Jeff alluded to he integrated a or he developed a STK scenario so what we're

26:29 gonna get into with our model Center demo is actually going to take that STK scenario integrate that in with model Center and also add in in Excel call spreadsheet so that we can get a visualization or plot or trade study for cost versus that access duration where that coverage of of communication in SDK so if you haven't seen Model Center before this is the GUI and I'm just going to highlight

27:00 a couple of the the three the three sections here so we see the blue section in the middle this is what we call the analysis view this is where we will build the workflows down in the bottom is what we call our server browser you can think of this as our toolbox so we can bring in plugins that come out of the box with Mal Center that users have developed or engineering analyses that have been made reusable and they can

27:31 just be dragged and dropped right into the workflow the the third section here is the component tree over to the left and that's just going to give us a tree view or a tree structure view of the workflow so it's going to show all the components in the workflow along with the inputs and output variables for each component will be able to modify the inputs here and then will be able to view the outputs after running the

28:01 workflow here as well so without further ado I will go ahead and start the demo so the first thing we're going to do is go down to that server browser and grab our SDK plug-in and specify the scenario the constellation design scenario that Jeff had already constructed we see SDK actually launches in the background so this will be actually be performing the analyses we can go ahead and minimize that and just like what we saw in the

28:32 SDK analyzer we're going to go ahead and select a few inputs and outputs that we'd like to vary so in this case we're going to bring in the inclination but we're also going to bring in those Walker variables that define the constellation next we'll look at the output in this case we're going to do that duration of complete access where do the total sum for that and once we hit the ok button we see we have we

29:03 can rename our SDK component and we call this constellation design over in the component tree we can expand it to see all the variables that we've exposed to model center the inclination the Walker component variables and then the sum of the complete access to raishin doing a quick run to make sure things work as expected and we do get an output here but next to take it to a next level test we're going to run that same parametric

29:30 study that we saw before in SDK bringing in the inclination and bring in the sum of the complete access duration we're gonna do a little shorter bounds on our sweep here just do 10 samples just to make sure we get some of the same behavior or the same behavior that we saw in SDK so running produces the same plot just with fewer data points so that looks like a good integration here we're getting as expected results and here of course is

30:04 the table of data that the scatter plot was used to populate so we're going to close all this this was just a test to make sure that the integration of SDK was successful and then next we're gonna go ahead and bring in the Excel plugin to bring in our cost spreadsheet so we'll drag and drop that into the work flow as well specify the spreadsheet that performs our cost calculations and this spreadsheet has named ranges

30:35 specified for cells the plugin will go and identify those named ranges and bring those in as optional variables we can see things here like cost per launch cost per satellite and ultimately we're looking at the total cost of a constellation that we we like we're gonna go ahead and give some metadata to that specifically units of millions of dollars apply our changes go ahead and rename the Excel component as well to cost

31:07 and then just for some organizational benefit we're gonna go ahead and rename or reorganize the the variables so if they're a little bit more intuitive with the inputs at the top and outputs at the bottom next we'll want to link these two models together so we want to link SDK to cost or to the excel so we drag a link from one to the other model Center recognizes that that we have two variables that have the same names and

31:33 both components we say we want to create those links and you and we can verify that with our visual link editor that shows those links in a visual format so we can see here in the SDK component we have number of planes as linking to number of planes in the cost and same thing with number of stats per plane so now we have an integrated workflow we can go ahead and run this as well we see

31:57 that the data from the number of planes and number sets per plane from SDK is passed down to cost and then now we will set a couple of initial values for our inputs just before we run a do e of our constellation design so we're going to bring in a number of planes and number of SATs per plane we're gonna bring in that sum complete access duration and

32:32 then we're also going to bring in some variables from the cost as well so we're going to do total SATs in our constellation and the total cost will specify the ranges that we would like to run for each of our design variables so we're going to do one two three of number of planes incremented by one and then number of stats per plane is one two five incremented by one as well so this gives us a total of fifteen runs so

33:00 we hit the Run button we will execute the workflow 15 times with those different design variable values and fast-forward to the fifteenth run we can go ahead and do some visualization so we're going to bring in a basic scatter plot and start setting up the scatter plot to do cost versus that sum of two for complete access so switch to our total cost as the x-axis and the sum for our y-axis and just for for visual sake

33:34 we're going to give the color as total SATs we can also apply constraints to the plot so in this case we're going to take out some of the more expensive satellite constellation designs and also some of the lower performance constellation designs as well and we can see here that shaded those in feasible those are the gray points and we're left with a subset so we have a nice knee in the curve here we're gonna select one

34:00 point a number of planes is one a number of sets per plane is five notice that this doesn't have the the highest coverage here but looking at the the trend it's looking like the best bang for the buck and so therefore if we wanted to increase coverage we'd have to increase cost as well all right so moving forward here that was the the demonstration but I did want to allude to a couple of use cases in industry

34:33 where the DME methodology has been implemented so this is the the first webinar I believe that was presented in the was discussed in the previous AGI webinar series part so this is the Lockheed Martin osiris-rex webinar this integrates systems models with domain models specifically SDK using model center to determine if we violated satellite keep out zones and if those

35:05 requirements were met or not so I'm not going to talk too much more on that since it was already presented but these are webinars that are hosted on the phoenix integration webinars page and you can see the link down in the bottom right hand corner if you'd like to check that in fuller detail so it did want to talk about one more industry use case that's also a webinar that we host so this is one that was done by Parsons

35:33 this was their distributed model-based systems engineering webinar presented Eamonn Thomas Albert hem Phil and Tim Gatos link for that is down at the bottom as well and so getting into the details of this webinar not gonna spoil it and go into great detail but it won't do want to give a little taste about what it's what it encompasses so that you can have some interest in it and go and view it yourself so first off one

36:04 main goal or objective for this webinar was to do distributed engineering in this case they had engineering sites across the United States so not all Parsons some supplier and technology companies as well so we can see we're distributed between California Colorado Virginia and Maryland and so the integration of models from all sites was done into one workflow using model centers remote execution capabilities and so they integrated systems models

36:37 with domain models including SDK as well using model Center in this fashion so what they were trying to achieve here or the use case that they were trying to accomplish had to do with a satellite orbiting as well based off of their technical requirements document they had 88 requirements that they had to meet this orbital trade study here focused on five key ones and those included the Sun

37:08 synchronous orbit or the orbit of this the satellite the orbital life of the satellites the requirement that we had to have a hundred percent coverage every 12 hours and then the type of sensor that we're going to using we're using and specifically with the type of sensor there was a requirement that we need to have a resolution of less than two kilometers these two were the driving requirements the the 100% coverage and the resolution of two kilometers though

37:41 the main design variable that would drive that was the orbital altitude which they could vary from four 82 535 kilometers and then they were also able to look at a reaction wheel which the logistics and the engineering for that was done by a supplier that was based in Colorado Springs which they integrated that into the workflow as well so the reaction wheel itself had requirements that it need to meet given the the pointing and the saturation so

38:15 just a little highlight of what they had to do or one of the the diagrams that they used this is their parametric diagram that they used to connect the system L model and matted Rahl to the model Center workflow to calculate coverage so we can see here on the left the value properties from their structure diagrams their blogs are exposed and we've linked that over into a constraint block that has an external

38:46 analysis stereotype that is pointing to a model in a workflow so we're going to feed in a couple of variables from the value properties the vertical half angle the circle or altitude and that's going to calculate a range of of responses most importantly is the coverage here so in summary after you know building the workflows building the the small diagrams connecting the two they were able to determine that the to maintain

39:16 sensor resolution and 100% coverage which were the two main requirements 500 kilometer orbit satisfied that and the over life was six point three years which was satisfactory as well and that is it for my portion of the the presentation I'm going to pass that back to Jeff so yes I just quickly wanted to summarize today's presentation so so thank you Joshua for the demonstration

39:46 that was that was great and good industry examples of industry already doing this today and and previously especially hooking into the NBS sea part which we are going to cover more in the next webinar so as we discussed earlier the just bringing us back to what we talked about at the beginning the whole vision of digital mission engineering is really to connect all of the engineering and systems models to the mission model that is rooted in a multi domain physics

40:14 environment furthermore these models need to be pulled in as early as possible in the process and persist throughout the life cycle so that you can identify those critical design changes as early as possible and still be able to influence the outcomes so we discussed the concept of the digital thread which illustrates how each of these models are individual strands that are tied together like a thread so that when you pull on one and change one part

40:38 of the individual model it pulls through the rest of the models as well and in order to achieve this vision it's it really requires an ecosystem of commercial tools that all integrate together from day one so what we found is it just takes too much time and effort to keep developing custom tools at each phase of the lifecycle and then trying to integrate them as you go it makes it extremely difficult to identify those critical issues early in the process which again

41:07 limits your mission effectiveness so having an organization-wide ecosystem of commercial tools allows you to quickly transition from program to program and not have to continually rebuild custom tools each time and it also provides the added benefit of reducing these significant challenges of maintaining the custom tools as well as transferring knowledge as individuals change programs or leave the organization so we we demonstrated a beginning part of this

41:38 process in today's webinar where we looked at some of these tools and applied it to a satellite constellation design so we quickly built a mission model and STK integrated it with an excel cost model with model center and ransom cause first performance architecture level trade studies and as you saw from the demo videos they were probably only about 5 to 10 minutes each so you're looking about 25 minutes from scratch to do those types of trade

42:05 studies which talks to the two and a half to six times of the timeline acceleration that we were talking about earlier so having that commercial tool said that already is pre-integrated and is ready to use from day one is really a huge enabler of this digital mission engineering environment and so I also wanted to say this is not the end this is kind of just the beginning in this webinar series of the how to

42:35 integrate things so we've got the rest of the DME webinar series coming up the next one is really gonna do a similar deep dive into the STS DK integration with sysml tools using model center so that webinars on August 13th we're going to be integrating with with Cameo through that MBS C pack that Josh wood mentioned earlier and we also have a follow-on webinar August 21st on extending STK mission models with

43:07 detailed answers engineering simulation tools so we're really excited we just have a new partnership with ANSYS and so we're gonna be extending it throughout the program lifecycle into that detailed engineering design and get into some more higher fidelity simulations and show how to integrate that all together so yeah depending on how you answer that last poll question some other next steps for you if you're interested in more information or a demo from AGI visit our website AJ comm or email info at AGI

43:34 comm and similar on the Phoenix side you can check out their website Phoenix - intercom or info at Phoenix - in comm we've got some other AG I train either AJ events coming up we have some virtual training July 25th tomorrow we have the SDK geo surveillance virtual training well we're gonna click by click through how to set that up we have a radiation environment with SDK seat virtual training and also a satellite collision

44:06 assessment training on August 1st and also on the Phoenix integration side there's a webinar on September 10th on integrating MBS C into model-based engineering environment presented by Lockheed space so I definitely check out those other events and again please register for the upcoming DME series as we will go into more detail on the sysml and the detailed engineering design phases of the lifecycle and Jeff if you don't mind me interjecting real quick one other event or that Phoenix is

44:36 hosting we have started a series of public trainings in our Novi Michigan office so we have a next round of those coming up in August so if anyone would like to come to attend a public training so you know send one send six people it's up to to your organization feel free to attend that alright so I guess with that one that was all I had

45:06 it's really quick to highlight it here this is our contact information for myself and Joshua if you have specific questions and just to highlight so these are some of the products we covered it today on the SDK side so we really only covered just a small use the tip of the iceberg there's many other products that we're gonna cover some of these but if there's other parts or other mission sets besides constellation design that you're interested in there's still much

45:32 more to sdk so you can visit our website AG edicom slash STK to find out more about other parts of the software that we just didn't get have time to cover what today and so the ones that you cover are highlighted in bold as well you're so correct yes alright let's move on to the questions there's a quite a few of them so if I ask you guys a question that is gonna get too far into

45:53 the weeds maybe you could just say well we'll take that offline and and get back to the question asker independently so real quick let's try to get through as many of these as possible when you are calculating the communication times in those cities were you including any RF modeling no in this case we were not so we were using communication term kind of broadly there and we're really just looking at the field of view of the

46:16 sensor however actually one of the modules listed here sta Communications allows you to provide the information for the transmitter and receiver and then do the RF link calculations from there great I think this next question is sort of an extension it's pretty similar how our radar search fences and other mission specific other mission specifics model so yes similar to that so you can either do a again a simple geometric sensor field of view so the sensor object can

46:48 take a variety of shapes and format so you can have it pointing in different directions you can have different radar cells represented so you can do a basic field of view or if you want to get into more of the actual radar equations you actually can put in a radar object on your on the ground or on your on your satellite wherever it exists and then compute the the radar calculations from there okay and so just for completeness

47:13 there was similar question with OPA ir s-- o-- infrared sensors and their sensitivity and cueing and things so similar sort of questions again real quick what do you think yep so similar things so one of the sensor types is is GOI our electro optical infrared and that allows you to design your sensor and look at the radiometric performance of targets and so that's how you would model that type of setup thank you all right how does model sonar enable

47:43 feedback in two-way communications for interoperability I guess that is a question for me yeah I'm not taking it so regarding feedback so I guess it completely depends on the the use case but as far as interoperability we do allow multiple tools as we saw in the demo to to be integrated so I would I would want to unfortunately I'd want to

48:15 follow up with this this question I guess off on to get a little bit more detail about what what they're thinking as far as the the use case for this got it now another question community I didn't see my tool listed what other tools can be integrated I know it's probably a long list but if you could just name some of the major ones maybe yeah so some of the ones that come out of the box with model center a lot of

48:39 the CAD tools let's see in X and SolidWorks and a couple let's see CATIA we have some others like MATLAB Excel some of the more common ones you used but just because those aren't the ones that come out of the box doesn't mean that other tools can be integrated we have an extensive list of of tools that our users have created or developed plug-ins for

49:10 themselves whether they're in-house tools or cots so like I said in the in the presentation as long as you have a way to to run the execution whether that it has an eight the tool has an API can be running batch has a scripting method and so on really any other tool that you can think of can be integrated great can you discuss the types of graphs that you have for showing multi-dimensional

49:40 graphs and Pareto fronts yeah so we only showed the one the 2d scatter but we have a quite an extensive list as well whether that's a 3d scatter or not we also have settings and objectives and different things that we didn't get into the demonstration that can highlight those parade of fronts and show multi-dimensional characteristics of our design space whether that's the you know size of the bullet or the data point the

50:11 color as we saw the opacity and then we can even set objectives in our visualization apply the constraints as we saw so it's a pretty extensive list I'd be happy to send more information or or talk in person or give a demo on those other capabilities that we have alright so Joshua you mentioned a behavior model and the question was are you gonna talk about that in a little

50:42 more detail in a later webinar yes I I apologize about that one that was one of the next industry examples that we have coming up in the next webinar series that we're going to present so I did misspeak by saying behavior when I was referring to the Parsons model but we will discussed behavior integration or behavior diagram execution in the next webinar as well all right here's one that I can answer what's the

51:13 difference between satellite toolkit and the new systems toolkit nothing it's just a name so a couple years ago it was the tool was rebranded and that satellite toolkit was the original software name 30 years ago and it had added so many capabilities for non satellite objects that it wasn't really representative of a lot of the use cases that people were you know using it for so the name was updated to be a little more accurate and it changed over to

51:36 systems toolkit but SDK it's still but it's still the same thing just a slightly different name alright so how are multiple models from different developers integrated so in that case as we saw in the demonstration of integrating you know SDK and Excel those components that we brought in could be technically hosted by another developer or another vendor or another supplier

52:09 model Center has remote execution capabilities so that essentially we can have model Center talk to other sites and pass very little data essentially run the workflow and then when it gets to the component that's hosted elsewhere by another developer it will go execute that model locally on that developers machine giving the inputs and pulling out the outputs so that IP is maintained

52:39 at that site so there's actually quite a bit of interest around this and that's what the the Parsons distributed engineering focus really was on was tying in different models from different developers maintaining IP and keeping a workflow consistent so that you could bring in sources from from all and get a multi-discipline result can you just real quickly touch on optimization in

53:11 model center oh of course so I alluded to that model center Explorer has the has optimization built into it so I think we have about 30 plus algorithms whether that's genetic gradient based proprietary things like dot we have a couple of legacy optimizations from Boeing in there as well and then even if you have your own algorithm that can be incorporated so if you've developed your

53:42 own optimization algorithm you can plug that into our optimization tool and and and run a workflow optimization that way as well great all right thank you alright so question maybe for both of you or I'm not sure what do you see as the primary barrier to the implementation of an integrated MDO system and first maybe define what MDA o is for some of the audience that might not know so I can take this one MDA Oh

54:13 multidisciplinary analysis and optimization so that is the look at you know integrating multiple disciplines not just a single discipline into a workflow and and running and getting ties in from all different disciplines the biggest barrier that I've seen or that Phoenix has seen I believe is is not necessarily technology or the tools it's more of culture or the adoption of

54:45 that that grand vision so once you can get everyone to to see the vision and to adopt it things run very smoothly so we've seen that at certain customers where they've adopted that in a cultural sense of progress has been made quite rapidly great I think that's that's great I think we're out of time here so if we did not get to your question we will followup with you individually all

55:16 right well thanks again everybody our times up you know where to find us hei dot-com slash DME there you will receive these materials as a follow-up in a in a few days and what you sign up for the next one everybody here thank you very much thanks for attending thank you thanks guys you