Summary: 2.6.3.2 How does architecture address relationship propagation by the factory methods? “copy forward”

Summary: Problem: The DocumentRevision (2.7.3.4), DesignSupplier (2.7.3.3) and
PartSupplier (2.7.3.17) relationships inherit from PdmReferencesRelationship.
These relationships have no specified attributes, and
PdmReferencesRelationship is not Attributable. But the factories for
these relationships take a PropertySet parameter. How does the client
subsequently reach any property values so attached?
A similar problem exists with the PartData, PartDataIteration,
PartStructure, PartStructureIteration and PartMasterComposition
relationships (which inherit from PdmContainmentRelationship), but a
previous issue recommends deletion of the factories for Containment
relationships.
A related problem exists for Alternate and Substitute and Usage
relationships, which also inherit from PdmReferencesRelationship
and are not Attributable. In their case, only the properties
defined as "attributes" in the specification are accessible.

Summary: Problem: The role names in the IDL and would-be CDL are NOT the same
as the role names in the UML in section 2.7, e.g. UML prcl_of_dr
is interface PrclOfDr.

(In most sections, the role names do not appear in the UML at all.
The only other section in which the role names appear in the UML
model is 2.2, and in that section the UML and IDL match.)

Recommendation: Either remove the role names from the model in 2.7.2
or spell them to match the IDL.

Summary: Problem: The DocumentRevisionRelationship appears to be a general-purpose
mechanism for relating Documents to Parts, in that it is many-to-many.
And yet it specifically relates Part Revisions (PRCL) to Document
Revisions rather than Document Masters. It seems that two ideas have
been mixed here:
a) the relationship that binds a definitive Document to the Part,
such that each Revision of the document describes a Revision of the
part, e.g. the part geometry model; and
b) a general-purpose relationship that attaches arbitrary
Documents to one or more Parts, such as analysis reports, Issue
documents, design recommendations, etc.

Summary: Reference: PDM Enablers 2.7.3.2, 2.7.3.20

Problem: As modelled, AssemblyComponentUsage inherits from
SecurityClassifiable, but Usage does not. If Usage is ever to have other
subtypes (which is the only reason for separating AssemblyComponentUsage),
the other usage relationships (such as MakeFrom) might also be classified.
Usage should inherit from SecurityClassifiable, and AssemblyComponentUsage
should inherit that from Usage. When fixing this in the UML, "Classifiable"
should be properly spelled "SecurityClassifiable".

Summary: Reference: PDM Enablers 2.7.2

Problem: Usage inherits from PdmReferenceRelationship and Node, but these
inheritances do not appear in the UML diagram in 2.7.2. They should.

Summary: The names of the relationships are unintuitive, such as prcl… The rest of the document does not use abbreviations such as these, why start here?

Summary: 2.7.1 Concerned that the product structure is at too low a level in the hierarchy. This could be because the module name does not reflect the model, which is part structures. The abstract product functional capabilities are described in configuration management (2..11)

Summary: Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.
2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas

Summary: 2.3.3.9 How is this related to ItemRevision::create_next_revision?

Summary: Clarify and expand the text that explains how or why ECIs yield ECRs.

Summary: Add a "do it by" (or "effectivity") attribute to EngChangeOrder (2.9.3.5), which designates a target date for Engineering to complete the changes.

Summary: Section 2.9.3.1 All roles are defined, therefore, non-issue for this part.

Summary: Again in 2.7.3.2 description of reference_designator attribute talks about the as_required attribute. Is this the approximate attribute from PdmFramework::Measurement or a new attribute not specified?

Summary: The create method on the ItemSolutionFactory interface should raise
ITEM_CREATE_EXCEPTION

Summary: Problem: The data type of attribute ProcessStep::duration is "string", but
duration is a quantity of time, and should be represented as a Measurement
type.

Summary: Reference: PDM Enablers 2.7.3.20

Problem: The Assembly and Component Role interfaces are defined in 2.7.4,
but not in any IDL snippet in 2.7.3. They should be defined in 2.7.3.20
(Usage), which is the parent relationship.

Summary: ISSUE #10 REF: 1.12.3 Develop Product Definition
Manage Libraries of Existing Modules (Parts)

3. Define new part types.
By a Parts Classification system.

Should include integration to third party classification tools (i.e. Aspect).

[ASPECT is a classification tool used by the electronics industry. Its functionality includes searches on product metadata.]

Summary: ISSUE #9 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC)

Does the design support a change process whereby workflow management is jointly owned by PDM and WORKFLOW? Consider this scenario: a REA is submitted for a change in the product design. The request is accepted and elevated to an ECR. So far, we"re under the purview of PDM. However, the work behind changing the associated 3-D CAD model would be adminstered by WORKFLOW. When finished, the new model is distributed for review and approval. Each system must coordinate their respective work activity with one another.

Summary: ISSUE #20 REF: 1.15 Other Information

Other materials are not provided as part of this proposal.

How about embedded software (test software and process control software associated with the part)? Is there any software process management tool interface strategy (i.e. Clear Case, PCMS, etc.)?

Summary: AP203 requires a specific revision of an assembly specification to refer to specific revisions of the component parts. This structure model is intractable in a concurrent engineering work-in-progress environment, because all the parts of an assembly are undergoing simultaneous rapid versioning in each aspect of their descriptions.

This is a very important point and this discussion needs to be tied to the product"s status within an organization"s life cycle model.

Summary: ISSUE #15 REF: 1.13.4 ERP

Add the following bullets:

· Provide item master ownership strategy by attribute between PDM and ERP systems.
· Provide item master ownership strategy based on product life cycle between PDM and ERP systems.
· PDM and ERP systems need to be able to view each other"s BOM views.
· System of record strategy need so meet individual organization"s needs.

Summary: ISSUE #14 REF: 1.13.3 CAD

Add the following bullet:

· Able to convert native CAD file into neutral image (e.g., PDF, PostScript) when a view is requested. Can handle complex file stuctures (i.e. 3d CAD).

Summary: ISSUE #8 REF: 1.11.3 Workflow , 1.14.4 Workflow Management Coalition (WfMC)

How does SWAP apply ?

[SWAP stands for Simple Workflow Access Protocol. As I understand it, it is a protocol for exchanging workflow information. This may be more pertinent for the BODTF.]

Summary: ISSUE #7 REF: 1.9.8 Test, Maintenance, and Diagnostic Information

Is this within the scope of PDM or in the MES domain?

[Equipment maintenance is definitely MES. Product diagnostics may employ FMEA, which seems to fall under P/PE scope.]

Summary: ISSUE #12 REF: 1.12.6 Develop Process Design and Procurement Agreements
Develop Manufacturing Facility Plan
Is this within the scope of PDM ????

Summary: ISSUE #11 REF: 1.12.5 Develop Product Design
Develop Part Design
3. Provide feedback to other designers when changes to their parts would improve the overall design.
EngIssueItem to create an issue object.
EngChangeAffect to associate it to the questionable specifications.

ERP integration at this stage is crucial!

Summary: ISSUE #6 REF: 1.9.7 Configuration Management

How are revision rules addressed?

Summary: ISSUE #5 REF: 1.9.5 Product Structure Definition

BOI or BOM perspective?

[Motorola places emphasis on a Bill of Information; that is, product information that goes beyond the traditional notion of BOM. A BOI encapsulates BOM as well as process specifications, test programs, recipes and other manufacturing engineering objects.]

Summary: ISSUE #4 REF: 1.9.4 Document Management

How about viewer technology? Native and neutral images. Grouped files (i.e. 3d CAD models)?

Summary: ISSUE #3 REF: 1.9.3 Manufacturing Implementation

Is this just a BOM view by the MES? There could be much more here (ERP has one view; engineering another).

Summary: ISSUE #13 REF: 1.12.6 Develop Process Design and Procurement Agreements
Procure Machine Tools, Firm Tools and Services
Is this a workflow/ERP issue or a PDM issue?

[May be within the scope of PDM if production tooling is tied to a part of assembly and is tracked by an engineering tool.]

Summary: ISSUE #16 REF: 1.14.2.1.1 Differences in Purpose

Modify bullets as follows:

· Store (check in) and retrieve (check out) product "documents" and structures.

Summary: In the Manufacturing Implementation module there is a relationship between a
ProcessRevision and the ProductRevisionChangeLevel. There is also a need for
a relationship between the ProcessRevision and the
Usage Relationship for defining Assembly Process Plans. This allows you to
specify a Part specific process
plan using the PartProducedByProcessRevision and Use this ProcessRevision to
Usage relationship to specify
Assembly Process plans.

Summary: There"s a problem creating PartDataRelationship, PartDataIterationRelationship,
PartStructureRelationship and PartStructureIterationRelationship objects.

Unfortunately neither PartData nor PartStructure inherit from CosGraphs::Node
in any way. This makes connecting a CosGraphs::Role-derived interface (like
PartStructureOfPrcl) pretty difficult .

I suggest to make both PartData and PartStructure inherit from
PdmFramework::ManagedEntity. This would also provide the ability
to add attributes and identifiers via the Attributable and Identifiable
interfaces.

Summary: The documentation describes the Vault attributes as
being read only. The actual IDL code shows them
as being read - write!

Summary:
2.10.2 Similarly, why do PRCLs reference ProcessRevisions direct not via their PartDataIterations? This relationship could be pushed down to the PartDataIteration level allowing closer tracking of the Manufacturing process for a Part. Paul J .

Summary: 1.14.1 Should we at a later date define relationship to RM-ODP?

Summary: In "#include" statements, The IDL published in the PDM Enablers specification uses file names for most of the CORBA Services that are different than the file names used in "#include" statements by the CORBA Services IDL published on the OMG web site.

For example, PdmResponsibility.idl has the following statement:
#include <CosLifeCycle.idl>
and the published IDL for Compound Life Cycle has
#include <LifeCycle.idl>

To compile PDM Enablers IDL with the published CORBA Services IDL, one of the sets of IDL needs to be hand-edited to be consistent with the other. The PDM Enablers IDL should be changed to be consistent with the published CORBA Services IDL. This problem originally arose because there are apparently no published official file names for the CORBA Services IDL files.
.

Summary: D) In the Configuration module, the ProductRootToComponent-Relationship should be changed to
run from a ProductClass to a ProductComponent. We see the need to be able to freely associate
ProductComponents to ProductClass definitions. Currently the ProductRootToComponent runs
from ProductComponents only to ProductRootClasses, therefore causing heavy limitations.This
relationship should also have it’s cardinality altered from currently 1:n to a more flexible m:n,
allowing ProductComponents to appear in many ProductClasses, and to associate many
ProductComponents to a ProductClass, which is how it is used by many of our customers
especially from the automotive section.

Summary: In the Salt Lake city meeting Ed brought up a point that Revisions
cannot be created independent of the Master and the Iteration cannot
be created independent of the Revision to which it belongs.

As a result the Factory for the Master - to - Revision relationship
does not exit and the create function for the revision takes the
Master as a parameter and also creates the MasterRevision
relationship. The same is also true for Revision to Iteration
Relationship. eg BaselineRevisionFactory - The create function takes a
BaselineMaster as a parameter and creates the
BaselineMasterComposition Relationship.

This behaviour has been duplicated in the Master-Revision-Iteration
relationships of most of the modules expect the Product Structure
Definition. In the ProductStructureDefinition Module the following
relationships should not have factories:
PartMasterComposition
PartDataRelationship
PartStructureRelationship
PartDataIterationRelationship
PartStructureIterationRelationship

Taking this principle one step further we can say that this behaviour
is true for all Containment Type of relationships (Black Diamond). If
so then there are a few other places where this applies these are
Change Management Module:
Deliverable relationship
ChangeDescription relationship

Configuration Management Module
SpecificationCategoryComposition Relationship

Summary: The IDL shown in a few modules contain illegal usage of the
keyword "context" and cases of type/variable names, which
differ only incase. Both facts reperesent illegal IDL (but have
only be detected by one compiler....).

Summary: There are interfaces for PartData, and PartDataFactory in the PdmProductStructureDefinition module. A Client uses the PartDataFactory create operation to create a PartData object and give PartData object attributes. Once the attributes were add to PartData object, there is apparently no way for the client to get them out or change the attributes" value. The same issue exists for PartStructure too.

It does not make much sense to assign attributes through the PartData and PartStructure interfaces. They are grouping and control interfaces which really exist only to provide separation between structure and data so that they can be separately iterated, and to provide navigation from PartRevisionChangeLevel and the different (two) types of iterations (PartDataIteration and PartStructureIteration).

Notice that both PartRevisionChangeLevel and the PartIteration interfaces are all Attributable, so that Attributes are appropriately accessed through those interfaces

Summary: B) Add a relationship from a DocumentMaster directly to a Vault with the corresponding document
data. If the PdmEnablers are used for importing or exporting a partial model from one Pdm-
System to another, there often will be only one file to import/export, and only in rare cases
complete document-hierarchies will be exposed. With a direct relationship from DocumentMaster
to a corresponding Vault there would be no need to build up the complete hierarchy for
documents (Master, Revision, Iteration, File, Vault) if you want to expose only one single file,
which could eliminate the creation of much overhead.

Summary: A) Change the cardinality of the ComponentHierarchy-Relationship from now 1:n to n:m. This
would enhance the flexibility of use for ProductComponents significantly and would allow the
creation of more complex hierarchies.

Summary: C) Add relationships from most main objects to documents, especially from the Configuration,
Changemanagement and Manufacturing module. In a real construction process, every single step
and every configuration needs to be properly documented. In most main elements (ItemSolution,
ProductComponent, ProductFunction etc.) there is only one field ”description”, which cannot
fulfill the need for complete documentation. Therefore we suggest relationships from
DocumentMasters to: ItemSolution, ProductComponent, ProductClass, ProductFunction,
Specification, Configuration (from Configuration module), to ProcessStep (from Manufacturing)
and to EngChangeItem, EngChangeRequest, EngChangeOrder (from Change management). A
technically correct way for these changes would be the creation of an new Interface
”Documentable” from which all main elements would inherit (like they do from Qualifiable or
Attributable) and to have a single relationship from the DocumentMaster to the ”Documentable”
object, simultaniously eliminating all specialised relationships to and from DocumentMaster or
DocumentRevision.

Summary: ISSUE #2 REF: 1.9.2 Engineering Change Order

This design implies a two step ECM process model (ECR à ECO). While rare, not all organization use this strategy. Some employ a one-step method (no ECR; go straight to ECO).

Summary: ISSUE #1 - Editorial changes

1.) 1.10.2.1, p. 15: change "CosLifeCycle LifeCycleObject" to "CosLifeCycle::LifeCycleObject
2.) 1.14.2.2.1, p.39: need separation between paragraphs
3.) 2.7.3.4, p. 136: change "PartRevisionChangeLeve" to "PartRevisionChangeLevel"
4.) 2.11.1: The model name is "Camry", not "Camary". In either event, it is trademarked and probably should be so noted.

Summary: Problem: There are differences between the interfaces for Person in
the PdmResponsibility module and in the PIDS. In general, these two
models reflect different concerns for the management of Person
and Party objects, but they have identifiably common attributes
that will also no doubt be part of any Party Management proposal,
which we may expect to be implemented by Human Resource Management
systems. Because of the coupling of Human Resource Management with
PDM and ERP systems in the manufacturing operations environment, it will
be necessary for Manufacturing to have a common basis model for Person
and Party that extends across these systems. An initial cleanup of
unnecessary nomenclature differences will facilitate this.

Summary: It seems that
there are a few cases where duplicate exceptions
are being raised. The c++ compiler recognizes this
as a warning. Nothing major here but it does
cause lots of warnings during the compiles.

Summary: In the PdmResponsiblity module, there is no
attribute for "City". Probably ought to go in the Party
interface.

Summary: Problem: The name DocumentRevisionRelationship is misleading in that it has
nothing to do with revising Document objects per se, and it does not
inherit from RevisionRelationship (2.3.14) as one might expect.
Moreover, this relationship is one of three ways of characterising
a PartRevisionChangeLevel – by Document, by Data set and by Structure.
The other two are called PartDataRelationship and PartStructureRelationship.
This one should be called PartDocumentRelationship.

Summary: Figure needs updates (related to Issue 9?)

Summary: Figure 1 in section "2.2.3.5.1 Additional Identification Description" has two incorrect object names.
Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.. 2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas
.

Summary: Part Description text indicates discrete mfg, how could this be expanded for larger industry in the future.. 2.7.1 Part description is targeted towards descrete manufacturing, can it be expanded to other industry areas

Summary: In the convenience document mfg/98-02-02, the IDL for PdmDocumentManagement is obsolete, and does not match the adopted IDL file specified in the errata document mfg/98-02-01.

Summary: 1. PDM Enablers shall support use of a Note Object. Note Object(s) are used by Boeing to store note text associated with another Object (e.g. Documents, Models, Parts, Processes, etc.). Notes may provide information about how to handle, fabricate, or process a part that is not contained in any other location (e.g. a Definition or Process Note may be created for a graphics model), or notes may provide additional information pertaining to a Work Authorization. Note Records are revision controlled and are linked to the Object types to which they correspond. Boeing PDM provides the capability of resolving where the Note is used in a product structure relationship. Notes may contain attributes as described in the following table (for example only):

Summary: PDM Enablers do not currently address Note Objects. This is a Boeing Requirement.

Disposition: Submit as Boeing Requirement to be supported by PDM Enablers

Summary: How do we extend ICOM? Keep PDM Enablers add attributes vs. Subtyping PDM Enablers?

Disposition:

Summary: What security services are to be used with the PDM Enablers? CORBA Security Services?

Disposition:

Summary: When does one use OMG PDM Enablers and when does one use STEP PDM Schema?

Summary: IdentificationContext appears to be no value added. Boeing only wants to make call to get Partid without overhead baggage attached. There exists limited to no capability for query functionality.

Disposition:

Summary: Identify cases where interoperability between PDM Systems would be of use. Identify how these PDM Systems interoperating would be supported by PDM Enabler Functions

Summary: Can we build Boeing ICOM and use PDM Enablers without modifying PDM Enablers?

Summary: How do we handle Document and/or Drawing Sheet Information in PDMEnablers?

Disposition: