The concepts will be clear if I take a simple example of mechanical routes in a ship and how it gets managed across multiple hulls (ship units) over years while it evolves.
Large Product Complexity should not slow down your design team
As shown above, a typical route that a routing engineer has to design is always in context of a ship and can pass through several decks and zones in a ship. It can affect other mechanical/electrical routes and affect many other aspects of a product. It is also possible that one route may be designed by more than one designer which forces further division of a task by creating pseudo parent nodes to allow for collaboration and concurrent design.
Let us now look at changes being made to above route:
1. Change # 1 – A piece of equipment was added that required a change for Hull # 3-4 - A new revision of a route with bent pipe is added for hull # 3 and 4 replacing revision A of Route12 by revision B of Route12 for traditional product structure.
While for 4GD, you can simply add one part for a bent pipe for hull # 3 and 4 while extending reused components of the same route for hull # 1 to 4.
2. Change # 2 – Gasket material was changed for all ships. This will require a new revision for traditional product structure based route with same number of components with a different material for the gasket resulting into revision C and revision D. For 4GD based route, only one component related to Flange needs to be revised with the new revision valid for all ships while cutting back effectivity of the older revision as discontinued.
3. Change # 3 – For hull # 5, one of the pipes need to be rerouted for added equipment and a strainer needs to be added. In order to make this change, the user first needs to find the revision valid for hull # 5 and then revise it to add needed components and remove obsolete components. The ship product structure will now have revision D for hull # 5, revision B will be valid for 1 and 2 and revision C will be valid for 3,4,6,7 and 8. For 4GD, the change will require addition of new components and changes to existing ones by revising and adding effectivity as hull # 5 for them.
4. Change # 4 – affects hull # 1, 2 and 3. The valve was showing premature wear and needed replacement. For hull # 1 and 2, revision B needs to be revised to revision E and for hull # 3, revision C needs to be revised to revision F and appropriate changes have to be made. The new revisions needs to have proper effectivity while cutting back older revisions. The same change in 4GD component based design will add new components with proper effectivity while cutting back the older ones for hull numbers that this change is affecting.
The new change management concepts enables 4GD users to manage these changes at a component level in an efficiently and seamlessly (Future of Change management).
Summary for Product Structure Based Route:
Required 6 revisions to manage all changes in above example causing duplication of occurrences.
Each change required review of its entire content by all downstream consumers.
The change was to an entire collection requiring reviewers and downstream consumer to first find what was changed using compare tools.
The design change required identification of source revisions and duplicating effort for each identified source revision.
Each design task requires an impact analysis and review which has to be done for each source revision that is modified.
The same multiplication applies to other tasks related defining system interfaces, drawing sheets, technical publications, attribute changes and work packages.
The number of revisions and complexity increases for real life routes. It also increases due to sheer number of systems and routes in a big product such as ship.
Cost of change increases.
Summary for Component Based Route Design using 4GD:
Duplication is eliminated.
Change impact drastically reduces due to the fact that the changes are applied directly to affected components rather than something above it.
Management of a change and effectivity or applicability requires orchestration to ensure all updates stay packaged together due to the fact that configuration is moved from a container object (entire route in this case) to its individual components.
Identification of change is easier and therefore becomes easier to review and consume changes for downstream applications.
Avoid duplication of interfaces, connections, welds and PMI data.
This new data management approach will provide tools that enables customers to increase their productivity. There are many other areas in today’s product structure modeling that can be improved and made more efficient by the new technology. Some of the examples of use cases that benefit from this approach are product-level positioning and constraints, electrical routing, management of part data (Defining the Part Bill of Materials), defining connections, welds and PMI.
About the Author: 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.