Parallel Revision Driving in Teamcenter PLM

GEA Farm Technologies
Implementation for Rapid Product Design
Matthias Ahrens – Technical Solutions Manager
100164 BU Dairy & Farm Equipment – BU Support
2015-03-02
Parallel Revision Driving in Teamcenter

GEA Farm Technologies2 2015-03-02 / Parallel Revision Driving in Teamcenter / M. Ahrens
• Review approach to shorten concept and design phases
• Adoption of classic methods in PLM suites
• Review implementation of “Revision Rules” in Teamcenter PLM
• Present “Override Folder” option in concurrent design approach
Intention

• Time to market is an increasing criteria.
• Assigning massive, additional resources achieves limits, if data
management layer and processes are operating non efficient!
• Fast fallback scenarios can be realized by driving multiple, alternative
designs in parallel during the early concept and design phases.
• Concurrent design scenarios can help to drive multiple concepts in
parallel to a stage, where the best alternative wins the race.
Abstract
Source: www.slotracinglemans.com

• A lot of disciplines have to be tied together in modern product
development projects (e.g. software, electronics, mechanics).
• Concurrent and agile methods like SCRUM are requesting a total
transparent information backbone.
• Various solution alternatives have to be considered from startup.
• The timestamp, when a final definition for the product structure exists,
moves closer to the final production scenario.
The challenge
Source: www.esa.int
European Space Agency‘s
Concurrent Design Facility
Source: agilefragile.com
Agile methods:
e.g. SCRUM process

• To adopt the classical “morphological matrix” principle in Teamcenter
by using item revisions as representations for the various solution
alternatives.
• Provide the “override folder” option for revision rules to the project
team to manage the product configuration on their own.
• The team can combine various alternatives on their own, regardless
of release status flags.
The idea
Source: edu.volpe.ch

• The intention is to drive multiple alternative design revisions in parallel
in the early stages of the project to shorten the time for iterations.
Parallel revision driving principle

• The main product
structure is defined
by standard items
• The different
alternative solutions
for each module are
stored as revisions
• The team can
reference specific
revisions into
“override folders”
• Various revision
rules exists to run
“What would happen
if …?” scenarios.
Parallel revision driving in detail

• In addition to a default revision rule, which is operating primary on
status flags, a few alternative revision rules are prepared.
• The alternative revision rules are running the same priority order like
the default revision rule with the exception of an “Override Folder”
term in front.
The revision rules
Default Revision Rule
Preset for all user by preference
TC_config_rule_name
Alternative Revision Rule
With a specific “Override Folder” option upfront
Can be selected by users in NX or PSE

• The override folders are defined with global modification access for
every team member.
• The users are able to cut and paste revisions of interest to the
different override folders on their own resp. on project circumstances.
The override folders

• While revisions representing alternatives, the revision rules can be
used to review various combinations of alternatives for the modules.
The usage

• To achieve a proper cycling between the various alternatives
(Revisions) the assembly constraints between the modules should be
assigned to datum coordinates systems, which were copied into all
alternatives upfront.
Hints: Assembly Constraints

• This allows an accurate solving of the constraints, even if there exists
significant geometrical deviations between the alternatives.
Hints: Assembly Constraints

• The revision rules are treating each item on its own independently
from the next higher level sub assembly or any other intermediate
assembly levels!
• As effect the user can simulate “What would happen if …?” scenarios
on the end item level without the need to modify entire sub assembly
structures!
• It is important to train the user base on the various, possible behaviors
of product structure assembling scenarios, if they starts dealing with
revision rules!
Hints: Sub Assemblies

• Instead of coding MRP stages like “Prototype”, “Released to
Experimental” or “Released to Supply Chain” implicitly inside the
revision schema a full alpha or numerical schema without any
sequential constraints should be used!
• MRP stages should be reflect by different options like status flags or
in ERP framework!
Hints: Revision ID coding
X = „Release to experimental“
A = „First release supply chain“
….

• An easy to use status schema and process should be applied, which
offers parallel revision scenario in early project stages!
• As example:
• The PLM status reflects the “Released to ERP” status for drawings only!
• No back coding of plant specific MRP status flags to PLM site.
Hints: Status schema

• In addition to all automatic notification tools and capabilities of modern
PLM and ERP frameworks the team internal communication is the key
to drive projects to success stories!
• For the Parallel Revision Driving method the following information are
essential on internal communications:
• Item ID?
• Revision ID?
• Revision Rule?
Hints: Communication
Revision Rules
RevRule 1 = „Concept combination A“
RevRule 2 = „Concept combination B“
….

• Controlled by Items:
• Advantages:
• Maximum flexibility
• Access control can be handled
totally independent
• Disadvantages:
• Switch of alternatives inside
assembly requires large
maintenance effort (e.g. Assembly
constraints).
• BOM management effort increases
• Possible alternatives are not tied
together
Other option for managing alternatives
• Controlled by Revisions:
• Advantages
• Faster switch between alternatives
inside assemblies by revision rules
• Alternatives are tied together under
one item
• “What would happen if …?” checks
can be accomplished very fast.
• Disadvantages
• Communication about dedicated
revision rules required within the
team
• For coexistence of alternatives a
“Save as new item” is required at
the final end.
versus

Other revision techniques
• Teamcenter offers additional options for configuring structures:
• Occurrence effectivity (Not in use right now)
• Classic Variants (Not in use right now)
• Modular Variants (Not in use right now)
• Baseline (Not in use right now)
• …

• The system landscape of the GEA segment Farm Technologies
consists of a strong SAP backbone, which is utilized to manage and
guide all ERP relevant data and processes.
• To support early product development phases a 4Tier Teamcenter
PLM backbone is in place with a connection to NX as CAD authoring
tool.
• Entire architecture is spawning multiple departments across various
global locations.
The system landscape
SAP T4S
Teamcenter
8.3
NX
7.5
Product design: Mainly plant neutralProduction execution: plant specific

• In comparison to other processes (e.g. ETO) the GEA Farm
Technologies is running a product development process, which is
starting parallel to the autonomous product execution process.
• The product development process ends with adopting the new
product into the standard catalogue of product offerings.
The process landscape
Product development process
Production execution process

212014-01-13 / PLM Implementation at GEA FT / M. Ahrens

Parallel Revision Driving in Teamcenter PLM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Parallel Revision Driving in Teamcenter PLM

Similar to Parallel Revision Driving in Teamcenter PLM (20)

Recently uploaded

Recently uploaded (20)

Parallel Revision Driving in Teamcenter PLM