IESS

Integrated Engineering System Structure
IMPULS3 Information Model

Integrated Engineering System Structure

A coherent engineering model that connects what a system must accomplish, which physical Building Blocks provide that functionality, and how those Building Blocks are organised into a producible physical system.

Functional ElementsWhat must the system accomplish?
Building BlocksWhich physical entities fulfil the functions?
Physical ElementsHow is the system physically organised?
Beyond the E-BOM

A product is more than a list of parts

A conventional Engineering Bill of Material primarily describes physical composition. It does not fully explain why the elements exist, which functions they fulfil, or how multiple product variants relate to one stable system architecture.

IMPULS3 therefore treats the functional structure, Building Block catalogue and physical structure as an interconnected whole: the Integrated Engineering System Structure.

The engineering definition of a system is not a single tree. It is a connected network of functional meaning, physical realisation and product composition.
One system, three perspectives

Three structures that must be understood together

Each perspective answers a different engineering question. None of them is sufficient on its own.

🔵

Functional Element Structure

The functional structure describes what the system and its subordinate elements must accomplish. Functional Elements are named as functions, using verbs and nouns.

What must the system do?
🟢

Building Block Catalogue

Building Blocks are identifiable physical entities that fulfil functions and possess their own properties and constraints. The catalogue may contain all Building Blocks needed across all product variants.

Which physical entities provide the required functionality?
🟡

Physical Element Structure

The physical structure describes how Building Blocks are grouped into physical or production modules and how the complete system is assembled.

How is the system physically organised?
The connecting element

The distinctive role of the Building Block

A Building Block is the bridge between functional intent and physical product structure.

BB

A physical entity with functional meaning

A Building Block may fulfil one or more functions and has its own physical and performance characteristics, such as mass, volume, dimensions, capacity, reliability or power consumption.

It may be internally complex and may contain Parts. However, within the IMPULS3 architecture, a Building Block does not consist of subordinate Building Blocks.

Functional identity

A Building Block contributes to the functional behaviour of the system.

Physical identity

A Building Block is an identifiable physical entity with measurable characteristics.

One functional owner

Exactly one Functional Element has a consists of relation with a particular Building Block.

Multiple functional users

Other Functional Elements may use the same Building Block without becoming its functional owner.

Hierarchy and network

Hierarchical, but not necessarily a tree

The functional and physical structures contain hierarchies, but the total engineering model is a network. A Building Block may contribute to several Functional Elements while appearing at a specific location in the physical assembly structure.

🔵 Maintain Structural Integrity
🟢 Top Bun
🟡 Upper Section

The same Top Bun may also be used by “Enable Handheld Consumption”, without changing the Building Block itself.

Relation-centric variability

Add a product variant without redesigning the model

In IMPULS3, product variants are created by changing which relationships are valid—not by copying structures or redefining existing engineering elements.

!
A new variant can be introduced without changing the definition of a single existing Node.

The functional architecture, physical architecture and existing Building Blocks retain their identity and meaning.

What is actually required to add one alternative?

0existing Node definitions modified
1alternative Building Block added
1variation point identified
1conditional alternative relation added

The default relation has no Condition. When a Condition such as vegetarian becomes valid, Condor selects the matching relation from the applicable XOR variation point.

One variation point, two alternatives
REL-01 | FE-02 | BB-03 | consists of | X-01 | -
REL-02 | FE-02 | BB-12 | consists of | X-01 | vegetarian

Why this is significant

01
The default product is not a separate variant

The unconditioned relationships already define the default configuration. There is no special “standard variant” structure to maintain.

02
Variability does not contaminate element definitions

A Functional Element remains a function. A Building Block remains a physical entity. Neither needs variant-specific wording.

03
Existing traceability remains valid

Requirements, analysis statements, properties and design information remain connected to the same stable Nodes.

04
The 150% model is still one coherent graph

Alternative Building Blocks coexist in one overcomplete model. Conditions determine which paths form a valid 100% configuration.

05
Configuration logic remains visible

Variation points and Conditions are explicit Relations rather than hidden assumptions or duplicated structures.

The distinctive choice made by IMPULS3 is not merely to support variants.It is to place variability in the Relations while preserving the independence of the Nodes.
Vegetarian condition
Top Bun
Lettuce
Tomato
Cheddar Cheese
Beef Patty
Burger Sauce
Bottom Bun

Default configuration: Classic Hamburger

Separation of concerns

Three independent modelling concerns

IMPULS3 separates element meaning, architecture and configuration logic.

1

Nodes define elements

A Node defines the identity and purpose of an engineering element independently of its relationships.

2

Relations define architecture

Relations express functional decomposition, functional use, physical assembly and other architectural semantics.

3

Conditions define configuration

Conditions and XOR groups determine which alternative Relations are valid for a selected product variant.

Why this matters for PLM

A stable architecture for changing product families

Relation-centric variability enables product families to evolve without repeatedly redefining or duplicating the underlying engineering concepts.

Architectural stability

Existing Nodes retain their identity and meaning when new variants are introduced.

Reduced duplication

Alternative configurations reuse stable engineering elements rather than copying complete structures.

Preserved traceability

Existing links to requirements, analysis and design information remain valid.

Explicit variation points

XOR groups make architectural choices visible, inspectable and configurable.

Localised change

A new variant affects only the relevant alternative Building Blocks and Relations.

150% product definition

One overcomplete Building Block catalogue can support all valid system variants.

From product definition to production

The static structure is the foundation, not the production sequence

The Integrated Engineering System Structure defines what the system is. A connected Manufacturing Process Structure can subsequently describe how instances of that system are produced.

Integrated Engineering System Structure

Defines the stable product architecture.

  • Functional Elements
  • Building Blocks
  • Physical Elements
  • Variant relationships

Manufacturing Process Structure

Defines the ordered actions required to realise the product.

  • Manufacturing Operations
  • Product States
  • Production Resources
  • Precedence and material flow
Core IMPULS3 principle

Stable elements. Explicit architecture. Configurable relationships.

The Integrated Engineering System Structure brings functional intent, physical realisation and product composition together without forcing them into a single parts tree.

New variants change the valid relationships within the architecture—not the meaning of the engineering elements.
Configuration Item: CI-PAGE-0002 | Version: 1.1 | Last controlled change: 14 August 2026 | View change history Qwerty

Loading