CubeSat Model Based System Engineering (MBSE) Reference Model - Development and Distribution - Interim Status #3

Model-Based Systems Engineering (MBSE) is the formalized application of modeling to support key systems engineering tasks for addressing requirements, design, analysis, validation, and verification. The International Council on Systems Engineering (INCOSE) established the MBSE Initiative to promote, advance, and institutionalize the practice of MBSE. As part of this effort, the INCOSE Space Systems Working Group (SSWG) has been investigating the applicability of MBSE for developing a CubeSat Reference Model (CRM). Our application of MBSE is enabled by the graphical modeling language Systems Modeling Language (SysML). SysML is used to model all aspects of a system either directly or through interfaces with other models. SysML diagrams are used to describe requirements, structures, behaviors, and parametrics from the system down to the component level. Requirements and design are contained in the model rather than in a series of independent engineering artifacts. The CRM provides the logical architecture. The logical elements can be reused as a starting point for a mission-specific CubeSat logical architecture, followed by the physical architecture and the CubeSat development. Our prior work established the CRM domain as consisting of the stakeholders, CubeSat enterprise, external environment, and external constraints, with the CubeSat enterprise consisting of space and ground segments. The CubeSat enterprise architecture has been refined to accommodate an external service providing CubeSat transportation to a launch site, integration into a launch vehicle, launch, and deployment. It has also been refined to accommodate a CubeSat project developing its own ground station or operating with an existing ground station that provides uplink and downlink services. Space and ground subsystems had been identified in our prior work. Use cases have now been established to further define the subsystem capabilities. It has been recognized that there are two modeling efforts. One is the SSWG developing a CRM with its logical architecture. The other is a team eventually taking the CRM as a basis for its mission-specific logical and physical architectures. Therefore, there are two categories of stakeholders. A stakeholder is any entity that has an interest in the system. The stakeholders for the CRM include INCOSE, the Object Management Group (OMG), regulatory agencies, and the university teams that will be using the CRM. We are exploring having NASA, NOAA, and FCC regulations contained within their own SysML models and connecting those models to our CRM. Another one of the stakeholders is the Cal Poly CubeSat project. The Cal Poly CubeSat Specification has been populated into its own SysML model to enable the content of the specification to be related to the CRM. The stakeholders for the mission-specific CubeSat model are those with an interest in the mission-specific CubeSat space and ground system. Typical stakeholders for a space and ground system include sponsor, user, operator, project manager, project engineer, developer, and tester. The list of stakeholders for a university CubeSat project is much smaller. We are developing validation and verification strategies and are collaborating with OMGs Space Domain Task Force (SDTF) to adopt the CRM as an OMG specification

Long-Distance Signals Are Required for Morphogenesis of the Regenerating Xenopus Tadpole Tail, as Shown by Femtosecond-Laser Ablation

tadpoles has recently emerged as an important model for these studies; we explored the role of the spinal cord during tadpole tail regeneration.Using ultrafast lasers to ablate cells, and Geometric Morphometrics to quantitatively analyze regenerate morphology, we explored the influence of different cell populations. For at least twenty-four hours after amputation (hpa), laser-induced damage to the dorsal midline affected the morphology of the regenerated tail; damage induced 48 hpa or later did not. Targeting different positions along the anterior-posterior (AP) axis caused different shape changes in the regenerate. Interestingly, damaging two positions affected regenerate morphology in a qualitatively different way than did damaging either position alone. Quantitative comparison of regenerate shapes provided strong evidence against a gradient and for the existence of position-specific morphogenetic information along the entire AP axis.We infer that there is a conduit of morphology-influencing information that requires a continuous dorsal midline, particularly an undamaged spinal cord. Contrary to expectation, this information is not in a gradient and it is not localized to the regeneration bud. We present a model of morphogenetic information flow from tissue undamaged by amputation and conclude that studies of information coming from far outside the amputation plane and regeneration bud will be critical for understanding regeneration and for translating fundamental understanding into biomedical approaches

The removal of information from working memory

What happens to goal-relevant information in working memory after it is no longer needed? Here, we review evidence for a selective removal process that operates on outdated information to limit working memory load and hence facilitates the maintenance of goal-relevant information. Removal alters the representations of irrelevant content so as to reduce access to it, thereby improving access to the remaining relevant content and also facilitating the encoding of new information. Both behavioral and neural evidence support the existence of a removal process that is separate from forgetting due to decay or interference. We discuss the potential mechanisms involved in removal and characterize the time course and duration of the process. In doing so, we propose the existence of two forms of removal: one is temporary, and reversible, which modifies working memory content without impacting content-to-context bindings, and another is permanent, which unbinds the content from its context in working memory (without necessarily impacting long-term forgetting). Finally, we discuss limitations on removal and prescribe conditions for evaluating evidence for or against this process

CubeSat Model-Based Systems Engineering (MBSE) Reference Model –Model Distribution and Application –Interim Status #2

Model Based Systems Engineering (MBSE) is a key practice to advance systems engineering that can benefit CubeSat missions. MBSE creates a system model that helps integrate other discipline specific engineering models and simulations. The International Council on Systems Engineering (INCOSE) established the MBSE Initiative to promote, advance, and institutionalize the practice of MBSE. The INCOSE Space Systems Working Group Challenge team has been investigating the applicability of MBSE for designing CubeSats since 2011. Our application of MBSE uses System Modeling Language (SysML), a graphical modeling language, to model all aspects of a system either directly or through an interface with another model. SysML diagrams are used to describe requirements, structures, behaviors, and parametrics from the system down to the component level. Requirements and design are contained in the model rather than in a series of independent engineering artifacts. In the past phases of the project, the team has created the initial iteration of the reference model, applied it to the Radio Aurora Explorer (RAX) mission, executed simulations of system behaviors, interfaced with commercial simulation tools, and demonstrated how behaviors can be executed to perform trade studies. The goal of the current phase is to provide a sufficiently complete CubeSat Reference Model that can be adapted to any CubeSat project. The CubeSat Reference Model will have all the logical model elements for population by a mission specific CubeSat team as their foundation for a physical model. The CubeSat Reference Model starts with an identification of potential stakeholders. A stakeholder is any entity that has an interest in the system including sponsor, end user, procurer, supplier, and regulatory agencies. The each stakeholder\u27s needs, objectives, constraints, and measures of effectiveness are incorporated in the model. Constraints are those items fixed and not subject to trades such as mission budget and schedule. The CubeSat operational domain includes the CubeSat mission enterprise and the external environment. The external environment consists of the natural and induced environments. The CubeSat mission enterprise consists of the space system, ground system, launch services, launch vehicle interface system, and communication services. The CubeSat model accommodates an entire project lifecycle from conception through retirement. The model accommodates all phases of operations from launch, early operations, normal operations and sustainment. Since we are just providing a reference model, another CubeSat team can apply their own mission lifecycle and engineering processes to customize and populate the model. One of the stakeholders is the Cal Poly CubeSat project. The Cal Poly CubeSat Specification has been populated into its own SysML model to enable the content of the specification to be related to the CubeSat Reference Model. The reference model is being developed by a team effort and there is an obligation to protect the investment of time and knowledge of each team member. There will be a licensing environment that is conducive to a user organization supporting the development of and use of the model

Model Based Systems Engineering (MBSE) Applied to Radio Aurora Explorer (RAX) CubeSat Mission Operational Scenarios

Abstract—Small spacecraft are more highly resource-constrained by mass, power, volume, delivery timelines, and financial cost relative to their larger counterparts. Small spacecraft are operationally challenging because subsystem functions are coupled and constrained by the limited available commodities (e.g. data, energy, and access times to ground resources). Furthermore, additional operational complexities arise because small spacecraft components are physically integrated, which may yield thermal or radio frequency interference. In this paper, we extend our initial Model Based Systems Engineering (MBSE) framework developed for a small spacecraft mission by demonstrating the ability to model different behaviors and scenarios. We integrate several simulation tools to execute SysML-based behavior models, including subsystem functions and interna