MBSE pillars are SE fundamentals, MBSE tools, MBSE language
Challenges include general obscurity of SE concepts, which can be resolved in models by flexible MBSE tools/language when coupled with rigorous SE efforts and analyses; learning curve, time commitment, managerial buy-ins; limited resources; need for dominant standard to communicate
Benefits: rigorous analysis to decompose system into underlying parts, analyze their interactions to meet objectives with requirements; multi-scale integration; enhancements and optimization of SE fundamentals; standardization and integration to improve communication
TMT application to better understand complex system behaviors; the model captures requirements and scenarios, enables analysis, document production, standardized communication
MBSE is not applied to full system, only for optimization of complex pieces
Telescope Modeling Challenge Team is building on previous generation’s work to revise SE Cookbook and include TMT experiences and examples and produce TMT Case Study for SEBOK fall publication
Other telescope teams should think about doing something similar
Continuously working efforts to apply modeling to GMT
Operational life cycle model
Complex mission: science cases which are often open ended
Complex environment and life time goals
But still with these complexities, there’s a need to make a machine with precise functionality to deliver the mission
Modeling playground which shows various levels, views, and processes and how MBSE can overcome these challenges
Model is a representation of the system’s architecture, and we need a standard language with formal semantics to decompose the system
Observatory as a function; analysis should be pointed at the data to fulfill the science (performance function); also need to check efficiency and safety metrics
Define observing cases with properties and hierarchical structure relevant to POV of observatory’s performance function
Mapping of observing cases vs science cases to understand what science will be impacted if…
This mapping allows data to be managed and still usable when science cases change over lifetime of the observatory
Observing performance modes show system level properties that need to occur simultaneously; independent from design choices
Observing case analysis block with properties as input and system performance output
Analysis is a representation, not performed in SysML model; it defines which analyses need to be performed
Observatory configurations split between nominal and non-nominal configurations
Requirements flow down: science cases (articulates science book) → observing case (articulates science reqs) → observing performance mode (articulates observatory reqs) → observatory configuration (articulates observatory architecture) → data products and system element properties
Analysis performed at each step to enable science case, observing case; enable implies that a single input can provide several outputs, need to add normalization rules
Operation concept: performance, safety and efficiency functions all provide feedback to the observatory
MBSE benefits: system decomposition, requirements flow down, articulating life-cycle concepts, organizing analyses; formal framework to consider correctness and truth; finds holes in specifications
Summary:
Modeling goals
Consistency in flow down of requirements
Traceability between analysis and requirements
Support for system decomposition
Develop observatory top-level life-cycle concepts model
Playground
Enterprise Level - Needs View
Mission Level - Needs view, requirements View, ISO Applicable Processes
System Level - same as above
System Element Level - same as above
ISO/IEC/IEEE 1440
Stakeholder, Concern
Observatory as a function
Observing Cases
Moe - name, units - quantity kind - initial value
Requirements for how accurate system performance needs to be and check against CBEs
Challenges: mass and power roll-ups can refer to PBS, but error budget is not directly linked to the PBS; need integration with system design and check requirements for accuracy
Excel error budget
Accuracy of pupil measurement/alignment to 0.03% of diameter as motivating example
Error roll-up pattern similar to mass roll-up pattern; element with values requirement, CBE, and margin
Margin = (allocated – CBE) / allocated
Pattern application:
inherit from specific error roll-up type
subset “subError” property of ErrorRollUpPattern element
Define default values for all “leaf”-CBEs
Parametric diagram for linking requirements and PBS
Parametric solver using CST (or others); result = roll-up
Excel error budget vs SysML: SysML is better for linking and collaboration
Model can produce visualizations similar to Excel (such as instance tables)
NoMagic is working on requirements improvements; synchronization of Excel and SysML tables instead of one-time import; Jason & Saulius to schedule webinar to discuss this update
New pattern needed for interfaces
OpenMBEE docgen allows for documents that include updated simulations from the model