Association toolset to provide individual controls over build behaviour and a preview

[LewisLawrence]

Currently the association functionality for managing relationships between EPMDocuments and WTParts is a bit of a black box, with obscure names for the associations that no longer accurately reflect their behaviour. Additionally the toolset does not use the standard collector, so the user interface behaves differently to the rest of Windchill and is counter intuitive to most users. It is also very limited in functionality, it does not offer individual controls of the build behaviour when creating or editing a build rule. Finally there is no way to preview and understand what a build rule will actually change, so users have to do a lot of awkward research before completing the build.

My idea is to offer a new toolset for editing relationships between EPMDocuments and WTParts, offering the ability to individually control the various build functions with clear and unambiguous terminology. This “Build Selector” would show the structure and attribute values of both objects, so that the user can preview and understand what the build rule will modify. The image attached to this idea hopefully makes the proposal clear. Here is a summary in case the image is lacking:

Representation Controls

• Default, maintain the default by always coping the representation overwriting any existing
• Additional, maintain this particular representation as an additional (secondary) leaving the default
• None, do not pass or modify any existing representations

Sync Names

• A boolean toggle to dictate when the name/descriptions of both objects must remain synchronized

Attributes

• A Boolean toggle to dictate when attributes must remain synchronized

Structure

• Up and Down, contributes to structure and builds structure down
• Up only, contributes to structure but does not build down
• None, no structure updates from

[Marco_Tosin]

Great idea Lewis!

Thanks.

[GregoryPERASSO]

Hi lewis

an addon to your idea ,

for a better understanting of Wtpart Attributes mapped to CAD parameters

We have added a custom datautility for IBAs that display an "cad icon" if it is mapped in the Build Preference

this datautiliy allow us also to control if these IBAs are read only if a CAD associated as owner link and read/write in no CAD.

[LewisLawrence]

I like your customization, that is a nice addition. Is the attribute marked in anyway or have a property to allow you to determine if it is built from CAD or not?

[DavidCobb]

I am very much in support of this improvement idea from the perspectives of user adoption and system configuration. For context, we are currently using Windchill PDMLink for CAD Data Management and are preparing to implement Parts and Change Management in addition across multiple business units.

User Adoption

Our Change process will require CAD documents to be associated to WTParts in order to drive the "Part-centric" approach moving forward. We plan to use Owner, Image and Content associations to support our range of use cases. We have already seen that helping users understand which association type is needed based on the use case is very challenging - connecting the association names to the behavior required (e.g. build structure vs. don't build structure) is not intuitive. Even for our subject matter experts who have helped define the use case data models and the appropriate association for each, they constantly struggle to remember the differences. (We have reviewed the definitions/tables in PTC's documentation for the associations numerous times, as I'm sure many others have. ) It would be great to have the capability more aligned to the specific build behavior required for a given use case.

System Configuration

From the standpoint of evaluating use cases and business requirements, having granular capability is very preferable to having bundled capability. For this topic, granular control over the key elements of CAD > WTPart synchronization (structure, attributes, visualization) in the build would be preferred over having them bundled in the different association types. Just to illustrate the concept in a different area of capability, bundled capability also creates challenges in access permissions. For example with the Administrative permission, there are use cases where you want to provide some of the bundled access but not others (e.g. give capability to Set State, but not capability to Reassign Life Cycles). Same concept for the build process - granular control over the key elements would be very preferable.