HoTT-Inspired Component Equivalence #
Defines PortEquiv (port interface equivalence), ComponentEquiv (component equivalence),
Substitutable (substitutability), and transport_wellFormed (design-space transport).
Correspondence with HoTT #
- Equivalence (A ≃ B) →
ComponentEquiv - Univalence (A ≃ B → A = B) → Substitutability principle
- Transport →
transport_wellFormed
PortCompatible: two ports are compatible (flowType and direction match).
Equations
Instances For
PortEquiv: two port lists are structurally equivalent. In HoTT terms, PortBundle(A) ≃ PortBundle(B).
Port counts match
- forward (p : Core.PortDef) : p ∈ ports₁ → ∃ (q : Core.PortDef), q ∈ ports₂ ∧ PortCompatible p q
Forward compatible mapping ports₁ → ports₂
- backward (q : Core.PortDef) : q ∈ ports₂ → ∃ (p : Core.PortDef), p ∈ ports₁ ∧ PortCompatible q p
Backward compatible mapping ports₂ → ports₁
Instances For
PortEquiv is reflexive.
PortEquiv is symmetric.
PortEquiv is transitive.
ComponentEquiv: two PartDefs are equivalent. Port interfaces are equivalent and invariants are biconditional.
Port interface equivalence
Invariant biconditional
Instances For
ComponentEquiv is reflexive.
ComponentEquiv is symmetric.
ComponentEquiv is transitive.
Substitutable: A can substitute for B (upward compatible). A weaker condition than ComponentEquiv.
b's invariant implies a's invariant
- portsSubset (p : Core.PortDef) : p ∈ a.ports → ∃ (q : Core.PortDef), q ∈ b.ports ∧ PortCompatible p q
All ports of a exist in b
Instances For
ComponentEquiv → Substitutable (special case of bidirectional equivalence).
Substitutable is transitive.
Replacing a component with an equivalent one preserves invariants. MBSE version of HoTT transport: (A = B) → P(A) → P(B).