GPU Compute Rack — SysML v2 Sample Model

Author: Brandon Head — Dassault Systèmes — MBSE Industry Process Consultant
Tool: CATIA Magic Systems of Systems Architect 2026x (No Magic)
Language: SysML v2 Textual Notation (primary) | Diagrams (generated views, secondary)
Completed: March 2026

---

What This Is

A complete SysML v2 system model of a GPU compute rack, built as a self-guided learning project across six structured phases. The model is grounded in rack-scale GPU architecture (NVIDIA NVL72 as reference) but uses generic naming throughout for reusability. It covers the full SysML v2 concept set — structural definitions, connectivity, behavior, and requirements — with AI queryability as a design constraint from the start.

This is a personal learning artifact and internal capability demonstration. It is not a production model.

---

Repository Structure

gpu-rack-sysml/
├── diagrams/
│   ├── gpu_rack_act.pdf              — Action flow diagram (power-on sequence)
│   ├── gpu_rack_bdd.pdf              — Block definition diagram (part definitions)
│   ├── gpu_rack_ibd.pdf              — Internal block diagram (rack with ports and interfaces)
│   └── gpu_rack_stm.pdf              — State machine diagram (thermal management states)
├── journal/
│   ├── gpu_rack_journal.md           — Session-by-session project journal with prompt answers
│   ├── gpu_rack_model_analysis_report.md  — Link to interactive model analysis dashboard
│   ├── gpu_rack_project_narrative.md    — Two-page model narrative: decisions, rationale, extensions
│   └── gpu_rack_technical_walkthrough.md — Technical orientation document for the model
├── model/
│   └── GPURack.sysml                 — Complete SysML v2 model — all phases
├── notes/
│   ├── gpu_rack_project_plan_v2.md       — Phase-by-phase project plan with exit criteria
│   └── gpu_rack_reference_syntax_guide.md — Annotated SysML v2 syntax patterns by phase
├── .gitignore
└── README.md

---

System Being Modeled

Top-level element: rack : ComputeRack

Subsystem	Type	Multiplicity	Notes
nodes : ComputeNode	Composite part	[18]	Unified NVLink compute domain
pdu : PowerDistributionUnit	Composite part	[3]	N+2 power redundancy
cooling : CoolingUnit	Composite part	[1]	Direct liquid cooling
tor : NetworkSwitch	Composite part	[1]	Top-of-rack switch
facility : DataCenterFacility	Reference part	[1]	External context — exists independently

All 18 nodes operate as a single NVLink domain. Partial node availability is a fault condition, not a degraded mode — minimumHealthyNodes = 18 is a hard constraint, not a threshold.

---

Package Structure

GPURack
├── Definitions
│   ├── PartDefinitions         — part def for all structural elements
│   ├── AttributeDefinitions    — custom ISQ-typed attribute types
│   ├── EnumerationDefinitions  — OperationalMode, NodeStatus, CoolingType
│   ├── PortDefinitions         — PowerPort, ThermalPort, NetworkPort
│   ├── ItemDefinitions         — ElectricalPower, ThermalHeat, NetworkFrame, thermal signals
│   ├── InterfaceDefinitions    — typed flow protocols between subsystem ports
│   ├── ActionDefinitions       — power-on sequence action decomposition
│   ├── StateDefinitions        — thermal management state machine
│   └── RequirementDefinitions  — four requirement templates with formal constraints
└── Usages
    ├── StructuralUsages        — rack instantiation with all subsystems and attribute values
    ├── InterfaceUsages         — interface usages connecting subsystem ports
    ├── BehavioralUsages        — perform / exhibit on ComputeRack part def
    └── Requirements            — R-001 through R-004 with satisfy statements

Definitions and usages are never mixed. Every package has a plain-language doc /* */ comment written for machine readability.

---

Phase Summary

Phase	Focus	Key Concepts
0	Setup and Orientation	Textual editor, package, part def, doc comments
1	Package Structure and Definitions	part def, attribute def, enum def, private/public import
2	Structural Decomposition	part, ref part, multiplicity, :>>, :>, ::>
3	Ports, Interfaces, and Flows	item def, port def, interface def, conjugation (~), flow
4	Behavioral Modeling	action def, state def, first/then, perform, exhibit
5	Requirements and Satisfaction	requirement def, require constraint, assume constraint, satisfy
6	Integration and Presentation	Coherence review, diagram generation, narrative, AI readiness audit

---

Behavioral Layer

Power-On Sequence (RackPowerOnSequence) — composite action with four sub-actions sequenced via first/then. Terminal output is rackOperationalMode : OperationalMode, connecting Phase 1 enumerations to Phase 4 behavior.

Step	Action	Output
1	PDUInitialization	isPowerStable : Boolean
2	NodePowerOn	isNodesEnergized : Boolean
3	CoolingActivation	isCoolantOperating : Boolean
4	HealthVerification	rackOperationalMode : OperationalMode

Thermal State Machine (ThermalManagementStates) — three states with accept transitions driven by typed thermal signal items. ComputeRack exhibits this state machine via exhibit state.

State	Trigger	Transition
nominalOperation	ThermalAlert	→ thermalThrottle
thermalThrottle	ThermalCritical	→ thermalShutdown
thermalThrottle	ThermalCleared	→ nominalOperation
thermalShutdown	—	Terminal

---

Requirements Layer

ID	Requirement	Constraint	Assumption
R-001	Power Budget	totalPowerDraw ≤ facilityCircuitCapacity	All 18 nodes healthy and drawing power
R-002	Thermal Envelope	rackThermalLoad ≤ coolingCapacity	Direct liquid cooling active
R-003	Availability	healthyNodeCount ≥ minimumHealthyNodes	—
R-004	Operational Mode	operationalMode == OperationalMode::Off	—

All requirements formally satisfied with satisfy rackXxx by rack.

---

Key Conventions

• ISQ typing and SI units everywhere — no bare scalars. Physical quantities typed with ISQ::PowerValue, ISQ::MassValue, etc., and assigned values with [SI::W], [SI::kg], etc.
• doc /* */ on every element — written before any other content; scoped for AI queryability.
• Supplier-perspective ports — defined once from the supplier; consumers use ~ at the usage site.
• private import by default — public import only when downstream packages need re-exported names.
• Rack-level attribute promotion — subsystem attributes participating in requirement constraints are promoted to ComputeRack due to a confirmed No Magic 2026x limitation: constraint expressions in require/assume blocks cannot navigate nested part hierarchies from outside the containing usage context.

---

Open Items (Logged for Mentor Review)

1. Requirements Table tool limitation — No Magic 2026x v2 Requirements Table view does not populate with SysML v2 requirement usages. The "Add Existing" button present in the v1 implementation is absent in v2.
2. State machine diagram rendering artifact — entry; then nominalOperation in ThermalManagementStates renders an extra entry text artifact in the actions compartment alongside the correct «entry» pseudostate symbol.
3. Nested part attribute navigation in constraint contexts — rack.cooling.coolingType fails to resolve in assume constraint blocks while rack.cooling.coolingThermalIn resolves correctly in ::> connector end references. Workaround: rack-level attribute promotion.