Fundamental MBSE Diagrams

Why This Matters

In Model-Based Systems Engineering, diagrams aren't just pretty pictures—they're the primary language you'll use to communicate complex system designs. You're being tested on your ability to select the right diagram for the right purpose, whether you're capturing requirements, modeling behavior, or defining structure. Understanding when to use a Block Definition Diagram versus an Internal Block Diagram, or why a Sequence Diagram captures something a State Machine Diagram cannot, separates competent systems engineers from those who just memorize definitions.

These nine SysML diagrams fall into three fundamental categories: structure, behavior, and requirements. Each category answers different questions about your system—what it's made of, how it acts, and what it must do. Don't just memorize diagram names; know what engineering question each diagram answers and how they connect to form a complete system model.

---

Structure Diagrams: Defining What the System Is

Structure diagrams capture the static architecture of your system—the building blocks, their properties, and how they're organized. These diagrams answer the fundamental question: "What is this system made of?"

Block Definition Diagram (BDD)

• Defines system taxonomy and composition—shows blocks (components), their attributes, operations, and hierarchical relationships
• Establishes inheritance and associations between block types, making it your go-to for understanding system modularity
• Foundation for all other diagrams—blocks defined here appear throughout your model, so BDD errors propagate everywhere

Internal Block Diagram (IBD)

• Reveals internal wiring of a single block—shows parts, ports, and connectors that enable component interaction
• Visualizes data and control flow between internal elements through typed flow ports and interfaces
• Critical for integration analysis—exposes interface mismatches and communication pathways before implementation

Package Diagram

• Organizes model elements into logical containers—manages complexity by grouping related blocks, diagrams, and requirements
• Shows dependencies between packages to reveal coupling and support modular development
• Essential for large-scale systems—without proper packaging, models become unnavigable chaos

---

Behavior Diagrams: Modeling How the System Acts

Behavior diagrams capture the dynamic aspects of your system—what happens over time, in what order, and under what conditions. These diagrams answer: "How does this system behave?"

Activity Diagram

• Models workflows and process logic—shows sequences of actions, decision points, and parallel execution paths
• Captures control flow and object flow using swim lanes to assign responsibilities to different actors or components
• Best for functional decomposition—breaks down complex operations into discrete, analyzable steps

Sequence Diagram

• Shows message exchanges over time—vertical lifelines represent objects, horizontal arrows show interactions in chronological order
• Scenario-specific by design—each diagram captures one particular execution path through the system
• Reveals timing dependencies and helps identify race conditions or synchronization requirements

State Machine Diagram

• Models lifecycle behavior of a single element—shows discrete states, transitions, and the events/conditions that trigger changes
• Ensures completeness of behavioral logic—forces you to consider every possible state and what happens in each
• Critical for safety-critical systems—undefined states cause real-world failures

---

Requirements and Analysis Diagrams: Capturing What the System Must Do

These diagrams bridge the gap between stakeholder needs and technical design. They answer: "What must this system accomplish, and how do we prove it?"

Use Case Diagram

• Captures functional scope from the user's perspective—shows actors (users, external systems) and the use cases they interact with
• Defines system boundaries explicitly—clarifies what's inside versus outside your system of interest
• Starting point for requirements elicitation—validates that stakeholder needs are understood before detailed design

Requirements Diagram

• Visualizes requirements and their traceability—shows relationships like deriveReqt, satisfy, verify, and refine
• Enables impact analysis when requirements change by revealing downstream dependencies
• Supports verification planning—links requirements to test cases and design elements that satisfy them

---

Specialized Analysis Diagrams: Quantifying and Allocating

These diagrams support engineering analysis and resource management—connecting your logical model to physical reality and mathematical constraints.

Parametric Diagram

• Expresses mathematical relationships between properties—uses constraint blocks to define equations like $F = ma$ or $P = IV$
• Enables trade-off analysis by showing how changing one parameter ripples through the system
• Bridges SysML to analysis tools—constraint equations can drive simulations and optimization studies

Allocation Diagram

• Maps logical elements to physical resources—shows how functions, behaviors, or requirements are assigned to components
• Reveals resource conflicts and utilization—identifies when multiple functions compete for the same hardware
• Critical for architecture decisions—supports "build vs. buy" and platform selection trades

---

Quick Reference Table

---

Self-Check Questions

1. You need to show how data flows between the processor, memory, and sensors inside a navigation unit. Which diagram would you use, and why wouldn't a BDD work for this purpose?

2. Compare and contrast when you would use a Sequence Diagram versus a State Machine Diagram. Give an example scenario where each would be the better choice.

3. A stakeholder asks you to prove that all safety requirements are addressed by your design. Which two diagrams would you combine to demonstrate this traceability?

4. Your system has a constraint that power consumption must stay below 50W, where $P = \sum_{i} V_i \cdot I_i$ for all active components. Which diagram type captures this relationship, and how does it connect to other model elements?

5. You're organizing a model with 200+ blocks across multiple subsystems. Which diagram helps manage this complexity, and what relationships does it typically show?