Innovation involves dreaming up architectures of coordinated satellites brimming with the latest and greatest hardware and software.
Engineering is balancing all of those lofty goals with the integration nightmares of what is both physically and practically realizable. If dreaming big is the catalyst of innovation, then lessons-learned are the bedrock of good engineering discipline.
AGI’s Systems Tool Kit (STK), shown to the right, was built to help bridge that gap.
Northrop Grumman Aerospace Systems faced a two-week system capabilities challenge to perform a payload trade study. In order to maximize their time they found that rather than modifying their own tools they were able to use STK to save 80 percent of their spin-up and analysis time.
According to Chris Champagne of Northrop, “STK provided superior qualitative and quantitative results as compared to our customer’s and competitor’s results.”
Similarly, in 2016 NASA Glenn Research Center found STK was their integration tool of choice to model enterprise architecture options for their Space Communications and Navigation program.
The United States Air Force’s Space Superiority Wing out of Space and Missile Systems Center also found that STK allowed them to rapidly conduct orbit trades, assess sensor performance, and simulate ground operations for their Space Based Space Surveillance program.
The traditional systems engineering approach to building satellite systems involves using the System-V as an attempt to balance these two opposing perspectives by adding some rigor and formality to the process. System level requirements capture the big picture, which is then broken down into subsystems that can be further refined and specified.
This breakdown of a large system into smaller subsystems is where designs can become stove-piped, causing problematic changes to the requirements. A payload-focused design might over-allocate resources to their primary mission while leaving the rest of the spacecraft starved for resources with stricter requirements, thus resulting in an inferior overall design.
Break-Out Example
If you have a payload-oriented program that’s designed around an imaging system, you could set aggressive requirements for area coverage and maximum resolution capability that with sufficient budget for this subsystem to meet would require larger optics, larger focal plane, and more on-board data processing.
However, to meet these more ambitious requirements, the heavier duty imaging payload would put additional stress on the thermal management, power, communications, and attitude/stability subsystems. With smaller satellites if the requirements could be broken down into perhaps two imaging payloads, perhaps even breaking them up across multiple satellites and adding enterprise resiliency and redundancy, these same imaging requirements for area coverage and maximum resolution could still be met while putting less stress on all the other subsystems.
Even with some of these potential risks, the System-V process works well for accomplishing the objective of building an overall system. However, all too often when this discipline is applied to a single system the opportunity to create a coordinated enterprise can be lost.
Ideally, the entire constellation and supporting architecture would be included in the design from the inception of the mission onward, with full-lifecycles for each spacecraft, communication link, and ground processing segment carefully defined with consideration for both potential and pessimistic future budget allocations.
Break-Out Example
When looking at problems from an enterprise perspective it opens the door to new possibilities beyond just a single system’s capabilities. As an example, consider how a small satellite system approaches knowing its position and orientation. For a precise orbital position it would require more sophisticated hardware that might be prohibitive for a small satellites design (consider the additional weight, power consumption, data processing needs, and system complexity).
However, if external observation measurements could be made from the ground with an inexpensive optical network, such as the Commercial Space Operations Center (ComSpOC), and precise orbit determination made then the overall enterprise could achieve the same fidelity through an entirely different means.
Image courtesy of ComSpOC
The problem with both the traditional System-V and enterprise level design perspectives is that building either a full system or enterprise modeling tool to do this analysis is prohibitive for both new programs just starting up as well as for smaller owner operators. That’s where commercial-off-the-shelf (COTS) modeling and simulation solutions such as STK come into play.
Using an enterprise modeling capability that can accurately model low-level subsystems, interactions between systems, and can propagate future performance allows users to get started sooner and work faster while also reducing overall program risk and cost (Frost and Sullivan reference).
For single systems, one can focus on evaluating high level system designs or dive into integrating industry standard or proprietary subsystem models. With an enterprise modeling capability, one can move right into modeling an entire constellation and supporting architecture over decades to characterize true integrated system performance over the full potential life-cycle.
This capability is even more important upfront to bridge the gap between innovation and engineering by allowing users to design entire constellations quickly with accurate constraints in place to perform both system-level and enterprise-level design trades early on and throughout design, build, test, and finally operations.
Imagine looking into the future and being able to enjoy the benefits of hindsight from day one of your concept of operations. Rather than just performing early system level design trades and analysis of alternatives for a single satellite an enterprise modeling user can perform quantitative analysis twenty years or more out into the future to see how their growing and evolving enterprises can someday look and start building to those requirements today.
Break-Out Example
This full enterprise perspective lets you step out of the completely hypothetical innovation space and start quantifying future research and development needs in areas such as technology, automation, scalable manufacturing options, redundancy, resiliency, reusability, and so on. With the right modeling capabilities a system design can easily turn into an enterprise design that allows for enterprise level what-if scenarios. Rather than just looking at the budget of a single system one could look at budgetary impacts, both positively and negatively, across the entire enterprise rather than on a single satellite-by-satellite or program-by-program basis. This allows research and development efforts to impact across programs and missions, for example the Johns Hopkins University Advanced Physics Laboratory uses STK to perform test collections from a multitude of sensor configurations to evaluate payload performance that can be applied to many future systems across an enterprise.
Putting a system or multiple systems into an enterprise model that projects performance out for years to come also allows engineers to hammer on the enterprise design with all of the potential curve balls that could happen during the lifetime of each system.
In addition to the design and build phases and evaluating potential future capabilities, one can also focus on the present day-to-day operations. With a full enterprise perspective and the right modeling capabilities, more realistic inputs and outputs can be used during dry runs and rehearsals to be more prepared for operations.
Pre-initialization stress tests can flesh out problems much earlier in the development cycle and lead to more confident Go/No-Go decision at each progress gate. Once the rubber hits the road and new systems become operational, enterprise modeling capabilities allow for analysis of empirical performance. This allows for updates on future models and improvements on daily calibration and operations scheduling. Anomalous events can be analyzed quickly with an enterprise model to perform forensic model-based investigations to cut through the what-if haystack and narrow down the most relevant hypotheses.
All of this systems engineering work still requires the talented, experienced, and innovative engineers to perform the work, but with a good system and enterprise modeling capability the team can feel confident that each piece of the complicated puzzle is accurately represented and working together to keep the entire team moving in the
same direction.
This can perhaps help everyone move from the day-to-day System-V execution to a true enterprise level perspective, because at the end of the day if we can all think big and work together that’s a true innovation engine.
www.agi.com/products/engineering-tools
