PLM BOM management has been a frequent subject in the Teamcenter blog. Recently, we’ve introduced some key concepts and talked in more detail about BOM Management, BOM configuration management, product variant management and master data management. I’d like to continue the discussion and explore the challenges that companies face when trying to manage the product definition for massive and complex products, as well as key concpets for solving those challenges.

The product definition of massive and complex products such as ships and submarines in traditional PLM BOM systems poses many challenges. The current approach relies on hierarchical product structures consisting of many levels in a tree-like structure that captures organizational nodes as well as nodes with associated product data such as CAD files, documents and usage specific attributes. However, for defining a massive and complex product consisting of millions of parts and welds, where each individual node as well as parent nodes consisting of a collection of individual nodes that can have their own lifecycle and revisions, the traditional PLM BOM data management techniques reveal a significant number of challenges. Let us look at what those challenges are and what alternatives we offer.

Challenge # 1 Multiple Data Organization

The design and construction of complex products such as ships may go through several iterations starting from a concept design to construction phases and may span many years while data keeps evolving. The product data is accessed and authored during this time by many different departments as well as suppliers, customers and external certifying agencies. A designer working with a fresh water system may want to view related product data under a system breakdown while a safety engineer looking at a specific zone may want to see fresh water system components from a zone perspective. Multiple data organizational breakdowns are useful to CAD designers, engineers, planners, analysts and all other involved disciplines throughout the lifecycle of a product. The requirements to modify organization or adding new ones can occur at any stage of a business process and should not trigger a change to a large portion of product data.

Unfortunately, the traditional PLM BOM modeling technique (as seen on the right hand side of thepicture above) forces users to create one static hierarchy under a static set of organization types. The usage statements of parts and assemblies are duplicated under all these schemes making the task of keeping data synchronized (system, spatial, functional in picture above) very difficult. Thus, customers are either faced with a difficult choice of working with a sub-optimal organization of data or keeping multiple breakdowns in synch manually.

Challenge # 2 Efficient Access to Individual Usage of Part/Assemblies

Let us consider two simple use cases while working with traditional PLM BOM product structures where a CAD user wants to view a part in context of a ship coordinate system and create an ad-hoc CAD session consisting of a few components (as shown above in the picture). The left side depicts the first use case as indicated in order to see component 1 in absolute position, you need to traverse all the way up the tree while loading each intermediate node to the top. Each node in the parent hierarchy may have many revisions and can carry configuration information and therefore will require examining and loading many objects during this process. It may also require loading sibling nodes in some cases which can further impact the performance.

The second use case on the right side deals with a designer trying to put together a CAD session to analyze clearance for a pipe by loading all other components in its proximity. With a static organizational structure, the components found by a proximity query may be under different branches. The implication of this on such important tasks is that a major portion of the ship product structure must be configured and loaded, affecting user productivity.

Challenge # 3 Ad-hoc Design in Context

A typical task in design or engineering a complex product consisting of millions of components requires a user to find and load a very small subset of product data. For example, if a CAD user needs to make changes to a piping system in a room, he/she would need to load a piping subsystem plus objects within some desired proximity of all the piping objects. For a ship that is captured using a very deep and broad hierarchical product structure, the components may be located in many branches of a tree and as explained above, the user will end up finding and loading many more objects in a session. The task may require many days or weeks and the reference data may change many times before it is complete. The user needs an efficient way to update their work session by persisting and reusing the same recipe. The user will end up spending lot more time in this process reducing the productivity of an actual design task with the current PLM BOM approach.

Challenge # 4 Concurrent Access

The parent node in a hierarchical product structure acts as a container for its immediate children and therefore the parent object controls the access to all changes including position, geometry, usage specific attributes, effectivity and variant conditions. The parent object needs to be checked out for making any changes below it which causes other groups to wait until the first user checks in with his/her changes. The product data can be grouped together by owning user and/or you can limit the size of parent assemblies. But, this will cause the product tree to get even deeper and broader compounding difficulties for the day-to-day tasks of engineers and designers. The approval and release needs to be performed at a parent level which creates the unnecessary work of detecting changes before approval by all the reviewers in a workflow. It also increases the amount of work when the changes are reviewed by customers, suppliers and external reviewing parties. It will also increase the number of revisions/versions of the parent object since each change to a child below it requires a new version of a parent.

To address these challenges, we introduced a new PLM BOM paradigm for managing the product definition called 4GD. The technology is initially geared toward capturing 3-D design data, but as indicated in my colleague’s overview of BOM Management, the technology and basic concepts will be applied to other areas as well.Let’s take a few minutes to explore the main concepts:

Collaborative Design

A Collaborative Design or a CD is a higher level container for all the product data. The data can be authored, accessed and modified by members of all collaborating teams during the lifecycle. It enables concurrent authoring and editing of product data across many different sites as long as access to add/remove data from CD is granted.

Design Element

Design Elements describe usage of parts/assemblies in context of a CD. Some of the key characteristics of this object are:

• Has its own access privilege


• Has maturity


• Has absolute position w.r.t. product CD


• Has its own set of attributes


• Has its own revision history


• Has its own configuration criteria including effectivity and variant condition

Partition

Partitions provide a way for user to organize product data in a traditional hierarchical manner according to needs from respective disciplines. For example, ship data can be organized into a system breakdown as well as module breakdown for manufacturing. A CD can have one or more schemes for organizing data. A design element can be a member of one or more partitions under same scheme or different schemes. Partitions can be populated manually by assigning design elements or dynamically by storing a recipe against it. The design data does not change while creating and modifying the partition hierarchies.     

Subset

A subset is created to store a recipe to collect design elements of interest from a CD consisting of millions of objects. The recipe can either be based on attributes or partitions or proximity of another design element or volume. The user can create a complex Boolean formula to find and load only the relevant data for a given task. The recipe can be re-executed to find up-to-date data according to desired revision rule while honoring the effectivity and/or variant rule (For example – Include design elements from Room # 105 (sub-partition) and also in fresh water system (sub-partition in system scheme) while excluding DE that are not certified (attribute based) + also include specific DE and everything within 1m. proximity of it)

Workset

A Workset is an object that is created to manage work sessions for applications that are integrated with PLM to perform engineering and manufacturing tasks of designing, planning and analyzing. Each Workset can contain one or more subsets and the user can work with a subset of data that was captured during creation time. The data can be updated to latest by replaying the subset recipe. The subsets under Workset may or may not be from same CD and can carry its own position. Each subset collects data based on its own configuration criteria including maturity of data, effectivity and options.

We’ll continue to explore this topic in more detail in the future.Any questions or comments?Let us know!

About the blogger: Kaushik Amin is a product manager for Teamcenter 4GD and 4G foundation with over 25 years of experience in product development for CAD, CAM, Product Structure Management and Manufacturing Planning applications.