Cancel
Showing results for 
Search instead for 
Did you mean: 

Best Practices: How to accommodate interfaces within a Collaborative Product

BACKGROUND:

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

9 REPLIES 9

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Solution Partner Esteemed Contributor Solution Partner Esteemed Contributor
Solution Partner Esteemed Contributor
Modular design w/interface declarations is the only way I know of to accomplish what you seek. Where each Design Partner owns a Module (part of the overall assembly). The Module could have a Project attached which helps isolate the data. However, the interface(s) should be specified by you and any changes to the interface agreed to (workflow/approved) by all concerned. The interface could be as simple as a skeleton/sketch waved into their model or as complicated as a specification document(s) tied to requirements (w/trace links). The interface, or interfaces since there could be more than one, would likely include an envelope, weight and power restrictions in the specification. Those parameters were likely part of the bid.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Solution Partner Esteemed Contributor Solution Partner Esteemed Contributor
Solution Partner Esteemed Contributor
I assume that you've already reviewed the CAD-Part alignment and discarded the concept.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

@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

 

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Solution Partner Esteemed Contributor Solution Partner Esteemed Contributor
Solution Partner Esteemed Contributor
Yeah, I don't know. I've been down this road before and we ended up with more than 20 Item types and it never really worked to my satisfaction, way too complicated. We abandoned our approach before we had any good answers. The easiest way to handle it was with CAD-Part separation so that the Part contained the interface definitions and the CAD could be separated appropriately.

We never had a really good answer on where to modularize and took our best guess based on what was being farmed out to whom. The new CAD-Part alignment shows a leaf-node where the module is instead of the whole breakdown which made this approach easier.

You might be able to create a "skeleton" type to hold the interface (usually a lines or a sheet but not the whole envelope) and it gets complicated from there. You may think the CAD-Part is too much stuff until you get farther down this road and realize how much other stuff you are creating without it. I advise contacting a Siemens Product Manager.

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

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?

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Solution Partner Esteemed Contributor Solution Partner Esteemed Contributor
Solution Partner Esteemed Contributor
Feels like you might want to employ the ADA license for IP instead?
https://docs.plm.automation.siemens.com/tdoc/tc/12.2/help#uid:xid1256816:index_plm00101:id1124492:id...

Randy Ellsworth, Teamcenter Architect, Applied CAx, LLC
NX 11 | SW 2016 | Creo 4 | TcUA 11.4
Evaluating: AW 3.4

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

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.

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Valued Contributor
Valued Contributor

What about the use of IP Classification?

Re: Best Practices: How to accommodate interfaces within a Collaborative Product

Valued Contributor
Valued Contributor
Sorry Randy, I didn't see that you came with this solution already