AeroCube 10, a pair of 1.5U CubeSats, deployed from a 3U NanoRacks deployer aboard a Cygnus cargo spacecraft in August. These craft have started to perform several of the primary missions: engaging in proximity operations, demonstrating a new thruster, and deploying atmospheric probes.

To date, a vehicle has successfully deployed one of its 28 probes, while another has performed a thruster maneuver to start a slow approach toward its sister AeroCube.

As the complexity of AeroCubes increases, so does the need for rigorous systems engineering practice. To help address this complexity, an AeroCube modeling team used a model-based systems engineering (MBSE) approach to capture key system definition attributes. 

The requirements, concept of operations (aka CONOPS), verification activities, physical architecture, and system-level analyses were captured and interconnected in a system-definition model that serves as a “source of truth,” which, unlike traditional document-based approaches, allows systems engineers to describe and trace these attributes consistently. 

Within the systems engineering community, there are insufficient examples of MBSE being applied across a satellite lifecycle. The lessons learned from this MBSE application during development will help us advise other project leads as they integrate MBSE into their activities. Some of the key lessons learned include:

• Modeling helps avoid pitfalls. Rigorous system-definition modeling forces early conversations among engineers, scientists, and stakeholders about structure, behavior, and requirements, helping avoid surprises later in development (e.g., during the integration and test phase).
• Plan the SysML model structure. Create component libraries, functional packages, etc., at a general abstract level. Meta-modeling can be reused later for future projects.
• Make key SysML model artifacts accessible. Create a method of sharing model elements with the development team, reviewers, and other stakeholders. Provide an export of artifacts into a format that everyone knows how to use, such as spreadsheets.
• Introduce MBSE in parallel with the development process, at least initially. Although not a general rule for all situations, funding MBSE separately and gradually delegating a holistic system definition model as the source of truth are preferable to abruptly mandating a new approach to a successful, existing process.
• Create connections between model elements. One advantage of a descriptive digital model over separate static documents is the interconnections of all the system elements rather than separate standalone artifacts.

One example use of the MBSE implementation was that when a mission requirement was removed late during the detailed design phase, several actions were quickly performed and captured: 

• Identified specific tests that were no longer required during integration and test phase
• Modified the CONOPS 
• Reran the system power analyses based on the new CONOPS to ensure adequate power 
• Updated lower-level requirements that derived from the removed requirement 
• Identified the subsystems, software, and components that would be affected so that all the members of the team would have the same understanding of the expected system behavior

This fast-paced AeroCube project provided an ideal pathfinder for MBSE implementation.

A report containing the lessons learned from the pilot MBSE project is released under OTR 2019-01065. 

For more information, contact Rob Stevens, 310.336.8786, robert.e.stevens@aero.org.