Given the use of a Design Partner business model where the majority of the design/engineering work is done in a single Teamcenter instance by Design Partners of various expertese (structural, electrical, controls, etc.), the Design Partners collaborate within a single product structure. The OEM, of course, is able to see all objects. Each Design Partner must allow interface/integration data to be seen by the other Design Partners. Addtionally, each Design Partner requires that non-interface/integration data not be seen by the other Design Partners.
PROBLEM STATEMENT (simplified):
Traditionally, each Design Partner creates interface models to be seen by the other Design Partners. This addes complexity to the single product structure and to the access rules. How is this best managed?
Option 1 - Create an interface Item for each assembly
Option 2 - Create interface Datasets for each part
Option 3 - Design Partners indicate interface data and access grant read access to the other Design Partners
Option 4 - Other
Solved! Go to Solution.
@RandyEllsworth Yes I have discarded the CAD-Part alignment concept as too complicated for our business model.
You are spot-on with your description of the problem, as you call it, "modular design w/ interface declarations".
At first glance I have a couple of questions. First, at what level should users declare an interface?
1. Separate interfaces from details at the Item level
pros - users don't need to learn revision rules
cons - user must manage effectivity of both interfaces and details and the BOM gets really cluttered
2. Separate interfaces from details at the Item Revision level
pros - the part numbers in the BOM remain the same
cons - users must learn to correctly use revision rules
3. Separate interfaces from details at the Dataset level
pros - this is the simplest from a data model perspective
cons - since CAD systems have hard coded methods of Dataset selection, this would require customization
If option 2, manage interfaces vs. details at the Revision level, is selected then the second question is, how to differentiate the interfaces from the details.
1. An Item Revision level Property is be used to designate the interface revision
pros - easy to designate which revision is the interface
cons - although if revision rules are setup correctly this should return the latest interface, this may be confusing to users
2. An Item Revision ID with a 'dot' (period character) and then a suffix is used to designate the interface revision
pros - pretty intuitively obvious which are the interface revisions
cons - it is a bit complex and users may frequently get it wrong
3. A special Status is applied to the interface revision
pros - it's pretty clear
cons - it may not be intuitively obvious in the CAD system
My company has a requirement for Teamcenter to provide their Design Partners with a method to indicate what can be seen by the other Design Partners and what can only be seen by the OEM. I’m strongly considering creating a mandatory Item Revision Property with a YES/NO LOV that defaults to YES. YES indicates it can be seen by the other Design Partners and NO is used by Access Manager to restrict who can see it.
When considering creating this Property, red flags go off in my head since this seems like it should be an OOTB feature and I’ve seen enough flotsam & jetsam Properties that I’m concerned this may become one.
I’ve seen in other company’s schema, this kind of thing included in an Item Revision LOVs that include things like; Installation Assembly, Assembly, Detail, Supplier Part, and Interface Part. But the problem with this common company approach is it is an “either/or” solution. In fact, the Interface=YES/NO is applicable whether or not it is an Installation Assembly, Assembly, Detail, etc.
What do you think? Is this a reasonable Property to create?
Right on Randy! Thank you for jarring my thoughts loose. I am already using ADA IP Licenses for export control but what I think (thanks again) I need to do is use the OOTB IP_Classification Property by adding in interface-only value to the LOV.