Mission Engineering, Radar, and Communications: A Compelling Combination - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 36:47
Loaded: 0.45%
Stream Type LIVE
Remaining Time 36:47
 
1x
  • descriptions off, selected
  • en (Main), selected
    Video length is 36:47

    Mission Engineering, Radar, and Communications: A Compelling Combination

    Overview

    As missions become more complex, organizations require effective methods for simulation, tradeoff analysis, and design activities.  Mission engineering has emerged as an analytical and data-driven approach to break down and analyze mission components, identifying measurable trade-offs and drawing conclusions.  This approach emphasizes the need for digital continuity across design phases and levels of abstraction, enabling collaboration among teams and organizations.  In this session, we discuss how mission engineering through a unified environment for modeling and simulation can enable faster and more cost-effective tech insertion.

    Through the lens of a search and rescue mission, we will showcase how to define problem spaces for missions involving systems of systems, highlighting communication links, radar system performance, and environmental factors that impact RF propagation.  Additionally, participants will learn how to conduct mission planning analysis to identify and understand lower level performance measures, consider constraints, optimize choices, validate assumptions, and accelerate the readiness of requirements, models, and testing environments.

    Highlights

    In this session, you will learn how to:

    • Specify the interfaces and interactions of a mission before specifying the underlying system behaviors
    • Insert radar and communications models of varying fidelity into the overall mission model, and assess the impacts of those fidelity levels
    • Visualize the evolving mission to assess measures of success
    • Visualize the performance of the underlying radar and communications systems

    About the Presenter

    Steve Ajemian is a Technical Account Manager for the MathWorks supporting Aerospace and Defense customers in the United States.

    Prior to joining MathWorks in 2020, Steve has supported the DoD for over 18 years, most recently for the MITRE Corporation. At MITRE, he provided subject-matter expertise in wireless communications and networking to DoD customers and lead projects supporting technology acquisition of tactical datalinks for the US Navy. Steve holds a BS and MS in EE from the Johns Hopkins University and an MS in Engineering Management from MIT. 

    Recorded: 20 Mar 2024

    All right, well, welcome, everybody, to our talk today. We're going to be presenting on mission engineering with MATLAB and Simulink. Excited for today's webinar.

    My name is Steve Ajemian. I'm a technical account manager with The MathWorks, supporting our aerospace and defense customers. Prior to The MathWorks, spent over a decade at the Miter Corporation, working a number of different tactical data link initiatives and platform integration activities across the services. Joined today by my colleague, Sam Lehman. Sam, how are we doing today?

    Doing great. Thanks, Steve. So hey, everyone. My name is Sam Lehman. I'm also an application engineer at MathWorks. I've been with MathWorks for about two years now. Prior to that, I worked at Boeing doing contracting for the Army and the Navy.

    Awesome. Thanks, Sam. OK, so just a high-level agenda we're going to step through today. Going to introduce mission engineering as an analysis workflow. And going to spend a lot of time talking about a search and rescue mission that we put together, just to highlight the analysis framework in our tools.

    And then we'll get into how we've actually implemented the model under the hood and show you some highlights from the demo and the tools. But before we do that, just wanted to lead off with exactly what our demo is going to do today.

    So I mentioned the search and rescue mission. So basically the progression is we've got some distress personnel that go down somewhere in our location. It's outside of Boston Harbor. So we have a rough idea of where these personnel are, but we've got to do an actual search to locate the life raft that they're in.

    And to do that, what we're going to do is task a rescue vehicle-- in this case, a boat-- that's performing a radar sweep to try to locate this life raft. And so we've got a rough idea of where they are, so we've got to execute a lawn mower search pattern, which is something that we've implemented in our scenario here.

    And what'll happen is the radar will start generating detections, and we'll convert those to tracks. And once we've identified the location, we'll motor towards the lifeboat. And once we get within a close proximity, we're going to launch a UAV to maintain positive visual identification.

    And basically what we're doing is we're measuring the time it takes for this recovery operation, which is going to allow us to vary the radar power that we're trying to evaluate here to see if we can right-size that radar performance to really maximize how well we can perform our mission, where really our top-level metric is how long it takes to recover these personnel.

    So I just wanted to give you a little introduction of the demo. And then we'll get into more detail on how exactly it's implemented under the hood.

    And just some example outputs from this analysis. So I mentioned that we wanted to be able to sweep our radar power. And so we've got range down here on the x-axis, which is a proxy for our radar power. And what we're plotting on the y-axis is how long it takes to recover these personnel.

    And really, the key takeaway from this type of analysis is being able to sweep performance parameters at a lower level and see how they impact these higher-level mission metrics. So really what we're trying to tease out is where do I get the most bang for my buck, or where is the elbow of the curve.

    So we can start to see that the rescue time pretty much levels off right as we increase power beyond, say, 10 to 15 kilometers. So you can start to see where those diminishing returns are.

    And then for mission engineering, you want to be able to do Monte Carlo analysis, a batch of runs for a given set of input conditions. This box plot on the right is just showing some rolled up summary statistics for our Monte Carlo simulation of this search and rescue mission, where these box plots are capturing min/max and median for our rescue time. And intent here is just to show some example visualizations that are outputs from this analysis.

    So let's just introduce mission engineering as an analysis framework. And before we do that, just want to start off with just a word on our digital engineering capabilities. So what we're showing here is an end-to-end mapping of our capabilities to a digital engineering workflow, starting on the left-hand side with requirements.

    So we've absolutely got the ability to import requirements from a number of different sources. That could be Word, Excel, DOORS, DOORS next-gen. But really, the intent here is to pull requirements into our environment, where you can start linking them to architecture components and lower level implementation behavior.

    So if you're looking to capture your system architecture, you can actually do that in our System Composer tool and elaborate on that architecture by implementing actual design models under these components. From there, you can leverage Simulink for your behavioral modeling, perform algorithm development, or physical simulation in our Simscape tool. And we've got a number of capabilities for scenario visualization. We showed you just an example of that with the view of Boston Harbor, where our scenario takes place.

    And we've also got the ability to generate code from Simulink models. So that is providing the capability to generate C code to potentially target an embedded processor, or HDL code to target your FPGA devices or RFSoCs. And we've got a number of capabilities for controlling test instrumentation in our Instrument Control toolbox, as well as capabilities for working with software-defined radios.

    So if you've got virtual scenarios in the lab, we've got a lot of capabilities within Wireless Testbench to do spectrum monitoring, over-the-air data capture of RF signals. And that product works exclusively with the NI USRP family of radios. So a number of capabilities where working with actual hardware can augment your mission engineering analyses.

    And then for system integration and test, just want to mention our comprehensive set of verification and validation capabilities. We're not going to get into those today, but just know that they exist and can be very useful in enabling a digital engineering workflow, particularly for your test-driven development or continuous testing activities to really get at that early verification.

    So historically, this digital engineering workflow with our customers has been practiced at the system or component level. But we are absolutely working with customers to extend this to system of systems applications as well as mission applications.

    And as you navigate up and down this pyramid, you've got some trade-offs to make. Typically, you're evaluating how do I model my system at the appropriate level of abstraction. And so some of the trade-offs you're making are what's the right amount of fidelity to answer the technical questions I got to answer in a modeling and simulation activity. And that's where you're trading off the aggregation and the scope of what you're trying to analyze.

    And what I mean by that is at the component level, you're probably looking at a higher level of fidelity. But when you start pulling in multiple systems for these mission-level or system of systems-level analysis, we've got to abstract out some of that complexity. And you can absolutely do that in our tools

    And then I guess related is at each level of this pyramid, you've got different sets of stakeholders, starting with the top level, your deciders. Maybe you've got a mission commander communicating commander's intent, which gets derived into requirements for systems that we've got to go acquire.

    And that's where your integrators, your program offices come in to perform that requirements derivation and figure out where are my capability gaps that I've got to close with new capability. And then your systems engineers, program managers in charge with developing these systems, continually characterizing system performance and performing those system-level optimizations as the design matures.

    And at the engineering or developer level, some of the key perspectives, concerns, are all right, how are we actually going to implement the complexity of our system in a modeling environment. And how are we going to collaborate? How are we going to communicate our design? And that's where model-based activities, that authoritative source of truth, can be a really effective mechanism for enabling that collaboration.

    So I'm just going to introduce System Composer. I mentioned it earlier. Just want to highlight some of the capabilities. And Sam's going to show it in the tool when we head over to our search and rescue demo.

    But fundamentally, what System Composer aims to do is capture your architecture, so the ability to compose an architecture. In this case, we've got our constituent platforms of our search and rescue mission.

    And you've got some flexibility here to create different types of architecture views. So you can think of functional, physical, logical views, and create allocations between components of these different architecture views to, for instance, allocate a particular function to a number of different physical components in an architecture and visualize those allocations.

    Defining interfaces-- this is a nice capability. So being able to define the interactions between components of your architecture. And what's nice about the interface definition in System Composer is the ability to flow that definition down to Simulink for actual implementation, once you've elaborated sufficiently on your top-level architecture, where you're ready to take that next step to implement the component behavior.

    And just want to mention a construct we leveraged from SysML is the ability to create profiles and stereotypes. So these are different attributes you want to provide your model to give visibility into performance attributes of your system that might not be reflected in the model.

    And what I mean by that is take, for example, size, weight, and power, being able to allocate values for weight across different components of your architecture and then perform analysis, so roll-up analysis. How am I doing against my weight budget? I can evaluate these stereotype properties across my architecture through MATLAB scripts to get that heading check on how I'm doing against my, in this case, weight budget.

    But that could be a power budget. You could look at latency across a number of different hops in a network, if that's what you've got captured in your system architecture. But really, the key capability here is being able to perform analysis of these attributes through MATLAB. So at that point, you've got the whole power of the MATLAB language at your disposal to perform analysis on the underlying architecture.

    So just some context on our search and rescue mission before we head over to the tools. Just want to provide some context here. So as we develop this demo, just wanted to call out the mission engineering guide. So this was actually recently updated back in the fall. This is an excellent resource for laying out the mission engineering analysis framework in a way that's really tailorable to what you're trying to do.

    But fundamentally, what mission engineering is intended to do is inform decision-making. How do we steer investment decisions to the highest priority capabilities? Acquisition decisions-- so maybe OK, we've funded a certain capability, but we need to accelerate that timeline because we've done some analysis that suggests we need this capability a couple years earlier than projected.

    And one of the nice things also is the ability to derive performance requirements of these systems. By evaluating capabilities within the context of a mission, it can really help you bound the performance requirements of these systems that you got to go put on contract and build.

    So this is an excellent resource. The slides will be disseminated, and there's a link to it. But if you just Google "mission engineering guide," you should be able to grab the latest version.

    And within this guide, they lay out a process flow. So just a high-level representation of what that mission engineering process looks like. So you've got really the problem or the question to be answered, and then the mission characterization. That's laying out all the assumptions that you intend to use as the basis for evaluation.

    And most importantly, includes the mission metrics that you're going to actually measure in your scenarios to score how well you're doing in a given set of input conditions and input architectures. And then you go into really the analysis phase, which is fundamentally an iterative workflow, where you're looking at oftentimes a baseline architecture and an alternative architecture.

    And this is where you can start to do that gap analysis to figure out, OK, here's what's missing, here's what's preventing me from executing my mission effectively. We've got to go close this gap with some new capability that we got to go acquire.

    So that's where the guide introduces terminology like baseline architectures, alternative architectures, and some additional terms that it introduces. I'd encourage you to check out the guide, but mission engineering thread, mission thread, these are just laying out really the sequence of events in the analysis.

    And then you'll run your analysis. This could be parameter sweep, sensitivity analysis, Monte Carlo runs. Basically hit and run and evaluating the performance of your architecture against those mission metrics. And we'll get into kind of the outputs of the mission engineering analysis. We've got a number of capabilities for report generation that we'll come back to

    So yeah, just to set up some context for the search and rescue mission. Mentioned this earlier, I believe, but really, we're trying to right-size the radar power on our search boat to conduct the search of the rescue vehicle. And we also want it to be able to evaluate our comms requirements. How much range do I need in this mission for my comm system? So just some example performance attributes that we want to go analyze.

    And the basic sequence of events-- we've got an emergency beacon that's going to kick off the start of the scenario. The person will go down. They initiate that beacon. Command center hears the beacon and tasks some assets to go perform the rescue. And that's primarily conducted by our search boat that's going to execute the lawnmower search pattern and then the UAV for the positive ID once they're located. And really what we're trying to do is measure that timeline.

    So our alternative mission in this case was just augmented with the UAV. What does that bias operationally in terms of hitting our mission metrics?

    So just additional characterization. This is a few years out, 2027 time frame, open ocean and our constituent platforms. We've got our search boat, UAV, and command center, our downed personnel. And that rescue beacon is initiated over a satcom shot back to the command center. And that's going to kick off our scenario.

    And just some additional information on the mission metrics that we're evaluating. So our top-level measure-- did we recover the personnel or not? But what we're going to do is decompose that to a number of measures of effectiveness which represent the timeline of events to go perform that rescue operation.

    And then additionally, a communications availability target that we're trying to evaluate. How effective were our comms over the tactical distances we were trying to achieve? And our lower level measures of performance.

    This "obtain precise location," this is where we're really going to focus in on the analysis today to figure out really what does our radar power need to be to effectively accomplish our rescue operation.

    So here's just a functional architecture that we've captured in System Composer to highlight the mission thread. We've basically covered this. Just starts off with that distress signal and the tasking of rescue assets. And this is some terminology that's laid out in the mission engineering guide.

    And then the mission engineering thread, you can think of that as assigning those functions to individual platforms. So this is just context for our analysis here.

    So this is my cue to throw it to Sam. Sam, would you mind pulling up the model, and we'll get into how we've got things implemented?

    Yeah, definitely. Thanks so much, Steve. So I'll go ahead and grab the screen here from you, and we can jump right in. So we saw the beginning a little bit about how this was actually run and kind of what the dynamic analysis looked like.

    So this is the model we've put together. Steve already briefly mentioned System Composer, and that's the tool we're using to design this mission architecture that we have right here.

    So first thing I want to call out is you remember from the slides that Steve just showed what the kind of platforms that we are interested in viewing are during this mission simulation. So if we jump back into that slide, we can see here we have downed personnel, satellite, command center, search boat, and UAV. Those map directly to five of these components that we have here in System Composer.

    So hopefully you can see them pretty clearly. They're the ones outlined in black lines with the images on them that correspond to those images from the slides that we saw before.

    You can also see, as Steve mentioned, there's some interfaces that we've defined between each of these different components. You notice a few other components that are kind of hanging out in this architecture model as well. So we'll get to what those are next.

    So first off, I will chat briefly about these three components here. And this is where we're modeling that comm system that Steve mentioned. So how frequently are we able to successfully pass messages between our constituent platforms and successfully communicate information?

    We need the comm system to be up and running and able to handle the distances over which this mission is taking place to be able to successfully complete the mission in a lot of cases. So we'll get to how those are implemented in just a little bit.

    The final couple components you see here are just kind of our broad mission configuration components. So one is a data store this keeps track of all the ground truth information. This is things like our platform positions, platform velocities, acceleration, orientation, environmental characteristics. So our ground personnel, they're actually drifting, so the drift speed, the drift direction, all that good stuff.

    And then it also takes care of that nice visualization you saw. So we can actually pop that open and kind take a look at what that looks like here. You'll notice it's a 3D globe that we can kind of zoom in and sweep around on.

    We can see this blue oval. That's the radar coverage that we have on our search boat. We can see the UAV successfully launched and performed in orbit. Did a situational awareness assessment there. And there is our command center off in the distance. So you can see all this stuff really nicely and clearly from those two kind of environmental and mission control blocks that we have set up in here.

    So now I'm going to jump down into kind of what's going on here specifically to simulate all of these different pieces of this mission. So first thing I'm going to do is jump down to the search boat right here. And we're going to talk about a few different pieces of this here.

    We will start with the platform team logic. So that's this block right here in the middle. This is the dynamic model of the search boat that we're actually looking at. So we'll jump in and kind take a take a peek at that in just a second.

    The other two components here, this is just how messages are passed around, so communications in and communications out, and we'll take a look at that in just a second. This format is how all of these platforms inside our scenario here work. So this is kind of a uniform structure that we hope makes it easy to use drag-and-drop new platforms into your scenario, your mission that you're hoping to simulate.

    Let's jump down inside the boat and see what kind of pieces are there in here that we're looking to simulate. So you'll notice two things. One, we have a radar sensor put together here on the bottom. We'll talk more about that in just a second. And then over here on the right, we have a platform dynamics and control block. So this is where the boat's actually moving around. It controls what stage of the mission the boat is in. And we'll take a look down in here to see what that looks like.

    So I've popped open a tool called Stateflow here. This is a state machine modeling tool based in Simulink in MATLAB. So you can see here, there's a whole bunch of different states that our boat can be in. When it first enters the mission and the mission starts, it starts in the standby state. We haven't received any messages that let us know that there are people who are waiting to be rescued yet. So it's just kind of waiting in port.

    Once it receives a message from the command center that someone is in need of being rescued and this boat needs to go out and perform a search, it'll then shift to the drive to location state, and it'll enter the searching state right here. So it'll perform that lawnmower search pattern that Steve was talking about that we configured.

    We can take a peek at what that looks like here. We'll notice here we can see we drive out to our kind of last known location, and then we follow this lawnmower search pattern until we found our downed personnel. Now once we've actually found the downed personnel and we have a track, we'll move to this found state, and then we'll actually start driving towards the downed personnel.

    And you can see in this top-level kind of illustration here exactly where that occurs. At this point right here, we deviate from our kind of pre-planned search pattern, and we start driving towards the downed personnel.

    Once we've gotten close enough, we'll launch the UAV, so we'll reach the deploy UAV state. We'll wait for it to complete its kind of situational awareness assessment, get a visual ID of the people we're trying to rescue. And then finally, we'll report back to the command center that our search is complete. We have successfully found and rescued these people. We're able to come back to shore now.

    So that's kind of how we'll walk through each individual step of the mission here. And all the time, we'll be passing messages back and forth to the command center and the UAV, all the other platforms in this scenario.

    So next I'm going to take a look at how we transition from this searching to found state. How do we model our radar system that's going on here? Well, I'm going to jump back up to the search boat right here and look at the radar.

    So this is the radar block. I know there's a bunch of stuff in here, but we'll kind of focus most specifically on this block right here. These are really just more doing some coordinate transforms, making sure we understand the geometry of the scenario.

    So if we jump in here, we can see a couple blocks that are going to be important. This fusion radar sensor here, this is our actual radar sensor that we're using. And it's not a waveform level radar sensor. Instead, what it uses is a variety of configurations, up here in the Measurements panel here when we look at this, to determine what are some of the kind of top-level system requirements of our radar system.

    So in here, for instance, you can see we have our azimuth, elevation, and range resolution, bias fractions, things like what our detection probability is, our false alarm rate, reference target range, radar cross-section for our target, all this good stuff that helps make this statistical model of a radar sensor match what your real radar system is going to look at.

    And so the way this really works is with respect to some sort of specified reference range with a specified radar cross-section, what is the probability of detection for that target at that range? And then if the target is further away or it's smaller, the probability of detection goes down. And if it's closer or bigger, the probability of detection goes up right.

    And then we basically roll a die and see if we actually have detected that target. And then we can apply some noise based on the settings of our radar system here to that detection and feed that into a tracker. So it's a really nice way to simulate a radar system effectively and quickly when we're running an hours-long mission like this.

    Hey, Sam?

    Yeah?

    Got a question for you. So yeah, radar sensor's nice. What about other types of sensors? So take, for example, a passive sensing application. Is that something that you might be able to do in our tools?

    Yeah. That's a great question, Steve, and absolutely we can. So this radar sensor that I've got here, you can actually call it an RF sensor if you like because it can be configured to change to an ESM, electronic support measures, mode.

    So instead of doing active sensing, bouncing a signal off our target, we can give our target some sort of RF emitter on them, whether that be a comm system or a radar system, and then just listen and generate kind of passive detections there. So angle only, kind of angle of arrival detections.

    There's also other sensors like LiDAR, infrared sensors, sonar sensors, and kind of a variety of others to choose from. So if this isn't the exact sensor you're hoping to look or work with, we can absolutely talk about how to incorporate other sensor models.

    Awesome. Thanks.

    Yeah, absolutely. So the final piece of this here, we can look at this tracker that we have going on here. So we take a whole bunch of detections, and we can fuse them together to actually form a track of this object.

    And once we get that track out and we get a location of that track, that's when we transition to that, OK, let's drive towards the downed personnel. Let's actually go over and rescue them. So that's kind of the full way we get from just trying to search with our radar system all the way to OK, we found something, and now let's drive over towards it.

    So next thing I want to jump into is the communications piece of this. So as I mentioned, there is a comms in and a comms out block here. These are written using SimEvents, which is a discrete event simulation software written in Simulink.

    And so what SimEvents allows us to do is pass around discrete packets of messages. This can include commands like help, I need help, I need to be rescued. So that's going to go from the downed personnel to the satellite to the command center. It could be other messages, too, like, OK, we're ready to deploy, or we have successfully found the downed personnel. So all those are kind of messages that we've configured in here. You can add more of your own if you're interested as well for sensor data, stuff like that.

    So let's take a look at kind of how we've done and modeled some of this message passing here. So as I said, out of that Stateflow chart we looked at earlier, discrete message events will come out. And they will enter one of these impaired RF environments. So you'll notice there's a couple of different ones because we have a couple different kinds of links that we're trying to model.

    In here, for instance, we have messages from our UAV, from our boat, and from our command center, all coming into the same line-of-sight link. We then check, and we apply some channel impairments, and we'll talk about those a little bit more in just a second. And then coming out the backside, we'll get the messages distributed to their targets, to the receivers that are looking for them.

    So I'm going to jump into the comms loss calculations here and kind of show you what this looks like. If we jump down in here, what we'll see is not really a high-fidelity channel model, but instead, something that's, again, probabilistic, similar to how the radar performed.

    So again, we don't want to do waveform level simulation here because the time steps would be super short. It would be very computationally intensive to do an hours-long mission simulation. So this is how we've incorporated a way for a communications channel model.

    And really what we do is we have this lookup table here. It's got along the x-axis, this is the range between our two platforms, our sender and our receiver. And based on that range, we determine, well, what's the probability of dropping a packet? So this is what that probability is. Up here is 1. We are definitely going to drop the packet. Down here is 0. We are definitely going to let the packet through.

    And then this is around I think 300 kilometers right here, where we kind of reach that edge point, where we're going to drop more packets than not. So that's kind of really where we see a drop-off in the performance of our communication system.

    Hey, so Sam, question for you. How did you generate the lookup table?

    Yeah, that's a great question, Steve. So I'll jump over to another model we have now. And this is actually informed by a high-fidelity, or higher fidelity, anyway, waveform level communication system model. You can see here this is written in Simulink as well, and we're generating some packets over here.

    We're doing some encoding, modulation, applying some RF impairments with our power amplifier, amplifying the signal, passing it through free space, our channel model, and then kind of doing all the reverse of that transmit chain on the receive side.

    And really what we've done is we've run this model for a variety of different distances. We've swept from 0 kilometers all the way up to, I think, right around 500 kilometers and seen what our packet error rate looks like over that sweep of distances there. So we get a really nice idea of what are the chances that we're going to drop packets.

    OK, so for this lookup table, could you do, say, multiple lookup tables, where you maybe got different types of RF environments that the system's operating in?

    Yeah, absolutely. There's no reason this just needs to be a one-dimensional lookup table. If you have things like weather effects going on, different velocities that actually may come into play, and you want to simulate Doppler kind of impairments, frequency shift impairments, other things going on in the environment, you can absolutely build this out to be more complex and more representative of your actual environment that you expect to be operating in. So that's 100% a viable way to go.

    OK. And so as long as I've got-- so let's say I've got another comms model and some other tool. If I can generate a similar lookup table output of packet error rate as a function of range, you ought to be able to swap it into to this model, right?

    Yeah, I think that's absolutely right. So this is just coming in as a MATLAB variable here. Sorry, pop this one open. This is just coming in as a MATLAB variable. So as long as you can get it into MATLAB, and you can get just about anything you want to into MATLAB, it's going to be useful here.

    So that could be something from a Simulink model, another tool. It could be empirically measured stuff. It could be from a data sheet. Wherever you get that from, whatever's going to give you the most representative performance of your system, you can pull it in from there and then use it here to inform the comms model.

    Cool. Thank you.

    Yeah, absolutely. So the final piece I want to talk about is the other-- we jump back to the top here-- the other link that we have going on. So you might be asking, OK, well, we've talked about the line-of-sight link that we have here. What about the satellite link, and how does the distress personnel, how do they-- or the downed personnel-- how do they communicate with the satellite? How does the satellite communicate back to the command center?

    Well, for that we've used the Satellite Scenario in MATLAB, which is a really nice tool for analyzing satellite communications scenarios. So we have a constellation of satellites here that we're using. We can see down here on the bottom, we have downed personnel that we are interested in being able to receive a message from and then relay that to a satellite back down to the ground station.

    So we've confirmed that we do have consistent coverage throughout the duration of our mission, using this Satellite Scenario. And we can see if I click play here, we have a nice idea of which satellites in my constellation are able to close a link-- that's what this green line means-- with the downed personnel. And just be sure that we can actually push messages through and get those relayed to the command center.

    So again, you can see that we do have access, we do have closed links with multiple satellites throughout the duration of this mission here. So just a really nice, tight way to confirm that we're going to see the performance that we expect to see, and we're going to be able to receive these kind of "oh, my gosh, I need to be rescued" messages.

    So again, just to tie this all back together, the things we just talked about. We talked about using System Composer to define some of our components. We saw how to use Stateflow to be the brains of some of these platforms that we have here. That passes messages in and out using SimEvents, so that discrete event message simulation tool.

    So we're not doing that at the waveform level here. But our mission model is informed by a waveform-level model of a communication system that we've developed using Simulink.

    We also saw how the radar and tracker were put together using those statistical-level radar models and other kinds of sensor models built into the MATLAB tools. They give us a really nice approximation of the way our radar system is going to perform. And we can even visualize what our radar system's coverage is going to look like.

    And then finally, we saw that we can use the Satellite Scenario to do some analysis of this beyond-line-of-sight shot, this satcom link that we're using to actually first find out that our downed personnel are in need of rescue. So really nice, tight workflow to incorporate all of these different pieces and get a good idea of what the outcome of our mission is going to be.

    And just to flash that back up on screen here, these are the kind of results we want. So we're not just going to run this once. We want to do some sort of parameter sweep or Monte Carlo analysis to be able to determine what kinds of requirements do I need for my radar system, for instance.

    So sweeping that reference radar range or the maximum radar range, that stuff, that's the good stuff that's going to lead to these kind of results right here. So Steve, I will pass this back off to you now for kind of closing remarks.

    Thank you, sir. OK, so yeah, just to kind of wrap up here. What we're showing here is just a high-level analysis workflow and just a mapping of some of the capabilities we highlighted in the demonstration.

    And just a word on report generation. So in addition to the visualization capabilities that you have access to within MATLAB, a number of capabilities for automating that generation of artifacts. That could be PDF, Word, PowerPoint, but the ability to export to file summarizing your analysis and disseminating that to stakeholders.

    And then additionally, the ability to export back to, say, a government reference architecture. So going from System Composer to SysML, there is a path to do that through XMI. If that interchange is something you're interested in, absolutely reach out and get ahold of us. We can work with you to facilitate that interchange through XMI. But that'll provide the ability to go back and forth between the SysML tools and System Composer.

    And then just a word on third-party interoperability. We've got open APIs. If your tool of choice has open APIs, there ought to be a be a path to interoperate with the MathWorks tools. We'd love for you to just live in our tools, but I understand that that's not realistic.

    And so just a few call-outs here. So with mission engineering, oftentimes distributed simulation is a common use case. So we've got DDS block set for distributed simulation, as well as an add-on support package we can make available for distributed interactive simulation, support for interfacing to external programming languages-- C, C++, Python.

    So take the case of you've got a deep learning network built in Python. You've got some algorithm that you want to be able to evaluate in a mission context. We can absolutely pull that into our environment for additional analysis. So just a couple of highlights there. If any of these are of interest to you, again, reach out, and we're happy to chat more.

    So yeah, just to summarize. Showed a number of capabilities for how our tools can enable mission engineering analyzes, which is fundamentally about providing decision support, informing decision-making on capabilities, performance requirements. And some of the key techniques there are those optimizations, parameter sweeps, visualization, data visualization, scenario visualization. Again, key components of mission engineering as well.

    But fundamentally we want to be able to look at those lower level performance attributes, see how they move the needle on our top-level mission metrics. And so to that end, we highlighted the radar power example, the ability to evaluate communication systems, and how evaluating them in a mission context can help you derive performance requirements.

    So we've got a rich set of capabilities, whether you're doing radar, comms modeling, other sensor types that Sam had mentioned. Autonomy algorithms-- we've got a lot of capabilities in our tools to really represent those multi-domain applications. And third-party interoperability is certainly a point of emphasis for us here, so any tool interchange you're looking to do, happy to work with you on that. But there ought to be a path for that.

    Thanks again, everyone, for your participation and attendance today. We certainly appreciate the opportunity to share any of these topics with you. So thanks again.

    View more related videos