Remote-Sensing Satellite MBSE and Change Impact Analysis
01
Project Background
Remote-sensing satellite design requires coordination across payload, platform and data-processing disciplines. Imaging, resource and interface constraints spread across documents can lead to duplicated parameter maintenance, missed change notifications and inconsistent review versions.
This method case focuses on satellite design organization and requirements change management, establishing a reviewable change-analysis workflow around implementation planning, model baselines and verification links.
02
Domain Modeling and Technical Approach
First align domain concepts such as satellite, payload, interface, requirement and parameter, then organize requirements, structure, behavior and constraints with SysML. Extensions carry explicit domain meaning without redefining the base language, and reusable functions and interfaces enter a controlled library.
Allocate system requirements to functions and functions to subsystems. Parameters retain provenance, decomposition links and assumptions. Change analysis follows established relationships to identify candidate impacts and flag them for review; missing trace links do not mean there is no impact.
03
Implementation and Change Control
Begin with one payload workflow: mission input, function decomposition, platform support and output data, then extend to related disciplines. Common naming, packages and relationship rules control granularity so models created by different engineers can be reviewed at the same level.
Rehearse one requirement change end to end: record its cause, generate candidate impacts, confirm design and verification actions, and update models and reports. Before releasing a baseline, check review flags and retain owners and resolution conditions for open items.
04
Deliverables and Acceptance
Deliverables can include domain vocabulary and extension rules, system-to-subsystem trace models, library entries, change-review records and report templates. Parameters and relationships in each report must come from a specified version rather than mixing design alternatives.
Acceptance samples a requirement, an interface and a change to check upstream and downstream traceability, generated records and engineer-reviewed conclusions. Performance attributes without calculation or test support retain explicit evidence gaps; complete diagrams do not prove performance.
05
Applicability and Limits
The approach suits multidisciplinary teams sharing requirements and reviewing design alternatives frequently. If mission inputs are unstable, establish assumptions and change rules before enlarging the model rather than building oversized, hard-to-maintain diagrams.
This method case focuses on satellite requirements changes and model traceability. Connecting specialist simulations and test data requires agreement on tool versions, interface semantics, access permissions and validation responsibilities.
06
Implementation Outcomes
Expected benefits are less duplicated document maintenance, reviews around one model baseline and clearer handling of requirement changes. Value comes from traceable relationships and responsibilities, not simply replacing text with diagrams.
Track change-analysis time, missed notifications and report-model discrepancies across changes of comparable complexity. The available evidence mainly covers planning and methods and does not establish a measured efficiency gain.