Recursive MBSE Architecture Weave Pattern

The Recursive MBSE Architecture Weave Pattern (RAWP) is a SysML v2 reference model for requirements-driven behavioral modeling with recursive decomposition. The pattern is machine-readable, executable, and intended for reuse as a practical baseline in MBSE projects.

Overview

The pattern combines:

• Recursive requirement decomposition across model levels.
• Structural allocation using explicit budget attributes.
• Behavioral realization via action execution and value propagation.
• Verification cases bound to integrated model contexts.
• Layered interface/stack-port modeling for interaction semantics.

Pattern Architecture

Decomposition Levels

Framework Level

Level -1 (Framework) provides reusable definitions for all decomposition levels:

• Common semantics and reusable types.
• Layered stack-port/interface definitions.
• Cross-level modeling conventions.
• Verification intent categories.

Abstraction Views per Level

Naming pattern:

• Original requirement: payloadQualityGain{Level}
• Derived requirement: payloadQualityGain{Level}Derived

Recommended Modeling Sequence

Use this sequence to minimize rework and keep decisions evidence-based:

1. Define behavior first at graybox (_gb).
2. Run analysis at graybox (_gb) to calibrate assumptions and attributes.
3. Refine connectivity only after behavior and analysis are stable.
4. Execute verification at whitebox (_wb) when available.

Default policy:

• Prefer analysis on _gb.
• Use analysis on _bb only by explicit exception.
• In this pattern, L3 analysis cases are intentionally omitted; L2 Subsystem2 is the explicit _bb exception.

Analysis Aspect

Analysis is a first-class part of the pattern and is used to calibrate decomposition decisions before interface hardening and final verification.

Primary analysis intent:

• Calibrate budget attributes and allocation splits.
• Test sensitivity to assumption changes.
• Evaluate degradation and boundary scenarios.
• Compare alternatives and trade-offs before structural lock-in.

Modeling policy for analysis:

• Prefer analysis at graybox (_gb) where constituent behavior is visible.
• Use blackbox (_bb) analysis only when explicitly justified by uncertainty, alternatives, or context constraints.
• Keep analysis focused on decision support, not on duplicating verification cases.

Expected analysis outcomes:

• Updated allocation values and assumptions.
• Clear rationale for requirement decomposition choices.
• Better confidence before refining connectors/ports and running integrated verification.

Analysis placement by level:

• L0, L1, and L2 can host analysis cases where decomposition decisions are active.
• L3 analysis can be intentionally omitted for leaf-level reference branches.

Core Recursive Mechanism

1. Requirement Decomposition

Pattern characteristics:

• Derived requirement subsets parent requirement.
• Subject is redefined from _bb context to decomposed (_gb) context.
• Budget attributes carry explicit allocations.
• Child requirements represent allocated needs for next-level constituents.
• Assumption gates control whether frame/require obligations are evaluated.

2. Structural Quality Closure

RAWP uses structural attribute binding in derived requirements:

• subject.qualityContribution is defined as the sum of allocated budget attributes.
• This is structural definition, not only post-hoc validation.
• Constraint statements remain as explicit, readable closure rules.

3. Configuration Realization

• Blackbox part satisfies the original requirement.
• Graybox part subsets blackbox and introduces constituents.
• Whitebox part (when present) integrates interfaces/ports/flows.
• Satisfaction links connect each requirement to the realization context.

4. Behavioral Realization

• Blackbox parts bind qualityContribution to action outputs.
• Action execution computes quality values used by requirement evaluation.
• Verification uses live computed values, not static placeholders.

5. Verification Realization

• Verification objective targets the requirement being verified.
• Verification subject is _wb when available, otherwise _gb/_bb for terminal branches.
• Stimulus is routed to actions that execute behavior, avoiding empty shells.

Layered Stack Port Pattern

The framework defines a layered stack-port model (MyStackPort) and the SoI applies it through explicit directional flows.

Key usage rules:

• Choose one connector-facing abstraction layer per connector usage.
• Keep flow declarations direction-compatible with selected nested ports.
• Use conjugation intentionally where consumer-facing orientation requires inversion.
• Avoid accidental mixed-layer declarations unless explicitly intended.

Design Principles

1. Requirement duality: each requirement is both a child need from parent perspective and a requirement at its own level.
2. Action-output traceability: quality values come from executable behavior bindings.
3. Explicit allocation: budget attributes are model values, not hidden assumptions.
4. Structural enforcement: derived sums are defined through binding, not narrative intent.
5. Assumption gating: frame and require clauses are evaluated only when assumptions hold.
6. Design/environment separation: designed elements are behavior-driven; external elements can remain blackbox defaults.

Cross-Level Consistency Rules

Maintain consistency through:

• Subject chain integrity from parent level to child level.
• Action subsetting integrity from parent action to child actions.
• Requirement satisfaction chain integrity from original to derived and onward.

Implementation Checklist

For each added decomposition level, include:

• Requirements file:
  • Original requirement on _bb subject.
  • Derived requirement with budget attributes and closure logic.
  • Assumption gate and frame/require obligations.
  • Child requirements for allocated needs.
• Configuration file:
  • _bb and _gb parts, plus _wb where decomposition exists.
  • Satisfaction links to original and derived requirements.
  • Part structure and connectivity aligned with taxonomy.
• Behavior file:
  • Action structure for _bb and derived behavior paths.
  • Value-producing actions for quality computation.
• Analysis file:
  • Analysis cases for sensitivity, degradation, and trade-off exploration.
  • Assumption and allocation calibration scenarios for decision support.
• Verification file:
  • Cases for original and derived requirements.
  • Subjects chosen by highest integrated level available.
  • Stimulus routed to executable action chains.
• Stakeholder/taxonomy views:
  • Concerns and constraints aligned with frame/require semantics.

Scalability

The pattern scales by:

• Horizontal expansion: add additional subsystems.
• Vertical expansion: insert intermediate levels.
• Terminal variation: keep some branches at blackbox leaf form.

Repository Structure

RecursiveArchitecturePattern/
|-- Level -1 - Framework/
|-- Level 0 - Operational/
|-- Level 1 - SystemOfInterest/
|-- Level 2 - Subsystems/
|-- Level 3 - Components/
|-- Credits/
|-- CHANGELOG.md
`-- README.md