Systems Engineering
ABEX employs a Models Based System Engineering (MBSE) approach with a SysML Integrated Systems Model (ISM) to manage work tasks, interface control, requirements, risks, Verification & Validation (V&V) procedures, and system reliability in an environment coupled to the system architecture. A singular system model reduces risk of design conflict through interconnectivity, configuration control, and institutional dependencies as an exclusive source of truth. Student involvement presents programmatic risks which are mitigated using the ISM’s clear view of the system interfaces, tasks, and specifications.
MBSE is defined by an Architecture Framework (AF) specifying a taxonomy of work products created throughout the mission, a Process Framework (PF) detailing the maturation of those products, an ontology expressing the properties of and relations between those products, and a modeling language used to create the ISM which ties it all together. The AF and PF organize which activities are accomplished in the mission and how they are accomplished, respectively; defining these explicitly affords rigid yet reinforceable structure to a project organization. The ontology aids in student conceptual understanding, product creation, and process execution by defining entity categories for concepts that exist in the program and strong, semantic relationships between those categories; ontologies represent an agreement on relationship usage rather than the usage itself. Graduate systems engineers interact directly with the ISM, not undergraduates.
Program management, in ABEX’s case the Project Manager and Chief Engineer, organize engineering, operations, science, and enterprise work in terms of the AF and provide subsets of that work to students in the form of a Design Analysis Cycle (DAC) work package specific to an academic semester. Per the PF, descriptions are included for how the work package should be executed and in what form deliverables should be provided. The PF also dictates which deliverables are shown at which stage-gate reviews, informing the products that should be created for a given DAC. If the AF and PF are defined in mission concept development, all future DAC work is known, ordered, and communicable. Work products in the AF will also be model-based if possible. ABEX utilizes SysML and UML as modeling languages that students can use to generate DAC work products, such as block definition diagrams for subsystem structure, activity diagrams for subsystem behavior, activity diagrams for integration test chain representation, parametric diagrams for analytical models, and sequence diagrams for software operations. Student-produced, model-based work can be imported directly into the ISM, reducing time required to translate student deliverables into the ISM.
Onboarding is the process of educating new members of a workforce in a relevant field and ensuring members can execute provided tasks using a set of provided tools; efficient onboarding provided by faculty and graduate students is paramount for student space programs because student turnover rates are high and knowledge retention is low. Three concepts have aided ABEX in student onboarding: traditional documentation, a centralized repository of onboarding materials, and Domain Knowledge Maps (DKM). Document-Based Systems Engineering (DBSE) is, unfortunately, how students are accustomed to learning. Documents such as analysis plans, development & integration plans, and verification activity plans can be provided as is common of any program, but DBSE material representation should be consistent with the AF, PF, and ontology with figures generated from the ISM. When students provide work products for import into the ISM, the products are polished, connected to other ISM entities such as requirements, structures, or behaviors, and exported back to the DBSE onboarding tools. When students learn subsystem onboarding material, they learn MBSE. Those documents, and any additional onboarding materials, must be available on-demand from a centralized repository for a geographically disperse program. ABEX utilizes this website, abexmission.org, as the first stop in a student’s onboarding journey. Students receive onboarding packages specific to their team containing subsystem-specific plans, reports, tool usage guides, and more general spacecraft and SE education. For analysis products, DKMs facilitate a direct connection between the ontology and the execution of analysis work outlined for a DAC. Ontologies can be created for a specific domain; ABEX subdivides a program-wide ontology into fragments such as the technical analysis domain for hardware and the software development domain for software. A DKM is an application of a domain ontology to a specific problem such as the calculation of a Technical Performance Measure (TPM) or the connection between user-defined software subsystems. If a domain ontology contains concept categories and relationships in that domain, a DKM represents instances of those categories and how they are used. A DKM example detailing instances of predefined categories is provided. The ontological triple, “Number of Torsion Springs is an input to Spring Torque Equation” is an instance of the ontological triple, “Scalar Parameter is an input to Equation.” Strong semantics inherent to DKMs remove ambiguity in concept representation. Additional DKMs and DKM use information is found here !!!!![link DKM page]!!!!!.
DKM Example. Instances of Source, Scalar Parameter, Array Parameter, and Equation categories are shown in red, blue, yellow, and green, respectively. TPMs are shown as ovals.
Programs with rigorous Systems Engineering (SE) processes feature stage-gate reviews such as a System Requirements Review or Critical Design Review, and Subject Matter Experts attending reviews need organized review material in the form of Review Data Packages (RDP) prior to reviews. Even at NASA, RDPs are usually created by sourcing materials from various documents, presentations, standards, and verification activity reports – a cumbersome, time-consuming process. A DAC may last only 14 weeks, and time to execute work products may be severely limited if 3 weeks are required for student onboarding and 3 weeks are required to organize RDP materials. Generating some, not all, RDP materials from the ISM is known as a model-based review and affords time-reduction methods when organizing review materials. Using the ISM, a subsystem can depict structural composition, behavior, integration flows, analysis plans via DKMs, test plans, and the satisfaction or verification of requirements as applied to any diagram. The generation of many RDP materials is then accomplished via perfunctory model exports rather than hunt-and-gather documentation.
The ABEX Integrated System Model (ISM) is the centralized source of truth for subsystem model inputs, architecture communication to stakeholders, and requirements traceability. The ISM allows ABEX to quickly trade subsystem configurations, provide inputs to STK, MATLAB, Simulink, and Thermal Desktop models, and develop Interface Control Documents in a way that many satellite projects may find cost- or labor-prohibitive. The ISM is made possible through the Complex Systems Integration Lab (CSIL) at the University of Alabama in Huntsville, led by Dr. L. Dale Thomas, who also happens to be the director of the Alabama Space Grant Consortium. Dr. Thomas worked at NASA for 32 years as the Associate Center Technical Director for Marshall Space Flight Center and was the Program Manager for the NASA Constellation Program Office at Johnson Space Center, so he knows a thing or two about spacecraft integration.
The ISM is developed using the Systems Modeling Language (SysML). Structural diagrams are used to communicate subsystem architectures to students, who can quickly clean which parts of their subsystems are connected to which other parts of the spacecraft.
Requirements can be organized using tabular or visual formats and allocated to various components in the spacecraft. Requirement verification assurance is made easier through this representation.
ABEX will be polishing the ISM continually until integration processes wind down. Model-Based Systems Engineering is extremely valuable early in a mission, but its utility falls off dramatically when the integrated spacecraft is ready for qualification testing and subsequent launch.