Modeling and simulation development for space system design, integration, and testing – with Redwire Space

Episode 19 of the Space Industry podcast is a discussion with Redwire Space on modeling and simulation design in space missions.

Contents

• Episode show notes
• Redwire Space’s product portfolio
• Transcript

---

Episode show notes

In this episode we speak with Chad Meskimen of Redwire Space on criteria and practices that engineers need to consider with regard to modeling and simulation design in space missions. Redwire is a space infrastructure company headquartered in Jacksonville, Florida, and works with companies around the world on missions at a variety of scales. In the episode we discuss:

• The value of open architecture and common standards in space mission simulation
• How and when engineers should think about the modeling stage of a mission
• Redwire’s Advanced Configurable Open-system Research Network (ACORN) system
• The future for reconfigurable system design and open architecture modeling in space

You can find out more about ACORN’s use in this video, referenced in the podcast.

---

The product portfolio of Redwire Space

---

Episode transcript

Hi, everyone, welcome to the episode. Today I’m joined by Chad Meskimen from Redwire Space. Redwire is a space infrastructure company headquartered in Jacksonville, Florida.

Chad is Product Manager of Redwire’s Advanced Configurable Open System Research Network or ACORN. And today we’re going to discuss this system as well as modelling and simulation development in space missions more generally.

Firstly, Chad, welcome to the podcast and thank you for being with us today. Is there anything you’d like to add to that introduction about yourself for Redwire?

Hywel, thanks for that introduction. And I think you covered it pretty well. So we’ll go ahead, let’s go and dive in here.

Excellent. Okay, so modelling and simulation development in space missions, in system design, integration and testing processes at all levels, is a really important part of the engineering practices that teams all over the world carry out and software obviously plays a huge role in there.

So in your view, what do you think the main gaps are in modelling and software simulation capabilities, particularly for NewSpace missions today?

I think the single largest gap in modelling and simulation software capability for new space missions is the lack of standards and interoperability. There’s a number of available simulation tools out there, but a lot of them are tied to a specific bus configuration or flight software, or they only focus on a single phase and mission planning.

So they’re going to help you out in that early design phase, or they’ll help you out in the integration phase. But at some point in the middle, you’re going to have to switch tools, which requires re-setting up your mission profiles, re-setting up your scenarios, and requires a lot of rework.

Satellite developers in this market really need the capability to rapidly compose their system of systems, pulling together disparate parts and pieces, to develop a solution that will meet their mission cost and schedule requirements. And you know, the sort of need to be able to pull in these disparate pieces and parts is what makes component databases such as satsearch so important in today’s environments, as they help engineers to be able to identify what components are out there.

And in order to truly make an informed hardware selection, you need to be able to simulate the performance of your spacecraft using these components. And then once you’ve been able to make that hardware selection, and you’ve got your hardware in house, you need to be able to evaluate the vehicle performance with that real hardware in the loop.

This is one aspect that makes interoperability so important in the simulation tool, it’s that you want to be able to bring in these hardware, components that you haven’t worked with before and that haven’t worked within your system, and be able to have them work within your simulation environment.

Satellite missions are also becoming a lot more complex. Missions are increasingly expanding to require constellations of tens, hundreds and even 1000s of satellites, and interoperability between components and satellites is becoming even more critical in those sorts of environments.

To properly model missions on this level, simulation software has to be modular and scalable in a way that many simulation tools are not able to support. This increase in mission complexity is largely what’s behind the push in the industry for digital engineering.

Digital engineering is a process that focuses on the cross-functional use of tools and data across the system lifecycle. The goals of digital engineering include using models to inform decision-making, providing an authoritative source of truth, and establishing engineering environments that can be used across disciplines to ensure that the right data is being delivered to the right person at the right time.

And so, establishing standards and providing an environment where these disparate tools and components can be integrated and operated cohesively is a critical capability for digital engineering, and to extend your modelling beyond just simulation to the level of a digital twin, where you really have a model that is fully representative your spacecraft to the point where it behaves identically to your spacecraft; how your spacecraft is going to behave in that operational environment.

Having that high fidelity simulation of a satellite or constellation that you can utilise for your specific mission throughout the system lifecycle can reduce the cost and schedule, while also providing higher confidence that admission is going to perform as expected.

That sort of simulation fidelity, and ability to bring in all these different tools, is what is needed by the NewSpace market today. And it’s where a lot of simulations’ capabilities are currently falling short,

Right. Interesting. So it’s not necessarily a lack of ability to simulate mission-critical aspects of the system. It’s the overall interoperability and standards that exist in the overall environment.

So on that; Redwire’s ACORN product has been designed, from my understanding, to help spacecraft manufacturers with different aspects of the simulation and the modelling that we’ve just discussed.

Maybe you could discuss a little bit about the system; how that support is given and also the system makes a lot of use of Modular Open System Architecture or MOSA. I don’t know how you guys refer to that. I wondered if you could explain a little bit about this as well?

I’ll start off by just providing a definition of MOSA. Yeah, so the most common approach is an integrated business and Technology strategy that leverages standards to create freely coupled, easily separable modules for efficient systems development and support.

MOSA’s foundation in modular design dictates the use of open standards, particularly the form of widely accepted interfaces that are independent of specific vendors, which allows for connectivity and rapid reconfiguration between these distinct elements of the systems. So MOSA as a concept is integral to the success of a digital engineering strategy.

The ability to seamlessly add and remove tools, and models and components, from that digital environment is imperative in order to enable engineers across multiple disciplines and with different needs to be able to utilise the same digital environment for further analysis. And this is where ACORN really shines and really provides a lot of value.

ACORN provides MOSA capability via the ACORN bridge application. So for systems that normally wouldn’t be considered MOSA-compliant, we can bring them together within this environment.

It’s designed to allow these disparate assets, utilising different communication mediums, different protocols, different schemas, to be able to interconnect. Assets that can be interfaced with ACORN, and to the simulation environment, include component hardware processors, and third-party tools, such as flight software, ground software, or engineering analysis tools. And to simplify, because that’s a big list there, I’ll refer to the collection of hardware and tools that we can bring in from here on as assets.

So the bridge is fully configurable with the ability to ingest electronic interface control documents, or ICDs, for an asset and build the interface that will connect that asset into the ACORN system. This flexibility is what enables ACORN to function throughout the system lifecycle and perform simulations using tools and hardware that are of interest to engineers across multiple disciplines, and really allows you to provide that foundation for that digital engineering environment.

That makes sense. So once these assets are integrated into the system, the simulation can be performed, in various ways. There’s software in loop, processor in loop, hardware in loop and so on. What do these approaches mean from the perspective of the utility, the operation, of ACORN?

That’s a good question there. So I’ll start with software in the loop. You are working in a fully non-constrained environment. There’s no hard limits or rules that you have to follow except those that are enforced by the simulation itself.

So for example, if your battery on your spacecraft runs out during your simulation, the spacecraft can continue on as if absolutely nothing happened, if the simulation allows it to do that.

And so you know, working within this fully non-constrained environment can be very useful, especially in early development, when you’re exploring different scenarios, just wanting to evaluate overall performance, making those early design decisions.

But eventually, you’re going to need to start adding some constraints onto your simulation in order for it to continue to be useful. This is one of the beautiful things about the way that ACORN operates – the way that it builds with where you are in the mission lifecycle.

You can start out with a GNC-focussed simulation that has just enough control to be able to verify your mission concept. And then as you verify your GNC design closes, you can start adding in your EPS system, and verify that your design closes with that. And then you can add other sub-system modelling, such as thermal modelling, vacuum modelling, and you can use ACORN’s buil- in modules for those – but what we prefer to do is actually go and interface with modelling tools that are designed for this.

We don’t need to reinvent the wheel here, go and get those those higher fidelity modelling tools that represent every sub-system and tie them into your ACORN simulation environment.

And another thing that you can do to improve and continue improving that fidelity is; you can tie in custom component models via an API, so that you can get more representative models of your actual hardware that you’re using the actual components. Once you’ve done that, you are continuing to build on accuracy of your simulation throughout the system lifecycle until it reaches that level of a digital twin.

And then, at some point, you’re going to want to bring in your mission flight software. And you can do that utilising the ACORN bridge. And there’s a couple different ways that you can do that. You can take that mission flight software, and you can run it as a desktop application if the flight software can do that, and a lot of flight software’s have to be run on some sort of processor. But you can bring that EDU in as well, and interface that with ACORN. And that’s when you start talking about processor in the loop simulation.

So the processor in the loop; you’re now entering a first-order constrained environment. Whereas with software in the loop, you can run simulations as fast as they will go, and generate your results very quickly. And now you have to work within the constraints of the processor and its clock.

ACORN has the ability to run simulations in real-time, either synchronously or asynchronously with the flight software. So this allows the engineers to evaluate the performance of the processor in the flight software in an environment that mirrors your actual operational environment.

And then once you have your processor working in your operational environment, you can start adding in your hardware. And as you start to add hardware in the loop, the environment becomes increasingly more constrained.

All of a sudden, your reaction wheel actually has limits on how fast you can spin. If your battery depletes, now your components are actually going to start shutting down. You have sensors that are going to need ground support equipment in order to drive the proper response.

ACORN is able to provide messages to these ground support equipment such that they can represent that simulated environment. And so that your sensors are responding back with the correct telemetry that represents an environment.

And so now, when you’ve got that ground support equipment, all working with ACORN, you’ve got your sensors all tied in, you got your actuators tied in, you’ve got your processor in the loop tied in. Now you’ve got a full flatsat that’s being driven by a high fidelity simulation environment.

And you can use that to do your final mission testing and also as a representative model during operations. So you can see what’s going to be the effect of a certain command sequence or perform troubleshooting on on-orbit anomalies to help figure out what the problem is, and a potential response to that.

So that’s kind of how ACORN is able to help across the whole system lifecycle with various forms of simulation. One other thing I’d like to touch on before we move on is scalability.

ACORN has the ability to interface with other interconnected ACORN units in order to model a constellation. And ACORN acts as the building block in this situation for a massive simulation involving large numbers of satellites.

And it takes advantage of VMs and VSPHERE technology to be able to spin up ACORNs on-demand to meet your current simulation needs for your scenario. The reason I want to touch on this here is that, in these different ACORNs you have interfacing within this constellation environment, you can mix your fidelity levels and your hardware integration levels on these different ACORNs.

So you have some ACORNs running low fidelity simulation of satellites that you’re not really concerned with right now. But you want to make sure that you can still see them within your scenario, you can have a higher fidelity simulation for the ones that you want to focus on. And that higher fidelity simulation can be full software in loop, acting as a digital twin, or it can bring in that hardware in the loop aspect and still be talking to all these other software in the loop ACORNs within the same simulation environment.

So it gives you a lot of flexibility to model different scenarios within this constellation environment using these different simulation techniques.

Right, so you can iteratively simulate the constellation as a whole, even though different aspects of it may be at different stages of development.

That’s a really good explanation of the process that simulations will go through on these different levels, different layers of constraint, which obviously mirror more and more closely, the operational environment.

That’s great. Thank you. So maybe then just to go a little bit further, and I wondered if you could provide us with some examples of how ACORN has helped component or spacecraft manufacturers, mission planners, some use cases?

Yeah, so when we started developing ACORN, we did a NewSpace market survey, segmenting the companies out there into four different potential user groups for ACORN. We had component manufacturers, payload manufacturers, mission integrators and value-add data services.

And we worked to understand the use cases for each of these different groups. We’ve had success working with each of these groups. But I’ll give some examples of specific component manufacturer admission integrators here.

The first example we have is a component manufacturer based in South Africa, NewSpace Systems. They successfully integrated and have driven their reaction wheel with ACORN.

And we’ve done this multiple times with multiple different scenarios, so they’ve been able to really evaluate the performance of that reaction wheel in actually many representative environments and be able to you know, make improvements and tweaks whatever they need to continue to improve that performance.

They’ve also recently been working on integrating and evaluating their GPS receiver with ACORN and that integration is going very well. From a mission integrator standpoint, we’ve also worked with KISPE in the UK, and they successfully built a number of different DRMs across multiple different mission profiles within ACORN.

And taking that step further. If you do a search on YouTube for global collaborative space system development, you can find a really awesome video of a live demonstration we did at smallsat last year, where we had a mission integrator KISPE operating three different satellites on different ACORN platforms.

One of those was located at the KISPE facility in the UK. One was looking at our facility here in the US and we had one located with NSS in South Africa. And the operator KISPE was sending commands to the different ACORNs and you were able to see the response to those ACORNs/satellites make in the video.

And in addition, we had the ACORN and NSS integrate in that NSS reaction wheel. And so you can see the real live response to the wheels making to the flight software responding to the commands the KISPE operator sending.

And so what we have is a three continent demo, demonstrating ACORNs constellation hardware in the loop simulation capabilities of in addition to highlighting KISPE and design capability and NSS’s reaction Wheel. We were really thrilled with the final results of that demonstration and how ACORN was able to empower collaboration across these globally distributed users.

Well, we’ll link to their video in the show notes that sounds really interesting, I think would be really useful for people to see. So thanks for that.

And so in these projects that we’ve discussed, and other projects that you’ve worked on with the ACORN system, or in the development of the system itself maybe, you must have come across several very common major adoption barriers for teams that are building components or whole spacecraft in leveraging modelling and simulation tools more effectively, or more widely. Maybe you could just discuss some of those briefly?

Yeah, I think we touched on one of those barriers already in pretty good detail, which is the lack of standardisation and interoperability. It’s very difficult to utilise a simulation tool when it’s not going to actually work with your mission profile or with your environment or with your specific spacecraft.

And even just not having the confidence that a simulation is going to be able to do that can be a barrier in itself, whether or not it actually is going to do that, it’s hard to want to shell out money for simulation, because there is going to be cost associated with it.

Not just purchasing but also just setting up the simulation, it’s hard to want to shell that out, if you don’t even know it’s going to work with your mission. And so that’s one common barrier.

Another barrier is the learning curve that’s associated with these modelling and simulation tools. These tools are by their nature, very complex. You know, we’re remodelling very complex systems and so there’s going to be some complexity, and there’s going to be some learning curve associated with setting it up. And there’s going to be some time and resources that you have to allocate in order to be able to use the simulation effectively.

But the benefits that you’re going to see over the full system lifecycle are well worth the cost, especially for simulation tools, like ACORN that do offer value across the full system lifecycle.

This is especially true if you’re going to be planning on doing multiple satellites. Because once you’ve laid the foundation with that first satellite, each new satellite you develop, you’re going to benefit from the mission and cost savings that simulation provides, but not have to have that learning barrier.

And kind of related to that learning barrier, you have the issue of companies turning to simulation too late in the design process. You still can get benefit out of simulation later in the design process, as I said, ACORN is going to offer your benefit across the full lifecycle, ut your best benefit is going to be starting out with a simulation and carrying it throughout your lifecycle.

And especially because when you’re later in the lifecycle, you need more out of your simulation tool, but you need your simulations increasing in fidelity. And that’s going to increase that learning barrier that we just talked about.

Because you want to be able set up a higher fidelity simulation that takes more to be able to do that. And so you’re spending a little bit more on that learning curve, you’re getting a little bit less value across the lifecycle.

My recommendation, if you’re even thinking about adopting simulation, you’re starting out in your design process, do it early, do it as soon as you can, because you’re going to get the most benefit, you’re going to get into able to get into a rhythm with that simulation tool.

And then one other adoption barrier I want to touch on is just the market awareness. Not knowing what modelling and simulation tools are available out there.

And so for this, I do want to recognise satsearch for helping to educate the market and providing information about available tools in database. And I also want to thank satsearch and you for allowing me to participate in this podcast to get the word out about ACORN. Because I think we got a tool here that’s going to be able to help a lot of different mission integrators, a lot of different mission profiles.

Oh, that’s great. You’re more than welcome. Yes, that’s really interesting. It’s very much about those sort of compound benefits, both in terms of the accuracy, the fidelity, the operational realism of your simulation is going to compound and get more advanced, the earlier that you’ve introduced the tools and also the efficiencies you’re able to create and the time able to save also compounds further along the line, because you’ve already built into the simulation earlier on the architecture, the overview of the of the system.

Just to finish up, where do you see the sort of this field, open system architectures, reconfigurable system design, where do you see this moving? Where do you see this going in the next three to five years say?

That’s a very good question there. And before I describe the future state, let me take a moment to kind of describe some of the history of MOSA.

MOSA at its conception was largely focused on rapid satellite development and the ability to minimise rework when we re-using a spacecraft design.

The goal was to streamline your hardware selection and make it easier to swap spacecraft components in and out so satellite developers are not beholden to their supply chain. So if you have a supplier that’s not gonna be able to meet your mission timeline or raises the prices or what have you, you’re not forced to go with them and take that cost and schedule impact to your mission.

You can swap out components without having to do a full satellite redesign. You know that that was kind of the focus of MOSA. While we were talking about redesign, it still is very much focused on kind of one satellite at a time. And as a simulation tool based on the MOSA concept, that’s kind of where ACORN started to.

But you know why there’s always going to be a niche for MOSA in the application of satellite development and hardware selection, I think where you’re gonna see it most rapidly grow in importance is for operations, I think we’re going to start to see it applied more and more over the next few years.

You look at, for example, what the Space Development Agency is doing with proliferated LEO in their Tranche-1 mission. They have 150 satellite constellation, in LEO being developed by up to five different contractors. And all these satellites need to be able to communicate with each other, and they need to be able to communicate with different ground systems.

When you have that sort of mission profile, having a solid foundation of standards is absolutely critical to the success of your mission. And that’s not going to be the only use cases that you’re going to see here, we’ve got proliferate of geo missions, you’ve got cis-missions that are gonna have very similar needs that are in the works.

If you a step further, you have the concept of hybrid architectures and mesh networks. You’ve got satellite constellations that weren’t even necessarily designed together and weren’t necessarily designed for the same purpose that you want to get to work together to achieve on-demand to be able to achieve certain mission needs and when you want to have that sort of capability, standards and interoperability is absolutely critical.

Then you can even go an extra step on that and add in assets that aren’t even spacecraft. You can bring in ground stations, ships, jets, there’s a lot of terms that are being thrown around for that. Multi-domain operations, joint all domain operations, joint all domains command and control. In the end, it’s just a bunch of disparate systems that are generating a lot of data that needs to come together and in a standardised format, so that you can do analysis, so that you can do evaluation, so you can utilise that data to make decisions.

Modularity, standards, and interoperability are key to enabling the capability, which is why I believe that’s the area that MOSA is going to make the biggest impact in the next three to five years. And Redwire is a thought leader in MOSA technology. With ACORN, we’re going to be leading the charge in providing this predictive modelling capability and digital engineering. And it’s needed to design integrate and operate these next generation systems of systems.

Well, fantastic! Yeah, that’s a fascinating area, you think of the complexity of the largest-scale satellite constellations, but you’re still only talking about assets based in space, or the ground systems that interface with them.

Then if you add in terrestrial-based additional systems, other technologies, vehicles, whatever it is, you’ve got a whole other set of standards issues, modalities and companies, crucially, companies and organisations to deal with. It sounds like a really interesting area.

I think that’s a really good place to finish the conversation there. We want to thank you Chad for sharing your knowledge with us. I think our listeners will have learned loads about what goes into good quality, high-quality simulation at all stages of mission development and operation. We appreciate you spending time with us on ‘The Space Industry’ podcast today and we’d like to wish you in RedWire all the best.

Thank you very much for allowing me this opportunity.