Comparative analysis of a model‐based systems engineering approach to a traditional systems engineering approach for architecting a robotic space system through knowledge categorization

Abstract

This study compares the types and quantities of knowledge that are captured by a model-based systems engineering (MBSE) approach and a traditional architecting approach to measure the benefits of the MBSE approach in managing the complexity of a robotic space system. The MBSE approach was implemented with Cameo Systems Modeler using Systems Modeling Language (SysML) and applied to architecting an orbiting sample Capture and Orient Module (COM) system concept for a Capture, Containment, and Return System payload concept for potential Mars Sample Return.An architecture framework was established, covering system, subsystem, and assembly levels, along with structure, behavior, data, and requirements perspectives. The COM system architecture was captured in parallel using both the MBSE and non-MBSE approaches in order to provide a side-by-side comparison of the approaches.The approaches were evaluated based on how well each represented the information content of the COM system architecture. A total of 4389 knowledge elements were classified using the Revised Bloom's Taxonomy knowledge dimension and used to quantitatively compare the two approaches. The MBSE approach more completely captured architectural knowledge than the non-MBSE approach. Limitations to the SysML-based MBSE approach were also identified, including its ability to fully represent certain high-level conceptual, procedural, and metacognitive knowledge such as design principles, design approaches and rationales, risks, development strategies and rationales, organizational core competencies, and requirement verification methods.The overall results demonstrate the benefits of MBSE in managing the complexity of robotic space systems and strengthen the case for adopting MBSE within the systems engineering community.

Comparative analysis of model‐based and traditional systems engineering approaches for simulating a robotic space system architecture through automatic knowledge processing

“…The system architecture and requirements of the physical system were manually analyzed at each level to identify knowledge relevant for modeling and simulation needed to verify the COM power and output data rate requirements. The key architecture knowledge elements identified were based on the system architecture information content defined for the architecture framework used to describe the COM architecture in terms of structural, behavioral, and requirements perspectives, and selected based on inputs from the CCRS architecture team at JPL, as described by Younse et al 3 These knowledge elements are listed and described in Table 5. This activity was performed at the system (Level 4), subsystem (Level 5), and assembly (Level 6) levels of the COM in both the non-MBSE and MBSE approaches.…”

“…The proposed architecture for the COM is complex, composed of 46 unique system element types, 203 interfaces, and 136 functions, utilizing a total of 4389 architectural model elements to describe the overall system architecture 3 . Extensive modeling and simulation were performed to verify that the architecture could meet its functional and performance requirements while keeping within system technical constraints.…”

“…2 The proposed architecture for the COM is complex, composed of 46 unique system element types, 203 interfaces, and 136 functions, utilizing a total of 4389 architectural model elements to describe the overall system architecture. 3 Extensive modeling and simulation were performed to verify that the architecture could meet its functional and performance requirements while keeping within system technical constraints. This included simulations to verify OS capture performance, optimize capture trigger sensor configurations, characterize OS-spacecraft interactions, assess vision-based pose-estimation and surface inspection of the OS, estimate operation time, evaluate kinematics of the capture lid and linear transfer mechanism end effector, and estimate power draw and data volume generation.…”

Datasheet: where is requirements engineering gone? A case in Benchmarking Mobile Robotics

“…The profile of model specifications could be adapted to the system context and categorization [9]. It is a widely accepted prolongation to the SysML 1.3 success in System engineering [10], because it adds views and connections to the system requirement expressions.…”

“…It is a widely accepted prolongation to the SysML 1.3 success in System engineering [10], because it adds views and connections to the system requirement expressions. The model aspects based on SysML does not express all required aspects of system design, which makes it incomplete, such as cited in [9]. This is a motivation for acquirers to specify systems in architecture frameworks, and to dig deeper on semantic approach [11] for system specification ambiguity reduction.…”