Webinar: Digital Mission Engineering Part 3

0:04 good afternoon everyone and welcome to today's webinar on developing physics infused descriptive models with SDK model Center and sysml tools and remember as we go through this webinar we are going to be taking questions at the end so over in the GoToWebinar panel there is a questions tab type in what you have there and at the end after the presentations we will do our best to answer as many of those questions as we can in our allotted time so with that

0:32 let's go ahead and get started today we have Joshua Edwards from Phoenix integration who is a senior applications engineer there and Jeff Baxter who heads up our engineering department here so welcome guys thanks for coming all right well thank you very much Josh and again Thank You Joshua for joining us here live in the studio too as well today for a second webinar so just for the the rest of the audience here today is part three of a four-part webinar series on

1:01 digital mission engineering in part one we introduced what digital mission engineering is and why it's important and in part two we began to show how to apply digital mission engineering starting with early concept design and trade space exploration so today we're going to quickly recap the key the key points of those webinars and then we'll be build off of that in this webinar as we move further into an example program lifecycle and show how to develop

1:29 physics and fuse descriptive models integrating at sysml tools like like cameo with the physics based mission modeling tools like STK using model center to tie everything together and then we'll at the end of the webinar we'll share some examples how have folks in the industry are using these tools today and then we'll wrap up with a quick summary and Q&A so the first thing I'd like to do is start off by defining digital mission engineering which is the

1:55 use of computer-based modeling simulation and analysis tools to design build and operate systems to achieve mission objectives it's really all about the mission programs or systems are created in order to meet a specific need or a mission gap or some kind of requirement that is going to ultimately help achieve some desired an objective and there's a lot of digital engineering initiatives going on digital transformations throughout the the industry and although the digital

2:27 engineering initiative in general is still fairly new AGI has really spent the last thirty years developing this digital mission engineering framework that we call systems tool kit or SDK an SDK allows you to quickly build these computer-based models of platforms in any domain aircraft satellites missiles and then bring in their sensor models communication models threat models and environment models and put them all into a system of system simulation and

2:58 analysis environment all based on physics and spanning land sea air and space so SDK provides a common reference frame for time and coordinate systems and all these domains it has a modern scalability and collaboration and viral environment to manage your models across your enterprise and SDK ultimately allows you to calculate over 40,000 metrics that you can use to quantify that mission effectiveness so that can be represented as reports or as graphs

3:30 as images or videos and so ultimately while SCA is very broad and very deep it also has an open API that can be used to easily automate customize and integrate with other standard data tools programming languages and data formats so that's just a quick overview of how SDK applies to the larger additional digital mission engineering framework the vision of digital mission engineering really is a combined

4:01 integrated persistent model across the whole entire program lifecycle and I'm not going to go into detail we talked about this more in previous webinars but really the whole idea is all of these models are connected across the lifecycle and all rooted in the multi domain physics environment and ideally these models we pulled together as or really as possible in the process and persist throughout the lifecycle we discussed the concept of a digital thread which illustrates how each of

4:31 these model our individual strands that are tied together like a thread so that when you pull on individual parts of one model it pulls for the rest of the models as well and the previous webinars we started building out a integrated model with STK and model Center and Excel with a cost model and we're going to continue to add on to that in this webinar today with the system model and a system l model built in cameo and adding continuing to

4:58 build on this and the rest this webinar series so in order to achieve this this vision it really requires an ecosystem of commercial tools that all integrate together from day one because otherwise throughout the program lifecycle you're spinning up either teams or individuals to develop custom tools as you progress through each phase of lifecycle adding fidelity adding different domains and then trying to integrate them all as you go and that makes it very difficult to identify critical issues early in the

5:30 process which as we described earlier really limits your overall ability to deliver effectiveness the the earlier and the program life cycle you can identify those critical issues and change them the better chance you have at successfully implementing those in and still delivering an effective system that again meets those mission objectives and so in addition to that for a single program if you extrapolate this into many programs having this as an organization-wide standard of tools

6:00 allows you to quickly transition from program to program and not have to continue rebuild custom tools and and maintain those as well as the other challenges associated with things like knowledge transfer as individuals change programs or leave the organization so we started building this representative demonstration in previous webinars we talked about satellite constellation design which is a pretty hot topic in the in the industry right now so what we did was we built a mission model in SDK

6:28 and about five minutes show how to do that a constellation design and then we spent the next few minutes talking about building and accepting and integrating that with an Excel cost model and model center and then running a cost versus performance trade study and then we talked about the next step in the process chose to then link these mah these mission models to the descriptive models in in model Center and we highlighted some industry examples that show people

6:56 already doing this and so this webinar I'm really excited because now we're in going to detail in the sysml using cameo and show actually how to do this so as a quick recap this was the demonstration that we showed in the first webinar series and you kind of see some of the values that we were changing the number of orbit planes the number of satellites per orbit plane and in the upper right you see the output that was created

7:20 which does that cause first performance trade study which shows you depending on how many satellites and planes you have you're able to get a certain number of communications our coverage time to a series of locations on the ground and the more satellites you have the better coverage time but also the more expensive so by integrating SDKs mission model with the cost model in Excel and doing some trade space analysis with the trade study tools and model Center it's

7:48 very quick and easy to do these cost versus performance trade studies and identify the best designs so now in this webinar we're going to be focusing on a earth imaging use case and really starting to go into more detail we're going to be maturing our design kind of throughout the problem the program life cycle and so now we're going to go into more detail on the sensor design and the revisit rate and integrate everything with a descriptive model using Cameo so

8:17 more specifically we'll be designing an earth imaging satellite constellation that has requirements to revisit all locations on the globe within plus or minus 60 degrees latitude every hour and we also have an image resolution requirement image resolution or ground sample distance of no greater than three meters so the images on this slide show that some of the sysml models that we use to build this in cameo as well as the mission model and sdk where you can

8:47 see in the lower right the globe view with the satellites and sensors and then the properties of those models the in sdk in the upper right that show the things like the focal length the detector pitch as inputs to STK and the calculation for ground sample distance and then all of that is all tied together into the into the system L model so let's go ahead and get started with the demonstration here so on the left side of the screen is

9:17 cameo and so this is what has our descriptive model this is our sysml diagram representing our constellation of satellites and on the right hand side of the screen we have SDK and so STK is our mission modeling environment that has all the satellites it's time dynamic it's physics based and you can see visually what that system looks like in its actual realistic configuration so on the Left our diagram consists of a

9:48 constellation orbit planes satellites and imaging sensors those are the main components of our model and the first where to talk about is the overall constellation and so there's value properties that define the constellation including number of planes the the time to revisit the ground sample distance the ran separation and the s centricity so these are some of the value properties that define our constellation and we also have constraints on this so

10:18 there's constraint properties for the image quality and revisit time which ultimately we're going to be pulling from SDK based on the other inputs in our model so that describes the overall constellation and and then that's made up of individual orbit planes so in this case we have orbit planes defined as based on their inclination of the satellite orbit plane the semi-major axis the ran and then the number of satellites so notice in this case the

10:48 integer we're using is 5 but the block is a one-to-many as we're using multiplicity here in sysml to define that and then in the satellite block going the next block down we've got some other inputs and value properties set so true anomaly argument of perigee and then we also have a constraint for the payload size which is coming from a calculation based on the Imaging sensor definition our imaging sensor definition shown here has the

11:18 details of our sensor which is things like the focal length and detector size and detector pitch so the focal length is of the lens itself and you see the values here represented in meters and the detector pitch and these values throughout the entire demonstration are all notional they're their representative of a small set configuration or a CubeSat so that's again another hot topic and the industry is leveraging these small satellites and

11:50 these constellation of satellites to provide a variety of capabilities to either military use or commercial use so that defines our our sysml overall diagram and now we're going to do is we're gonna go in a little bit more detail in the cameo model and show how we've hooked this up to different requirements that we have as well so specifically we have a constraint set for image quality and revisit time and we're going to be using these to define

12:21 the the requirements of these using a requirements diagram so so this diagram here shows the requirements diagram it consists of three main blocks we've got a sensor coverage block we've got a sensor size block and a command-and-control block the for the purpose of this demonstration we really going to focus in on the sensor coverage block so this sensor size just says that the sensor must fit within this small size because we're looking to CubeSat

12:53 the command-and-control says what the communications requirements are to task the satellite but the sensor coverage is where we're really going to focus the purpose of this demonstration and there's two main requirements the first one as we discussed earlier is the constellation must revisit all locations within plus or minus 60 degrees latitude every 3,600 seconds so that has an upper bound at 3600 seconds similarly for the resolution we must collect imagery at a

13:24 ground sample distance of greater than three meters so here we also have the upper bound set here at three and the units of meters so now what we want to do is we want to integrate our block definition diagram that shows our constellation with our requirements and and the way that we're going to do that is we're gonna be use a series of links and and we're going to build up a brand new block definition diagram here from scratch to show you

13:57 how how quick it is to do that so we're going to drag over our constellation that we had built previously and the first thing we're going to do is we're going to show the value properties that we want to look at for this example so you can see all the ones that are available the two that we're interested in for the constraint properties are the ground sample distance and the time to revisit these are our two requirements

14:23 we want to validate so here we can see those two that are now pulled into our requirements diagram and what we can do is we can also drag in both of our requirement blocks as well so these are the again the resolution and they were visit times that I showed you in the previous diagram we're just copying them back into here so that we can do some linking and the linking we'll do is what's called this satisfy link and so

14:55 this allows us to connect the ground sample distance value properties in our in our constellation to those requirements and then ultimately we would be able to see if we satisfied those or not when we start integrating with nvse analyzer so here we can see those two satisfied links being drawn here in this diagram and that's that's pretty much all you have to do to link up the ground sample distance and the the revisit time and then we'll be

15:24 calculating those values later using SDK to see if we've satisfied those and the way we do that and jumping ahead a little bit this is the NBIC analyzer portion where you can actually see that this value is going to be evaluated using STK because it's part of the model Center ecosystem that is being exposed through the MBS sea analyzer so this allows us to put an upper-bound value on a requirement you can see it's satisfied

15:54 by the ground sample distance and you can do the same thing for the further four visit time it also has that applied stereotype using the MBS II analyzer requirement and it has the tags that identify it and identify the upper bound of that specific requirement so that's just a sneak peek we're going to Joshua's gonna be going in more detail about em BSC pack a little bit later all right so now we've got both of those the

16:24 next step is to start linking all these together and what's called a parametric diagram so the the parametric diagram is what allows us to really hook all of our inputs and outputs to find those relationships and then it's going to be evaluating those outputs based on our inputs and again all based on SDK so this is where the the descriptor the physics infused descriptive models takes place we have our descriptive model we want to we have some input some value

16:55 properties we want to calculate some outputs and we want to keep track of all of that in our descriptive model here inside a cameo but we want to take advantage of Stks a multi domain physics based mission model at the same time so the way that we do this is you have all of the the value properties for the constellation list on the left just as we discussed previously so things like the number of planes for the number of

17:24 satellites for playing the inclination semi-major axis in particular in this case we're I mean changing things like the number of satellites or number of planes you can see those getting linked to the the constraint block on the right and then you also have the inputs for the imaging sensor the detector pitch focal length and detector size so so it's similar again to what we had all listed in our original block definition diagram the only difference is in the

17:50 pair metric diagram here we're hooking that all into this constraint block and you can see all those values and these will eventually get all put into Model Center for evaluation so on the on the right hand side that's how you can tell if it's an output so that is what SDK will ultimately be calculating as revisit time and the the image resolution so so that's a quick demonstration of how you set up your sis ml models to work within

18:21 the mission model we discussed discussed briefly how they link together through m BSE analyzer so now what I'm going to do is I'm going to turn things over to Joshua to talk a little bit more about how that connection happens and then he'll run through the second half of the demo here shortly thank you Jeff so once again for those not familiar with model Center I'm going to do it just a quick recap on our products our

18:47 capabilities just so that everyone is aware of where we fit into the mix so as I discussed in the last webinar model Center has three capabilities a model Center integrate which allows you to integrate and automate engineering analyses into a workflow and run that workflow many times as necessary the second capability is model center Explorer so this once you have a integrated workflow you can search your

19:19 your trade space or systematically search it with optimizations do probabilistic analysis and things like that advanced visualization the third capability which we're going to focus on today is model Center and BSC so this is what provides that integration to the system l descriptive models to the model Center workflows that we've already seen and specifically talking about model Center Missy we actually have two products that fit under this capability

19:51 and I'm just going to touch on those two very quickly the first one is what are our new product our latest product that is called model Center MEAC and we see the GUI here so this is the the latest of for our model center NBC initiative where we have essentially taken all the the feedback that we've heard throughout the years for our other application NBS CPAC and wrote this application from scratch

20:22 so that we're taking in and and building up in the the best way you know from the ground up from scratch so we see here in this GUI this is the interface for model Center in BSC this works by pulling in your systems model we can see certain highlights of that system structure and the top right we can bring in any analyses that we want to tied to those and we can also visualize or bring in

20:53 requirements as we need as seen in the bottom right also in the middle we have what we've started as execution plans where we can modify our our designs our value properties and then down in the very bottom pane in the center we see the requirements verification there so we have multiple requirements that were validating against some that are failed some of that passed so this is our new our newest and latest product and what

21:24 we've tried to do is incorporate some of the native behaviors that are already built into the system l tools and try to work with that without making too many modifications so hopefully this is a more flexible more intuitive more native integration for your NBIC applications moving to our second product our first product that we released about seven or eight years ago is M BSC pack so M BSC

21:55 pack solely relies on parametric diagrams as Jeff stated to make that connection between the systems descriptive model and the domain engineering here we see the GUI where we're able to change value properties bringing in those parametric diagrams bring in the value properties for those and then also running in a multitude of ways whether it's a single execution or running trade studies but also getting requirements verification here it's

22:28 probably good to note that MBA CPAC has the capability to be run natively in the SIS ml tool such as cameo or it can be run from model Center where we can pull in the project the system L project and and do all your engineering analyses directly in Model Center as well so really a preference on that of whether you're a systems engineer and you're looking to focus more in the system l and work directly in that tool and never

22:59 have to really see model Center just utilize its functionality or if you're more of a domain engineer working with the analyses but want to get all the context of your sysml project so that you're working from authoritative source of truth so moving forward here just going to quickly elaborate and kind of describe a little bit more of those engineering environments that I just touched on so the first one is what we

23:30 call the what we at Phoenix have kind of called the domain engineering side and that's where we're looking at engineering analyses things like mechanical electrical simulation cost manufacturing all those multiple disciplines tied into one to two to come up with some design whether it be conceptual or detailed or a much more higher fidelity than that so this is where model Center comes in we can integrate these all into a workflow as we saw in the last webinar

24:01 so you pick your tool of choice whether it's a cots tool a in-house code or legacy code of some sort and we can integrate those together so this is well established this is the the the go-to feature of model Center but what we realized a few years ago when we developed mbsu pact was it that there's a completely different engineering environment that we weren't paying attention to and that's the the system engineers so system engineers

24:34 using nvse tools such as cameo and I should point out that the language of these tools is known as sysml sysml has what is known as the four pillars of sysml requirement structure behavior and parametric's and those combined together make up the authoritative source of truth so everything that should be based off for a project for system should be coming from the requirements or the

25:05 structure or the behavior or parametric's of this system el model so at Phoenix what we decided to do is we decided that there need to be an integration between these two environments and we decided that we need to bridge the gap so we see here that we created a integration using model center MBS C or MBS C PAC I'm going to interchange those quite regularly but what that provided is a bi-directional integration between the domain domain

25:36 engineering side and the systems engineering side so that as I said before as a domain engineer you can access and have context to that authoritative source of truth and then on the flip side of that as a systems engineer you can have a descriptive model and but be able to validate it and run it against real physics based models like we're going to do here today so with MBS C PAC we have two use cases

26:08 that we have defined that we've noticed usually our customers fall into one or two categories some both the first one is going to be what we call requirement analysis and so that's the setup that we saw in Jeff's demo where we've we've included our requirements we've made that satisfy link what we're trying to do is to modify the value properties for our system l diagram execute the physics

26:38 bait models to determine if those value properties do actually satisfy the requirement and we can see here a quick snapshot on the left of the requirement analysis where we've modified some values in our m BSE analyzer view and we see a green checkmark showing that the requirement for that parameter has been satisfied so looking at use case B is what we call B hit and behavioral simulation I'm going to touch on that very briefly

27:10 essentially what we are looking to do here is to utilize the behavior diagrams so one of the the pillars of the of the sysml for pillars being behavior and so that we can actually utilize the behavior diagram set up in sysml and execute physics based models as your behavioral simulation is executing as well so i'm going to take a look at each of these first the requirement analysis

27:41 will we'll do a demo of the the second part of the demo that shows verifying those requirements that Jeff initially set up and then we'll touch very briefly on the behavioral simulation and show an interesting example of that being used so as I said for requirement analysis we're looking at the the four pillars of system L but in this case we're going to strike through behavior we're not going to focus on behavior right now we're only going to focus on the requirements

28:11 the structure and the parametric's with the parametric's but really being the key aspect of this that is the integration between the two engineering environments and all of this is still maintained as the authoritative source of truth so the first way that we do this as I said with a parametric diagram is we will map model Center workflows or engineering analyses in model center to constraint blocks in the parametric diagrams so we see here just a quick

28:42 little screenshot of a constraint block we see it has a external analysis stereotype this is one of the stereotypes that comes with the MBC and a lot of profile that's installed when you install MBA CPAC so putting this stereotype on this constraint block indicates to cameo or the sysml tool that this has an external analysis associated with it which is linked through model Center and it can

29:14 technically be any engineering analysis that you've integrated with model Center so that can be your CAD programs your your mat labs yours excels your SDKs all tied in through model Center into this external analysis constraint block and I will touch on in the demo on how we actually set some of that up so the second key piece of requirement analysis is the fact that we're able to execute

29:44 the work flow from Cameo or your system l tool of choice to validate requirements so Jeff touched on building that block definition diagram where we have our requirements and our structure for the value properties and we're tying those together with a satisfy link M BSC pack will interpret this diagram and use that to once an engineering analysis has been run to go through and check those satisfy requirements links to see if in

30:17 fact our requirement has been met or not and I should probably talk to on the fact that our requirements here also have an additional stereotype that's the property based requirement stereotype once again that it comes with the MBS C analyzer profile so adding that combination you know the stereotype with the property requirements to satisfy links to the your value properties enables MBS C pack to to read and validate those value properties to see

30:47 if they've met requirements so the third piece is the actual execution of your workflows or trade studies so as I said before this can be run either from the sysml tool or from model center in the systemö tool we call this in BSE and in Monell Center we call this the MBS C plugin so what we can do is we can change a single value property and hit

31:18 the Run button in a single time and get updated results by running the workflow behind the scenes or as shown here we have the option to run trade studies from the system L tool as well so in this case we've selected the do-e tool which is the same exact tool that we see in Model Center this pops up we can drag and drop value properties into the the GUI along with response variables select our design select number of runs and the

31:46 run button and we'll perform a design of experiments trade study all within our system L tool so lastly after we've executed our parametric diagram and this is the in BSC analyzer GUI here where we've we've loaded a parametric diagram we've modified our value properties we've hit the Run button we've gotten updated results as indicated by the up and down arrows for the in the new column that show whether an or in which

32:18 direction has our responses change we have two options from this point and that is to either save or save as we're save if we click the Save button we are actually overriding the current default value properties for our value properties for the in the system L model so if you do hit save you will be overriding those default conversely what we can do is hit the save as button and that will allow us to save instances of

32:48 this of these value properties so that if we're not overriding the default but we can easily refer back to them so without further ado I'm going to hop into the second part of the demo where we're going to kind of show more of the nuts and bolts of that constraint block and how we set it up and the the inner workings behind it so we'll start just at the parametric

33:20 diagram level looking at the constraint block you notice that we have ports as Jeff indicated inputs on the Left outputs on the right as we've set up we've clicked on and a port on the left-hand side which is a analysis variable since because this is has the external analysis stereotype and we see because of that we have certain parameters that we can set for it such as an input whether it has upper lower bound all these are feeding directly

33:47 from the model center model that this is tied to quickly looking at the right hand side for the outputs we can go and notice that this has the same tags with the direction being that it's an output and it has a default value as well so just to to iterate on what Jeff showed we have our model center workflow over

34:17 on the right and our Systema model over on the left and you notice there are there's a 1:1 mapping of the the engineering analysis over on the right which is a sensor design utility and the SDK component running the STK we can see that that here is the simulation of the the constellation but there is a one-to-one mapping between the sysml diagram and that workflow and that's actually because we're pointing through this constraint block through the

34:44 external analysis to that workflow so let's hop into M BFC analyzer so if we go into tools NBS the analyzer will pop up the splash screen for that from here you can do a multitude of things but one of the first things that we'd want to do is manage constraint block so this is how we bring in an external analysis into the system L tool so we've already had one set up here we'll click on it to

35:15 show that it does have those variables those inputs and outputs exposed here showing the inputs with the green arrow going in and the outputs with the blue arrow going out and you see it has an analysis description it has a URL there this is the way that we communicate between the the tools in the sense that when we run a parametric diagram it's actually running that analysis in that location over in Model Center so let's go ahead

35:45 and evaluate a design so we open up to the evaluate designs tab expand this out bring in our parametric diagram that we've previously set up expose all the the parameters or the value properties and you see here we have the ones for the the sensor field of view and all the sensor parameters but then we also have the constellation parameters as well such as number of planes some observer

36:16 satellites so hitting the Run button we see this takes off and will actually go and run the workflow behind the scenes we're seeing the the visualization of SDK building up those constellations and showing the time to revisit and the the resolution there in the diagram coming back to em BSC analyzer we see that we have two x's in the margin column next to the distance and the time to revisit what that indicates of course is that we

36:49 failed our requirements that we've set up using that satisfy link so in this case quite we failed quite a bit on the the distance and so forth with the the time get revisit and then hovering over these requirements we can see the tooltip that reminds us of what those requirements are in case we've forgotten so in order to make these valid and to pass our requirements we're going to

37:19 need to make some changes normally if you're not familiar with the system maybe you want to go run a trade study a do-e maybe even an optimization in this case we're very familiar with this workflow so we're going to go ahead and change the detector pitch and then decrease our I'm sorry increase the number Planes but since we've increased the number of points we're going to decrease the number of satellites per plane so by doing that we see the up arrow down

37:49 arrow indicating that we've decreased certain parameters and increased others meanwhile our requirements in the margin column have gone to unknown because we haven't executed this workflow again yet to see if we've met those requirements so using the the new values from those value properties we're going to run that workflow and actually see a new constellation pop up in this case we see that our time to revisit and the the field of view or the distance for

38:19 resolution are met graphically and we have an indication here that we have two green checkmarks so that we have successfully passed our requirements one little added benefit here is that we can click on the individual requirements give us a little bit more detail show us what the bounds are or were for for that requirement and showing that you know that we did meet that requirement we'll do the same thing with the the distance

38:51 response as well showing that we needed to be under 3000 and so that is it for the second part of the demo as promised I did indicate that I would be going through some of the behavioral simulation that's the second use case so I'm going to quickly touch on that and so what's key here is we're

39:23 going to focus on behavior but this will require the structure of the parametric's and the requirements as well we're just going to enable those to be run through a behavior simulation in Cameo so touching on some of the key points of that it's the same initial process here the first point that we made with requirement analysis we're going to do the same thing or it is a requisite for a behavioral simulation we'll need to map those workflows from

39:54 model Center to constraint blocks in the parametric diagram and of course all of that is done through model Center of the external analysis stereotype and we've already discussed that could be any any tool of choice if if you're familiar with executing behavior diagrams in cameo this is done with their product cameo cameo simulation toolkit and so this is a quick snippet of of one not being run but once we execute that we

40:25 would see animation moving from the left to the right going into the respective blocks these blocks may have greater detail underneath them that they'll go into further diagrams and then move on to the next block in a sequence until we've iterated however long the simulation should be so the key aspect of this where model Center and nbac tie-in is the fact that we can assign one of these blocks to actually run engineering analysis so we execute our

40:57 behavior simulation it runs in sequence through these blocks but in this case the one that we have highlighted here has a stereotype of call NBC analyzer behavior so what we've done is we've set this block up to point to the parametric diagram that we want to execute and so when the simulator and runs to that it gets that a diagram block it will actually execute the results feed them into a table and then move on with the simulation and then

41:30 when it rates back around it will iterate through that analysis once again until the simulation is done so as you can see here that block is tied to a pair much diagram which of course we've shown in the previous parts of this demo the constraint block of the pair much diagram is tied to a model Senate workflow which can be comprised of multiple systems such as ANSYS AGI Excel MATLAB and then lastly because we've run

42:01 a simulation what we're interested in doing there's a lot of data being moved around and and created is we would like to visualize those results so here we had the visualization from a one of our CubeSat examples where we see the red line is the Sun state so this is a state of property where we can be in the Sun or out of the Sun but when we're also tracking that we're tracking the energy consumption or the energy level of our

42:33 satellites so we can see that when we're in the Sun we're actually charging other processes may be going on that's why we're not seeing just a constant slope of a line going up at the beginning of the graph but then once we become out go out of the Sun or we go into an eclipse we see that we are energy level starts to degradation Eclipse and then once again we can start charging so it's these types of interactions that running

43:01 your your single analysis one time to do a requirement may not be you know fully comprehensive because we might have multiple interactions going on we're only a simulation like this and multiple simulations kind of linked together and visualized at one time can we actually see the results from those interacting so to prove this as we did in the last webinar and bring up a quick industry

43:31 example I'm not going to go through the entire example this is a recorded webinar on the Phoenix integration website you can see the URL here below but this is one provided by Airbus defence in space and is the application of federated and executed models mb SC process to Airbus orbital services missions so to translate that with a pretty picture we have two satellites here in this image the one over on the left is the active

44:04 satellite the one over on the right is the defunct satellite and the whole mission for Airbus was to to be able to service these satellites so whether that's to refuel or to potentially even deorbit that satellite so they want to model all this in in sysml tools and with model center so what that looked like from a high level is this is one of their slides where we see that they have a cameo system L model that describes a

44:37 logical architecture of of the system and of course that's just a very simplified view of it they also had some database tools that they were looking to integrate with and then some dynamic models but down on the bottom piece you can see is the the model center aspect where they are looking to analyze and validate the system so we see a little screenshot of a workflow tying together physical data and physical models getting some visualization as we move to

45:08 the right in the bottom you're getting visualization of that simulation and you know performing even things like sensitivity and optimization on this diving into the Cameo part of this or the descriptive side of this we can see here we have you know views of their internal internal block definition diagram we have their state machines and their activity diagrams all which are tied together as indicated by these blue arrows going every which way but if we

45:39 look to the the right side here we can see that you know they are executing activity diagrams and when they're at executing them they're actually calling that workflow that we discussed before that's integrating their tools and and getting updated results through the simulation and so a nice outcome of this is a very nice video that was done all through I believe through AGI and the the application of running the

46:09 simulation diagrams and so in this video we'll actually see the active satellite approaching the defunct satellite aligning to it and then and from there it can either pick its mission which that's where the the video will end but we see the act of satellite approaching the defunct satellites aligning itself getting itself in the correct axis

46:42 approaching further and then what we'll see is it actually matches the the spin of the defunct satellite and as I said all this is an outcome of integrating the you know descriptive models the behavioral simulations the parametric diagrams the structure the requirements in the descriptive side with the analysis capabilities of model Center and the physics based tools such as SDK

47:15 so with that that concludes my portion I'm gonna pass it back over to Jeff all right all right so thank you very much Joshua great examples and definitely really good way to highlight the the purpose of this webinar which is that physics infused descriptive models where you've got your cameo model and your mission model and SDK and your tie it

47:46 all together through model center and that really goes back to the vision of what we see when we talk about digital mission engineering and so going back to that original slide that we presented at the beginning of the webinar is the to connect all of the engineering and system models to the mission model that is rooted in a multi domain physics environment and having all the tools that are already integrated together from day one and having that organization-wide

48:13 ecosystem that you can quickly transition from program to program without having to rebuild custom tools or train new people on custom tools as they transfer programs and leave the organization is really beneficial and we talked about some of the benefits in previous webinars about the time it's that you can save by having these these tools all integrated and just to kind of recap where we've come so far on this webinar series and where we're going we

48:41 started off by building a representative demonstration starting early on in the program life cycle really starting at concept development applied to satellite constellation design and the first webinar we started by building out a mission model and SDK integrated with an Excel cost model using model Center and then ran those cost first performance trade studies and then we integrated that mission model with a sysml model and then validated requirements that had more details built into it for an earth

49:13 imaging use case and so the next and final webinar we're going to continue to build off of this example as we get into more the detail design phase and we're going to start getting into more high fidelity engineering simulation with ANSYS mechanical fluids and electronics so some really exciting demos coming up for that so I definitely would encourage everyone to to register for that webinar as well so this just has a few of the next steps for attending this after

49:43 attending this webinar as I mentioned the series finality series finale is coming up next week August 21st with SDK ANSYS and in Phoenix integration as well the three main areas were in look at is the thermal analysis for a spacecraft using SDKs soleus which is the spacecraft object library in SDK and an sis mechanical and so that's going to allow us to do some thermal analysis and and we also have communication analysis

50:14 with SDK communications and ANSYS electronics and their HF SS product and then we're also going to look at a notional hypersonic tracking system where we're tracking a hypersonic vehicle using that we built an SDK using aviator and EOIR combined with the CFD analysis that you can do within ANSYS fluids they're fluent product so that'll be a jam-packed webinar lots of great stuff looking forward to that if you

50:44 have any if you need any more information and questions from AGI or Phoenix integration I visit our websites or email us at those links provided we have a series of other upcoming events both on the AJ and Phoenix side on the AGI side some virtual trainees coming up over the next couple weeks and then on the the Phoenix side we've got a webinar coming up on September 10th MBS see in a model-based engineering environment presented by Lockheed space and then

51:14 there's on ongoing public trainings for Phoenix 4 on MDA O&M BSC so with that I think there's another final poll question and then we'll turn it over for questions okay thank you for everybody who answered that poll and as I read these questions to you guys remember that some of them probably came in before you went into a little bit more detail so it's okay to say hey we did cover that later in the presentation or

51:39 it's good to hear things twice for some people like myself so the first question was are these charts and video going to be available after the presentation and the answers yes they will be available and AJ comm / DME the previous webinars that had been mentioned a few times today are also up there so you can access them and catch up if you have not have not seen them are you guys ready for the questions yeah all right

52:05 so in the coverage requirements you should revisit times and image resolution but can you also show RF parameters such as e IRP yeah I could take that so so yeah the STK graphic even though it was part of Joshua's demo inside of SDK you can have multiple metrics that define your requirement so in that case what we showed was the white area was the revisit rates and so when you saw the

52:35 whole globe being white that meant that we satisfied that across the whole globe and then we had the image resolution rates within the sensor field of view which was indicated by the green the way we calculated that is we actually use what's called a figure of Merit object in SDK and there's many many options there's many built-in options for four different metrics that you might be interested in and and it really extends to the whole SDK ecosystem of of data

53:03 providers which includes all of the communications parameters like the e IRP or any other common parameters bit error rate carry a noise things like that thank you what if we have multiple parametric diagrams that require multiple tools so I can take that one so we in our demo did only include one parametric diagram if you were to build multiple parametric diagrams you can access those from the MEAC analyzer as

53:36 well you can place check marks to include some one or all of them and then executing those will execute the individual parametric behind the scenes in Model Center bringing all the results back and then of course each parametric diagram can have its own tools or share of tools or share blocks as well great how did you create the that satellite constellation model in Cameo so the the

54:10 the model that we used and I'm kind of chuckling because here we built that here at AGI we are not sysml experts by any stretch of the imagination so there's could be better ways to do it in this case what we did is we actually use one of the examples that was shipped with an M BSC analyzer which is a car break demo and so what we did is we kind of eyeballed that and then applied some

54:35 of the same concepts like multiplicity between the number of wheels and that example the number of satellites per plane in our example and we use that to construct the system all diagram but we just built it up from scratch in cameo and and hopefully it's pretty representative of how an actual sysml expert would it would build up that model alright so I keep in mind these came in at various times throughout the presentation so there might be they may

55:07 have already been answered right so your slideshow the authoritative source of truth as this is ML model is that your interpretation or the industry interpretation I can take this one so at Phoenix what we did is work with industry and with consultants in the industry to to come up with you know our our current implementation that's an BSC pack and MC m BSE so what we've used is what we've

55:40 seen in industry so when we say authoritative source of truth we're not saying that it's the only source of truth because with a lot of the the digital twin initiatives out there some may say that the the CAD tool should be in our opinion from what we've seen based off of industry is that both should be authoritative should be sources of truth but the sysml descriptive model should be the authoritative source of truth for for

56:11 your entire system trying to combine a couple of these because they ask similar sort of question the one that I see a couple different times is what if I have a different system l model tool system l tool other than Cameo so I can indle that one and is there a list of those available somewhere yes so I can try to repeat them very quickly but of course we can always find more information from people such as myself or on the phoenix

56:43 integration website for the NBS CPAC product it currently supports cameo / magic draw products or IBM rational Rhapsody for MCM BSU - just to recap which is the kind of next product that's coming out or that has come out so that is the the new main focus we've already integrated with with the no magic products we've also done PTC's

57:17 integrity model or windchill modeler and then the next one to be coming soon is of vitex genesis so if if that doesn't is that that's not on your list as far as your sis ml tool feel free to drop us a line we're always interested to hear what our customers are what potential customers are looking to use or what the industry uses so that we can work with those vendors and get an integration as

57:47 well great and if I don't have time for your question we will follow up with everyone individually if we don't have time or if the answer is too long to fit into this webinar alright so a question came in about the 2:30 mark and it says in this diagram we have a closed loop system is it possible to define new blocks I think you kind of went over that a little bit so I don't know exactly what chart was up that was doing

58:12 your portion Joshua yeah I'm not I'm not tracking which exact wall exactly diagram we're referring to but I can elaborate and say that yes in at least I'm gonna answer this and say that with the parametric diagram of course yes you can add more blocks so we only added one constraint block we I have seen and I have created parametric diagrams that have multiple blocks where a single analysis represents one block but we can tie those bonding connectors from

58:44 constraint block to another constraint block and so on and so forth as we need to pass data very similar to how model Center works and that's actually one of the reasons why model Center is able to to run these parametric diagrams is because the the setup with the inputs and outputs and the analyses is very similar to our methodology of how we execute workflows how do we know it's been satisfied by validated simulation analysis or both

59:15 can you repeat that yeah I think it came I think it was time to a specific question or a chart that was up it says how do we know it's been satisfied by a validated simulation analysis or both take a stab at this one yeah well and I'm gonna say both so we are running models behind the scenes in Monell Center we have to have some faith in those models and we visually saw the representation of that with the SDK

59:44 constellation we could visually see the mapping of the globe and then of course with the analytical results you know producing numbers back and going against those requirements verifications you know we get those green check marks to show that the the answer to that model or the output to that model is it did meet our requirements is inside the bounds okay thank you how do you ensure consistency between the sysml model and

60:16 the system representation within the external analysis especially for larger scale systems that need mdo and where it is not feasible to model all parameters in sysml that's a very good question so try to take this one step at a time from from my experience you would want to model your behavior or I'm sorry your your your project or your system I kind

60:49 of take it as a higher granularity first and kind of get the the elements of your system that you find interesting I get that a lot of these analytical tools do produce a lot of data have a lot of parameters for instance CAD tools may have you know our CAD programs may have a multitude of parameters exposed to them I think it's it's important to there are identify which ones are the key which ones you might be wanting to

61:19 change so almost doing a sensitivity summary to determine which ones are impactful to your design change and then taking essentially baby steps of going from a high granularity to model those and then slowly working in and getting greater detail into into your model to possibly even describe the entire system I think I may have answered that fully I'm kind of lost track of what the question was about halfway well you know if we if you

61:51 still have questions afterwards be sure to follow up with everybody who had one and if we don't that's why the first time around we'll we can iterate on on the line of questioning with you there we talked about there's going to be you will provide you if you asked for a list of standard tools integration tools that you can use other than one shown the webinars like we said they're still they're going to be available on hom /d

62:14 MA the previous ones as well as this one there any examples that use real time to drive real time executed models for example PIL or HIO I don't think we have any of those examples here today but we can dig into that and follow up with you with that question and there's no question about what steps are involved in adding components and analysis I think that's another one we'll take offline because there's probably that's probably a larger discussion than going

62:42 through here unless you guys have a quick version of that I think taking that off yeah it's a whole conversation in and of itself there's SDK consider the radiation pressure on the satellites surface I think that probably means solar radiation pressure yeah I would I would think so too and the answer is yes so what you can do is you can model the solar radiation pressure and is it if impacts the drag on a satellite for

63:09 example and so you can model the there's a variety of ways there's modeling that you can either use the the built-in models of the SDK they're kind of simple and standard as a general surface area and coefficient of drag or you can do higher fidelity simulations where you have a a plugin script that's that has a changing surface area exposed to the Sun but but in general yes Dan yes you can consider radiation pressure on your satellite surface an SDK

63:38 great okay I think that's it do you guys have anything else to add any other questions we're we're here for another 30 seconds or so no I think that's all so I just wanted to thank again Joshua for joining us from Phoenix and the courage every thank you everyone for for joining today's webinar and there was a question about finding the previous webinars those are up on Adriatic homicides DME and you can also register for the last one and tell your friends

64:06 about it so thanks for everyone for joining yep thank you thanks everybody so long you