Direct Answer
The Internal Block Diagram (IBD) shows how a block’s internal parts connect — their ports, connectors, and item flows. If the 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, IBDs are created directly from a Block element and inherit its part properties and ports. Key IBD concepts: Parts (instances of blocks owned by the parent), Ports (interaction points — flow ports, proxy ports, and full ports in SysML 1.x), Connectors (physical or logical links between ports), and Item Flows (the items that flow along connectors). For defence and aerospace teams, IBDs are the foundation of Interface Control Documents — the formal specification of what crosses system boundaries. Done correctly, Sparx EA IBDs generate ICDs automatically from model content.
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: pump output port connected to valve assembly inlet port; valve assembly outlet port connected to actuator inlet port; accumulator connected between pump outlet and valve assembly; return lines from actuator and valve to 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. Every IBD is scoped to a specific block. The 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 labelled with the part name and type: actuator : HydraulicActuator.
Creating Parts in Sparx EA IBD:
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 new elements in the IBD rather than pulling in defined Part Properties is the 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:
- Return to the BDD for the parent block
- Add the Part Property to the block’s
partscompartment - Return to the IBD and drag the new Part Property onto the diagram
This discipline ensures the IBD is always a faithful instantiation of the BDD structure.
Part multiplicity. If the parent block owns multiple instances of the same block type (e.g., 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], etc.
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. A flow port is directional: in, out, or inout. Flow ports are typed by Flow Specifications — elements that describe the properties of the flow.
When to use: physical flows (fluid, current, heat, data streams). A hydraulic line carries fluid — 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 → Add → Flow Port. Set direction (In/Out/InOut) and type (Flow Specification element from your library).
Proxy Port. A proxy port (SysML 1.4+) provides access to properties and operations of the owning block. It 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 with multiple signals, commands, and data items. A communications subsystem interface carrying multiple message types — use a proxy port typed by an Interface Block that defines each message property.
In Sparx EA: right-click a block → Add → Proxy Port. Type the port by an Interface Block element. The Interface Block defines what the port offers and requires.
Full Port. A full port encapsulates behaviour — the port’s Interface Block defines a complete service boundary. The owning block delegates its interaction to the full 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. The connector can be typed by an Association Block that defines the physical characteristics of the connection (e.g., cable type, protocol).
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, labelled with the item type.
In Sparx EA:
- Draw a connector between two ports
- Right-click the connector → Add → Item Flow
- Name the item flow and specify the conveyed item (a block or value type)
- Set the direction (source port → target port)
Item flows are the key to interface specification in IBDs. A connector that has no item flow is architecturally incomplete — it says “there is a connection” but not “what crosses this connection.” For Interface Control Document generation, every connector must have typed item flows.
The IBD-BDD Relationship
The structural discipline rule is: 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 will flag IBD elements that are not backed by BDD definitions if you run the SysML model validator (Tools → Model Validation → SysML profile rules).
Run the model validator regularly during IBD development. Catching IBD-BDD structural violations early is much cheaper than discovering them during a design review.
Interface Control Documents from IBDs
For defence and aerospace programmes, 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.
The generation process:
- Identify the boundary interface: the connector between the system block (your system) and the external system block (your customer’s or supplier’s system) in the System Context IBD
- Query the model for all item flows on that connector and all associated port typed properties
- Generate a report from these model elements using Sparx EA’s Document Generation or EA GraphLink Interface A
The result is an ICD that is always consistent with the model. When an interface changes, update the IBD, re-run the report, and the ICD is updated. The alternative — maintaining the ICD manually in Word — produces documents that diverge from the model within weeks.
For programmes 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. This ensures that all connections to the bus are formally specified against a common interface definition.
Frequently Asked Questions
Q: How many IBDs should a complex system have? A: One IBD per block that has meaningful internal structure. Not every block needs an IBD — leaf-level blocks (components with no sub-components) do not need internal structure diagrams. A complex aerospace system might have 20–50 IBDs, one per significant subsystem and assembly. Maintain the discipline: IBD only when the internal structure requires specification.
Q: What is the difference between a connector in an IBD and a dependency in a BDD? A: A connector in an IBD represents a physical or logical connection between specific port instances — it is instantiated. A dependency in a BDD represents a general relationship between block types — it is definitional. Connectors are in IBDs; dependencies are in BDDs. They model different aspects of the system at different levels of abstraction.
Q: Can we show behaviour in an IBD? A: No. The IBD is a structural diagram — it shows composition and connectivity, not behaviour. Behaviour is modelled in SysML Activity Diagrams, Sequence Diagrams, and State Machine Diagrams. For behaviour that is triggered by item flows, use a Sequence Diagram or Activity Diagram cross-referenced from the IBD connector context.
Q: How do we handle optional connections in an IBD (connections that may or may not exist depending on configuration)? A: Use multiplicity on connectors: [0..1] for an optional connection. Alternatively, use multiple IBD diagrams — one for each significant system configuration variant. Model the configuration variants as value properties of the parent block with tagged values (configuration : OperationalConfig), and document which IBD applies to which configuration.
Q: What is a nested IBD and when do we need one? A: A nested IBD shows the internal structure of a part within a parent IBD. In Sparx EA, you can open a block that appears as a part in an IBD and navigate to its own IBD — this shows the nested internal structure. Nested IBDs are the mechanism for hierarchical decomposition. Use them for assemblies where the internal connection structure is architecturally significant, not just implementation detail.
Q: How do item flows relate to data architecture in the TOGAF sense? A: SysML IBD item flows and TOGAF data flows are conceptually similar but operate at different levels. IBD item flows specify the items crossing physical interfaces in a system model — typically at the subsystem or component level. TOGAF data flows specify data movement between applications in an enterprise architecture. For integrated programmes (e.g., defence prime contractors doing both enterprise and systems architecture), maintaining traceability between the two models via shared data entity definitions is good practice.
Q: Is there a standard for IBD notation in defence programmes? A: Multiple standards reference SysML IBD notation. In the United States defence context, DoDAF’s SV-3 (Systems-Systems Matrix) and SV-6 (Systems Data Exchange Matrix) can be derived from IBD content. MODAF (UK MoD) uses equivalent views. The key discipline is that the IBD must be sufficiently detailed — with typed item flows — for these views to be generated rather than authored separately.
Q: What Amplify engagement deliverables relate to IBD practice? A: The Amplify MBSE track includes IBD methodology training, interface specification templates, ICD generation configuration in Sparx EA, and the Port and Item Flow type libraries. If your team has BDD capability but IBD discipline is inconsistent, Amplify delivers the standards and working examples to bring IBD practice up to the level where ICDs can be generated from the model.
Next Step
If your MBSE programme has BDD capability but inconsistent IBD practice — interfaces specified informally, ICDs maintained in Word — the Amplify engagement delivers IBD methodology, interface specification standards, and ICD generation configuration from Sparx EA.
