Product Lifecycle Digital Twin: How To Model Product Development Using xBOM Types?

Digital Twins is a trend and technology that aims to provide a virtual representation of a physical object, process, or system that spans its lifecycle, updated from real-time data, and uses simulation, machine learning, and reasoning to help decision-making. In such a way you can think about product development and manufacturing as a process, which can be modeled and later analyzed using digital tools. It can predict future obstacles in product development, such as system issues, supply chain disruption, or engineering complexity. Digital twins enable the analysis of data and monitoring of systems to head off problems before they occur, prevent downtime, develop new opportunities, and even plan for the future by using simulations.

 Earlier this year Digital Twin and its applications was a main topic discussed during CIMdata Industry Forum 2024. CIMdata analysis took the Digital Twin topic much far that you can think about. The Lifecycle Twin is a way to model a product in a perspective of its development across the entire lifecycle. Here is the initial passage from CIMdata website.

Digital Twins: Enhancing Lifecycle Performance. Initially rooted in electro-mechanical product design and development, ‘digital twin’ has expanded beyond its origins to cover comprehensive multi-attribute modeling and analysis from beyond engineering, manufacturing, and support. Multi-attribute modeling and simulation is core to CIMdata’s definition of the Product Innovation Platform, which underlies most industrial PLM strategies and implementations.

Check for more information in my article – CIMdata Industry Forum and Digital Twins in Lifecycle Performance. Many companies are researching the way digital twins can be used. Here just to give you an idea of different “digital twins”.

At OpenBOM, we are strategically focusing on how to help engineering and manufacturing companies to organize their performance using accurate data and analytics. The first step into this journey for every company is to escape from non-organized “document” management and move into the realm of “connected data”. The introduction of xBOM Types in OpenBOM Product Knowledge Graph Model is the next step in this direction.

OpenBOM Graph-based architecture of xBOM model allows to every company to build their representation of the product lifecycle and connect it with variety of important organizational activities. Today, I wan to speak about some practical aspects of this development and introduction of xBOM types. Here is a typical question asked by companies is: “How many BOM types do we need?” This query brings to mind an older question about “How many catalogs” we need to create in OpenBOM. If you haven’t seen that discussion, I recommend checking it out. Today, let’s explore catalogs and xBOM types, and how they help organize product life cycles within an organization.

Catalogs and xBOM Types

Catalogs in OpenBOM are fundamental in organizing item types, such as assemblies, electrical items, and mechanical items. They serve as a classification system for all objects within the nomenclature. xBOM types, on the other hand, are crucial for organizing these items into various virtual structures that represent different stages of the product lifecycle, including design, engineering, manufacturing, sales, and maintenance.

The purpose of xBOM types is to create a product lifecycle digital twin, representing all product information at each stage of its lifecycle. This digital twin ensures that all data is accurately organized and accessible, enabling better decision-making and streamlined processes.

Architecture of Product Lifecycle Digital Twin in OpenBOM

OpenBOM’s flexible data model allows us to organize diverse data types and virtual structures effectively. This model exists within a product knowledge graph, utilizing a multi-tenant, graph-based data structure. Each xBOM type can be virtually represented, rendering specific structures and displaying necessary information while remaining interconnected in a virtual xBOM view-based structure.

xBOM Types and Life Cycle

So, how many xBOM types do we need? There are four essential xBOM types that facilitate organizing all processes:

1. Concept BOM: Managed by the designer, the Concept BOM allows for validating the item master and all related information at the initial stage.
2. EBOM (Engineering BOM): This BOM type is the responsibility of engineers and is closely integrated with CAD systems, ensuring accurate and up-to-date engineering data.
3. MBOM (Manufacturing BOM): This BOM type is crucial for vendors and purchasing teams. It encompasses many manufacturing decisions, leading to production orders, assembly, testing, and shipment.
4. SBOM (Sales BOM): Although optional, the Sales BOM is useful for configured sales and later maintenance, aiding in customer-specific configurations and after-sales support.

These four xBOM types provide a comprehensive framework to organize and manage all stages of the product life cycle.

Concept BOM

The Concept BOM is the designer’s responsibility. At this stage, the designer validates the item master and ensures that all related information is accurate. This BOM includes preliminary information about the product, such as initial design ideas, concepts, and high-level structures. The Concept BOM is crucial for establishing a solid foundation for the product lifecycle, enabling teams to identify potential issues early and make necessary adjustments before moving to detailed design and engineering.

EBOM (Engineering BOM)

The EBOM is managed by engineers and is tightly connected with CAD systems. This ensures that engineering data is accurate, up-to-date, and seamlessly integrated with the design process. The EBOM includes detailed information about the product’s design, such as parts, assemblies, materials, and specifications. This BOM is essential for ensuring that the engineering design is correctly documented and that all components are accurately represented. The EBOM serves as a bridge between the conceptual design and the manufacturing process, ensuring that the product can be produced as intended.

MBOM (Manufacturing BOM)

The MBOM is crucial for vendors and purchasing teams. It involves many manufacturing decisions, from production orders to assembly, testing, and shipment. The MBOM includes detailed information about the manufacturing process, such as specific parts and assemblies required, the sequence of operations, tools, and equipment needed, and quality control measures. This BOM type is vital for planning and executing the manufacturing process, ensuring that all necessary components are available and that the product can be produced efficiently and to the required quality standards. The MBOM also supports cost estimation and resource planning, helping to optimize the manufacturing process.

SBOM (Sales BOM)

The SBOM, while optional, is valuable for configured sales and maintenance. It helps manage customer-specific configurations and supports after-sales processes, ensuring customer satisfaction and streamlined maintenance operations. The SBOM includes information about product variants, options, and configurations that can be offered to customers. It also supports the generation of quotes and sales orders, ensuring that customers receive accurate and timely information about the products they are purchasing. Additionally, the SBOM aids in managing spare parts and maintenance requirements, ensuring that customers receive the support they need throughout the product’s lifecycle.

Conclusion

I hope this article gives you an initial perspective of how product lifecycle can be modeled using product knowledge graph. This overview gives you a clear understanding of how xBOM types can help organize a product lifecycle digital twin. In future articles, we will dig deeper into the details and provide more examples.

For now, I invite you to REGISTER FOR FREE to try OpenBOM and see how it can benefit your organization.

Best, Oleg