MBSE Recursive 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

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.

Standards Encoding and Use

Standards are modeled as machine-readable compliance overlays in the framework standard package. A standard defines reusable constraints and groups them into requirements that apply to parts in scope. Architecture elements claim compliance by subsetting the standard-complying part and satisfying the related requirement, so conformance can be checked directly from model constraints.

COTS Library Encoding and Use

COTS products are modeled as reusable library packages in the framework COTS library package. Each product package contains its exchange items, ports, interfaces, product part definition, integration connector category, and supplier evidence attributes. Project architectures use these definitions by selecting and integrating the COTS boundary as a terminal supplier-owned element, rather than decomposing it as internally designed structure.

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/
|-- Framework/
|-- Level 0 - Operational/
|-- Level 1 - SystemOfInterest/
|-- Level 2 - Subsystems/
|-- Level 3 - Components/
|-- Credits/
|-- CHANGELOG.md
`-- README.md