MBSE Models in Development and Semantic Data in Series Production: How a Shared Backbone Enables Faster Commissioning and Continuous Optimization on the Assembly Line
The proof of concept was a success. The rollout, unfortunately, was not. Anyone who works on digitalization projects in production environments is familiar with this pattern: digital twins, predictive maintenance, AI optimizers, and condition monitoring are convincing in pilot operations but struggle when scaled up. The cause rarely lies in the technology of individual components, but rather in the lack of an integration layer between engineering and operations.
MBSE models developed during the design phase—which are further refined through semantic data models during mass production—fill precisely this gap. They provide the common technical backbone to which all digitalization building blocks can be connected. The result: Plants optimize their peak production curve more quickly during the series production ramp-up and maintain it over the long term.
Ventum Consulting explains why this works, the concepts behind it, how MBSE extends beyond engineering, and how domain-specific data responsibility functions in operations.
Summary – Why Engineering Structure and Operational Data Go Hand in Hand
- PoC successes cannot be scaled simply by adding more building blocks: Digital twins, predictive maintenance, and AI optimizers all share a common structural problem, and none of them can be solved in isolation.
- The Kamm line defines the business case: The narrow range between the technical and economic optima is the true source of value. Achieving it is one thing; maintaining it is the real challenge.
- MBSE is more than just an engineering methodology: The technical structures developed during the design phase form the backbone that lives on in series production—provided they aren't left behind at the end of the engineering phase.
- Semantic data models make raw data meaningful and interpretable: Hundreds of anonymous sensor tags are translated into the language of the process—data points become technical factors, and noise becomes answers.
- Data responsibility is organized by business function, not by system: Data requests and management are no longer handled by IT, but by the business unit responsible for that function.
- AI scales only with structured data that has been described in technical terms: Data classified according to technical criteria is equally useful for both humans and machines—a prerequisite for scalable AI in production.
Riding the crest: The production ramp-up ends. The problem begins.
Achieving a smooth start to production is an accomplishment. But it counts for little if the plant falls below its optimal performance shortly thereafter. In practice, there are peaks and slumps, and in between lies potential that is systematically lost. Often, the problem begins sooner than expected: Anyone who asks on the factory floor where the peak performance level actually lies will rarely get a consistent answer. Production management, quality assurance, and financial control use different key performance indicators, rely on different calculation methods, and draw on different data sources. Not because no one wants to optimize, but because there is no common ground.
Why Many Digitalization Components Impress in Proof-of-Concepts but Fail to Scale
For years, digitalization has been promised as a solution for achieving a more stable comb line in mass production. The reality in many plants, however, is not a lack of digitization initiatives, but rather their failure to scale: Proof-of-concepts (PoCs) demonstrate effectiveness within a limited scope but lose their impact as soon as they are applied to heterogeneous plant landscapes, established data structures, and real-world boundaries of responsibility.
Four Structural Causes
Silo-Scope
PoCs are so limited in scope that they have no practical relevance in the factory. Attempts to apply them to real plant environments fail due to a lack of interoperability and impact.
Manual Data Validation
Data preparation works on a pilot scale—but it cannot be implemented cost-effectively in mass production. Without structured, automated data maintenance, every rollout remains a manual process.
Distributed Data Pools
Only experts can establish connections between systems. What needs to scale depends on individual people and is not supported by organizational or systematic measures. This is a bottleneck that hinders any attempt at scaling.
A Culture Clash Between the Digital and Manufacturing Sectors
Digitalization teams and production managers speak different languages, pursue different goals, and use different criteria for measuring success.
The Solution: MBSE as a Domain Structure, Semantic Data as the Translation
Two concepts interlock to form a common backbone: MBSE models during development and semantic data models during series production.
MBSE provides the domain structure
Model-Based Systems Engineering (MBSE) naturally emerges during the development process: functions, components, and interactions are systematically modeled as the language of the product. This structure describes how the product is built and how its components interact.
The key point: This technical structure is not discarded at the engineering stage. It serves as the integration layer that remains viable even in series production if it is systematically maintained.
Semantic information models extend the domain structure into production and the field
Semantic data in production means that sensor data from the MES, historian, and operating systems is not treated as anonymous tags, but is structured in the language of the process. For example, “TAG_0417, TAG_0418, TAG_0419” becomes a hierarchical, semantically enriched structure:
- Module: Filler
- Function: Level Control
- Parameter: Target fill volume
- Measured value: Actual fill level
- Status: Deviation / OK
For example, 100 tags become the five factors that influence the specific question. That’s the difference between “we have the data somewhere” and “we can answer the question.”
Functionally Structured Data Responsibility
The third, often underestimated component: Data responsibility is no longer organized by system (IT, MES, ERP), but rather by business or functional areas. Data requests are then no longer directed to IT, but to the department with subject-matter expertise, where an understanding of the underlying relationships resides.
This isn’t a new department, but a new allocation of responsibilities. It’s organized by function, not by system.
From Foundation to Impact—Three Keys to Success
- Focus instead of breadth: Build a focused module properly instead of doing everything half-heartedly. If you try to integrate everything at once, you won't be effective in any area.
- Bringing people together: people with data and models from engineering, production, and the field who are actively driving this approach. Without this coalition, any methodology remains purely theoretical.
- Technical Responsibility: Responsibility for data lies with those who understand the underlying relationships—not with IT. Everything else is simply a method for achieving that goal.
From Real-World Experience: One Backbone—Many Applications. How a Plant Engineer Achieves Methodological Breakthroughs
Background
Industry: Plant Engineering
Technical data structures have evolved historically and are system-driven. There is no consistent relationship between the engineering structure and operational data.
What Emerged from the PoC
The PoC focused on a single focus module. Three steps characterized the breakthrough:
Step 1 – Derive the technical structure from MBSE
The engineering component was structurally adopted from the MBSE model. A consistent, functionally labeled structure was created, ranging from Customer Requirements and Machine Features to Machine Configuration.
Step 2 – Functionally Segment Data Responsibility
Operational instantiation was carried out along business areas: Production Asset, Functional Zone, and Measurement Record were assigned not to IT systems but to functional responsibilities.
Step 3 – Build a semantic information model
The “Heating” focus module was modeled end-to-end, from the sensor tag to the requirement, serving as the first end-to-end validation of the methodology.
Results of the PoC
Breakthrough validated: The end-to-end chain works methodically.
Organizational structure validated: Business units, not IT, serve as data controllers.
Company-wide Data Governance Office established; rollout is underway.
What the rollout builds on
Based on the same methodological foundation, several applications are now being implemented in parallel:
- Digital Twin
- Process Simulations
- Digital Product for the Shop Floor
- Packaging Layouts
- Manufacturing Data in the 3D Model
- Integration, Process, and Design
Your Experts
The Benefits: What This Means for Four Typical Perspectives
MBSE models and semantic data models have different effects depending on their role. Four perspectives from real-world practice.
Lead Engineering – Production as a Co-Pilot
For systems engineers and development managers, this approach means that the MBSE model is not completed at the end of the engineering phase, but is intended to serve as an integration layer all the way through to series production. The investment in the model pays off many times over throughout the entire lifecycle.
Lead Production & Logistics – Engineering as a Co-Pilot
For plant managers and Heads of Digital/IT-OT, this approach means that operational data is structured by business function rather than by system. Data requests are answered more quickly and accurately, without IT bottlenecks.
Pure Production &
Logistics
For production managers, process engineers, and maintenance managers, this approach means that the control curve is defined consistently and maintained over the long term. Optimization opportunities are systematically exploited rather than addressed on an ad hoc basis.
Lead After-
-Sales
For service and after-sales departments, this approach means that field data is fed back into the same structure to serve as the basis for predictive services, data-driven contract models, and product-specific maintenance optimization.
Lead Engineering – Production as a Co-Pilot
Lead Production & Logistics – Engineering as a Co-Pilot
Pure Production &
Logistics
Lead After-
-Sales
- Talk directly with subject matter experts—no sales team involved
- Free Assessment of Your Situation and Needs
Our consulting services related to MBSE and semantic data models
Ventum Consulting supports companies throughout the entire value chain: from engineering methodology to production line optimization.
MBSE Consulting
Introduction, scaling, and continued implementation of Model-Based Systems Engineering—not as a siloed engineering discipline, but as an integrated domain-specific framework spanning the entire product lifecycle. We create the conditions necessary for MBSE models to serve as a viable integration layer all the way through production and into the field.
Semantic Data Models and Data Governance
Design and implementation of semantic information models for production use, including ontology development, domain-specific data classification, and governance structures that facilitate the transition from system-level to domain-specific data ownership.
AI in Production and Manufacturing
Production-ready AI and optimization models for throughput, quality, and stability. A combination of AI and mathematical optimization—from analysis through proof of concept (PoC) to closed-loop control during live operations.
Data Strategy and Enterprise Data Governance
Development of a company-wide data strategy with data ownership organized by business unit, clear roles, and a governance model. Includes the establishment of a Data Governance Office.
Digital Engineering and PLM
Seamless integration of engineering data, PLM structures, and production data as the foundation for scalable digitalization building blocks such as digital twins, predictive maintenance, and AI optimizers.
Change Management and Enablement
Embedding technical data stewardship in the organizational culture, building a community, and training subject-matter and production teams on new ways of working with data.
Maturity Model: Where Does Your Organization Stand Between the Sensor Tag and the Semantic Response?
Many companies know they have data. Far fewer know what questions they can answer with it. Even fewer have a clear idea of exactly where they stand on the path from raw sensor data to meaningful insights.
Level 1 – Data available, context missing
Production data is collected and stored. Historian, MES, and ERP are up and running. However, the data is stored in silos, tags have no technical meaning, and analyses are generated manually by individuals with specialized knowledge.
Typical telltale sign: “We have all the data; we just don’t know where it is.”
What’s missing: A standardized data structure, clear responsibilities, and subject-matter classification.
Level 2 – First dashboards, but no scaling
There are dashboards and initial analyses. Individual pilot projects show promise. But every new question requires additional effort because data models aren’t reusable and IT acts as a bottleneck.
A typical telltale sign: “We have a PoC that works well, but it doesn’t scale.”
What’s missing: a semantic data model, consistent structures, and subject-matter data ownership.
Level 3 – Technical structure begins to take shape, but remains within the engineering phase
MBSE is used. Engineering models are available and structured. However, the functional structure remains limited to the engineering phase. Commissioning and production operations have their own, unlinked structures. Plant employees see sensor numbers, not functions.
A typical telltale sign: “We do MBSE, but none of it makes it into production.”
What’s missing: Translation of the MBSE structure into semantic operational models; lifecycle consistency.
Level 4 – Building the Semantic Framework
A focus module has been semantically modeled. Subject-matter data ownership is being piloted. Initial data requests are no longer directed to IT, but rather to the department responsible for the subject matter. The methodology has been validated, and the rollout is beginning.
Typical telltale sign: “We’ve made the breakthrough; now it’s time to scale it up.”
What’s missing: A company-wide governance office, scalable processes, and full lifecycle integration.
Level 5 – Functionally Structured, AI-Ready Organization
The MBSE structure, semantic information models, and domain-specific data ownership are consistently intertwined. Data requests are answered in terms of business context. AI applications scale because they are built on a common backbone. The baseline is defined, measurable, and systematically maintained.
Distinguishing feature: “We can answer any optimization question with data and quickly set up new use cases.”
What’s next: Continuous development, expansion into the field and after-sales, and preparation for agent-based AI.
From Ventum Consulting's consulting practice
Future Outlook – Why the Backbone Should Be Built Now
Three developments are making the establishment of a common technical foundation based on MBSE and semantic data models a strategic competitive advantage.
AI adoption scales only with structured data
AI applications scale significantly better in production environments when the underlying data is classified by domain, quality-assured, and described in a way that allows for reuse. Semantic structures do not replace data quality, model validation, or MLOps, but they create the conditions necessary to ensure that use cases do not have to start over with manual data interpretation every time a new question arises.
Regulatory requirements are increasing
Documentation requirements, auditability, and compliance requirements under the EU AI Act, ESG regulations, and industry-specific guidelines increasingly call for structured, traceable production and engineering data. While having a robust infrastructure in place does not replace a compliance audit, it does facilitate transparency, traceability of data sources, accountability, and the reusability of evidence.
Competitive Differentiation Through Interaction, Not Through Tools
PLM and AI tools alone do not create a competitive advantage. Differentiation arises when organizations integrate their models, data, responsibilities, and decision-making processes more effectively than their competitors. Therefore, those who establish MBSE extension and domain-specific data management today are not investing in yet another tooling initiative, but rather in the ability to effectively combine digital building blocks over the long term.
Build the backbone for your digitalization components now
- From Proof of Concept to Production: We help turn isolated pilot projects into scalable solutions
- MBSE as an Integration Layer: The Engineering Structure Becomes the End-to-End Backbone
- Semantic Data in Action: Sensor Tags Turn into Expert Answers
- Technical Data Responsibility: The Real Core—We Show You How It Works
- Over 20 years of experience: in engineering, manufacturing, and digital transformation
TISAX and ISO certification apply only to the Munich location
Your message
FAQ – Frequently Asked Questions About MBSE and Semantic Data Models
MBSE describes the functional structure of a product—functions, components, and interactions—during development. Semantic data models carry this vocabulary forward into series production and map sensor data to the functional structures. MBSE is the language; semantic models are the translation into the production process.
No, but it’s a powerful catalyst. Those who already use MBSE already have the technical vocabulary. Those who don’t can also build semantic data models based on process documentation and domain expertise. The result is the same; it just takes a little longer.
No. Mid-sized plant manufacturers and process industries benefit equally. What matters is the willingness to define data responsibilities in a technical manner and to start with a single focus module—not the size of the company.
A targeted breakthrough—a module, a system, or a key process—can typically be achieved in just a few months. The trick lies in selecting the right module and building a coalition of the willing.
The PoC validates the methodology and organizational framework. This is followed by a rollout to additional modules, systems, or plants, and at the same time, specific applications (Digital Twin, Predictive Maintenance, AI Optimizer) are built on the same backbone.
The effort involved depends on the focus module and the starting point. As a rule, the methodological structure is more manageable than that of traditional data integration projects and pays for itself more quickly because many applications are built on top of the backbone.
IT provides the platform, tools, and technical infrastructure. The domain-specific semantics and data responsibility lie with the business units—Engineering and Production. This is the key paradigm shift compared to traditional data projects.
With a structured initial consultation: current situation, proposed focus module, business case, and methodological approach. Typically, this leads to a clear starting point for the first breakthrough within a few weeks.