SysML Internal Block Diagram (IBD): Modeling Connections, Ports and Flows in Sparx EA

The short version: the Internal Block Diagram (IBD) shows how a block's internal parts connect — their ports, connectors, and item flows. Where the Block Definition Diagram (BDD) asks "what are the components of this system?", the IBD asks "how do those components connect and exchange?" Every IBD belongs to exactly one block defined in a BDD. In Sparx EA, you create an IBD directly from a Block element, and it inherits that block's part properties and ports. Get the typing right — on parts, ports, and item flows — and the diagram becomes the source an Interface Control Document can be generated from rather than re-authored.

The four building blocks of an IBD are Parts (instances of blocks owned by the parent), Ports (interaction points), Connectors (the physical or logical links between ports), and Item Flows (what travels along a connector). The diagram below shows how they fit together inside one parent block.

IBD purpose: the "how does it work inside" view

The BDD defines the architecture. The IBD shows it working.

A hydraulic system BDD defines: hydraulic pump, valve assembly, actuator, accumulator, reservoir. The hydraulic system IBD shows the pump output port connected to the valve assembly inlet port; the valve assembly outlet connected to the actuator inlet; the accumulator connected between the pump outlet and the valve assembly; and return lines from the actuator and valve back to the reservoir.

The IBD is the engineer's working view — the diagram they use to trace interfaces, identify integration risks, and specify connection requirements. It is not a conceptual diagram; it is a specification tool. In Sparx EA, the IBD is a first-class diagram type in the SysML MDG Technology, and every IBD is scoped to a specific block. That block's part properties, ports, and constraints are the raw material of the IBD.

Parts in the IBD

A Part in an IBD is an instance of a block that is owned by (composed into) the parent block. Parts appear as rectangles labeled with the part name and type: actuator : HydraulicActuator.

When you create an IBD from a Block, Sparx EA offers to drag the block's existing Part Properties onto the diagram. Accept this — do not create new elements in the IBD. Creating fresh elements in the IBD rather than pulling in defined Part Properties is the single most common IBD error. It produces a diagram that looks right but is not connected to the BDD definitions.

To add a part that is not yet defined:

1. Return to the BDD for the parent block
2. Add the Part Property to the block's parts compartment
3. Return to the IBD and drag the new Part Property onto the diagram

This discipline keeps the IBD a faithful instantiation of the BDD structure.

Part multiplicity. If the parent block owns multiple instances of the same block type (for example, four reaction wheels in a satellite attitude control system), the multiplicity is defined in the BDD Part Property (reactionWheel : ReactionWheel [4]). In the IBD, each instance appears as a separate part with a role index: reactionWheel[1], reactionWheel[2], and so on.

Ports: flow ports, proxy ports and full ports

SysML 1.x defines three port types. In Sparx EA, all three are available through the SysML toolbox.

Flow Port. A flow port specifies that matter, energy, or data flows through a port. It is directional — in, out, or inout — and typed by a Flow Specification that describes the properties of the flow.

When to use: physical flows (fluid, current, heat, data streams). A hydraulic line carries fluid, so use a flow port typed by a flow specification with pressure : Pressure and flowRate : VolumetricFlowRate properties. In Sparx EA: right-click a block or part on an IBD, choose Add → Flow Port, then set direction and type.

Proxy Port. A proxy port (SysML 1.4+) provides access to properties and operations of the owning block and is typed by an Interface Block. Proxy ports replaced the older standard ports and provide bidirectional or multi-feature interfaces.

When to use: complex interfaces carrying multiple signals, commands, and data items — a communications subsystem interface, for instance. In Sparx EA: right-click a block, choose Add → Proxy Port, then type the port by an Interface Block that defines what it offers and requires.

Full Port. A full port encapsulates behavior — its Interface Block defines a complete service boundary, and the owning block delegates its interaction to the port, which behaves as a separate entity.

When to use: service-oriented interfaces where the port independently manages interaction. Less common in hardware-centric MBSE; more common in software-intensive systems.

Connectors and item flows

Connectors. A Connector in an IBD represents a link between two ports — a physical wire, pipe, data bus, optical link, or logical connection. In Sparx EA, draw a connector between two port symbols. It can be typed by an Association Block that defines the physical characteristics of the connection (cable type, protocol, and so on).

Connectors can be nested: a connector between two blocks at the top level might be decomposed into a more detailed connection path at a lower level. This hierarchical decomposition is achieved by creating a more detailed IBD of the connector's type.

Item Flows. An Item Flow annotates a connector with the item that flows along it. In SysML notation, item flows appear as small arrows on the connector, labeled with the item type.

In Sparx EA:

1. Draw a connector between two ports
2. Right-click the connector and choose Add → Item Flow
3. Name the item flow and specify the conveyed item (a block or value type)
4. Set the direction (source port → target port)

Item flows are the key to interface specification. A connector with no item flow is architecturally incomplete — it says "there is a connection" but not "what crosses it." For Interface Control Document generation, every connector must carry typed item flows.

The IBD–BDD relationship

The structural discipline rule is simple: every element that appears in an IBD must be defined in a BDD.

• Parts in IBDs → defined as Part Properties in the parent block's BDD
• Ports in IBDs → defined in the block's port compartment in its BDD
• Item flow types → defined as blocks or value types in a BDD
• Connector types (Association Blocks) → defined in a BDD

This is not a convention — it is the formal SysML rule. Sparx EA's SysML validation rules flag IBD elements that are not backed by BDD definitions when you run the SysML model validator (Tools → Model Validation → SysML profile rules). Run the validator regularly during IBD development; catching IBD–BDD structural violations early is far cheaper than discovering them in a design review.

Interface Control Documents from IBDs

For defense and aerospace programs, Interface Control Documents (ICDs) are formal contract documents between system integrators. They specify exactly what crosses each system interface: physical connectors, signal types, data formats, timing, power.

When IBDs are correctly constructed in Sparx EA — with typed ports, typed connectors, and typed item flows — the ICD can be generated directly from the model.

1. Identify the boundary interface: the connector between your system block and the external system block in the System Context IBD
2. Query the model for all item flows on that connector and all associated port-typed properties
3. Generate a report from those model elements using Sparx EA's built-in document generation

The result is an ICD that stays consistent with the model. When an interface changes, you update the IBD, re-run the report, and the ICD is updated. The alternative — maintaining the ICD by hand in Word — produces documents that diverge from the model within weeks.

For programs using MIL-STD-1553, SpaceWire, Ethernet, or other standard bus architectures, model the bus as an Interface Block and type all relevant ports against it. That ensures every connection to the bus is formally specified against a common interface definition.

Frequently asked questions

Where Sparx Services fits

If your MBSE program has BDD capability but inconsistent IBD practice — interfaces specified informally, ICDs maintained in Word — Configure the Solution delivers IBD methodology, interface specification standards, and ICD generation configuration from Sparx EA. Start from where your architects work, or explore the broader MBSE discipline we support.