Product Structure and Identification

From WikiSTEP

In order to define a product in AP 210, several AIM entities are used. The product entity establishes its identification (or part number), name (or nomenclature), and description. The product_category entity establishes the product in a classification family. The product_definition_formation entity identifies its version (or change level). The product_definition_context entity, in conjunction with the product_definition or product_definition_with_associated_documents entity identifies the engineering discipline view of a specific model of the product. Using those entities (and EXPRESS sub-types), the product is identified, revision controlled, and its context views are defined. Figure 2 describes pictorially the relationships among the entities needed to define a product in AP 210 at a high level. These entities and relationships are necessary in order for AP 210 to support various configuration control methodologies. The product_related_product_category is used to differentiate between assembly and interconnect for example in the "physical design" context.

Figure 2. Product definition context

Contents 1 Identifying Products 1.1 The Product Entity 1.2 The Product Definition Formation Entity 1.3 The Product Definition Formation With Specified Source Entity 1.4 The Supplied Part Relationship Entity 1.5 The Product Definition Entity 1.5.1 The Product_definition attributes 1.6 The Product Definition With Associated Document Entity 1.7 Shape as a property 1.8 Shape Aspect Entity 1.9 Categorizing Products 1.10 AP 210 Standard Categories 1.11 Standard Parts 1.12 Technology Specific Padstack 1.13 Technology Specific Land Pattern 1.14 Reference Packaged Part Assembly Implementation 1.15 Reference Packaged Part Interconnect Implementation 1.16 Recommended Categories 2 Relating Specifications to Products 3 Relating Product Data to Contracts 4 Relating Properties to Products 4.1 Shape State Information for product usage views 4.2 Assigning Shape properties to products 4.3 Assigning Non-shape properties to products 5 Renumbering Vendor Parts 6 Alternate Part Concepts 6.1 Alternate Parts 6.2 Test Select Parts 6.3 Assembly specific alternate parts 6.4 Substitute parts 7 Product association 8 Make From Relationships 9 Assembling Products 10 Instances in Multi-Level Assemblies 10.1 Reference designation 10.2 Quantities in Assemblies 10.3 Next Assembly Quantity 10.4 Specified Higher Usage Occurrence 10.5 Make from Part 10.6 Material Callout 10.7 End Item Quantity 10.8 Promissory_usage_occurrence 11 Substituting Parts in Assemblies 12 Assemblies and Shape 12.1 Replicated Shape 12.2 Mapped Shape 12.3 Referenced Component Shape 12.4 Referenced shape 13 Assemblies and Specifications 14 Engineering Release/ Change Data 14.1 Requests for Release/Change 15 Release/Change Incorporation 16 Release/Change Reissues 17 Configuration Identification 18 Effectivity

Identifying Products

The Product Entity

AP 210 deals with all parts as products. The part number for a part is stored in the id attribute. The nomenclature or name of the part is stored in the name attribute. If there is an expanded name or description of the part this is stored in the description attribute. All STEP products must be founded in some product_context which identifies the engineering discipline that is the product lead discipline.

In populating the data, the id or part number must be unique within the data population. This requires extra measures when the data is shared or exchanged outside of an organization.

AP 210 requires that all products exist in at least three product_categorys.

Products in AP 210 require either a person_and_organization or organization in the role of "design owner". This designation is applied to the person_and_organization or organization or design authority who designed the product.

Pre-processor Recommendations: All pre-processors should use non-defaulted data or user input for the values assigned to the design owner of a product as defaulting this data has a high probability of causing the data to be incorrect.

If the data is intended for external usage, or if the data repository contains product data from multiple organizations, the organization id attribute from the entity in the role of "design owner" shall be duplicated and pre-pended to the product id to provide a unique product identification. For example, if the organization id value were "COUNTRY,USA,CAGE,93699" and the part number were "999999", the actual value of the product id would be "COUNTRY,USA,CAGE,93699,999999".

Post-processor Recommendations: When receiving data from external sources, use the organization id attribute from the entity in the role of "design owner" to provide a product identification context in order to extract the data provider's part number from the product id.

The Product Definition Formation Entity

AP 210 requires that all products be associated with a product_definition_formation entity. This relation is required as AP 210 is required to support the versioning of parts. This requirement ensures that all information which typically varies from version to version is always related to the part.

There are many organizations which claim quite firmly (and possibly rightly so) that they do not version parts. All that is being done here is establishing a connection which may or may not have valuable data.

In AP 210, the connection being established is actually a connection to the data which comprises the detailed product model for the part. If your organization versions parts, the product_definition_formation id attribute is the standard mapping of the value which represents this version. The description attribute should contain the reason for the creation of the version.

AP 210 requires that all product_definition_formation entities be associated with a person_and_organization or an organization in the role of "creator". This is the one which created the change.

AP 210 requires that all product_definition_formation entities be associated with at least one person_and_organization or organization in the role of either "design supplier" or "product supplier". The person_and_organization or organization in the role of "design supplier" is the one which was the custodian of the master data when the version was created. The person_and_organization or organization in the role of "product supplier" is the one which had manufacturing cognizance (if the part is made internally to the organization) or the vendor who supplies the part if it is a vendor part.

AP 210 requires that all product_definition_formation entities be associated with an approval.

AP 210 requires that all product_definition_formation entities be associated with a security_classification.

AP 210 provides a capability for an organization to associate two product_definition_formation entities for the same product in order to publish technical information related to the product, while managing intellectual property. The two product_definition_formation entities would be referenced by two product_definition entities that would be related through a product_definition_relationship with a name of "design usage".

Pre-processor Recommendations: If your organization does not version parts, the id attribute should contain a null string as minimal data content or any mutually agreed upon string. If the id attribute is a null string, the description value would also be a null string. All pre-processors should use non-defaulted data or user input for the values assigned to the creator, design and product suppliers, approvers and approval date for product_definition_formation entities as defaulting this data has a high probability of causing this data to be incorrect.

It is recommended that pre-processors use an id of "ANY" where they wish to indicate a generic revision of a part. This type of instancing would be used when the part with the revision of "ANY" is a component in an assembly to indicate that any existing revision of the component is valid for the assembly. This type of instancing reduces the amount of data to be sent in change packages. When this is used, it reduces the ability to track the actual contents of parts lists at a particular change level when the organization versions parts.

Post-processor Recommendations: When the value of the id and description attributes for product_definition_formation is a null string, post-processors should use this as an indication that there is no version of the part.

It is recommended that post-processors recognize an id of "ANY" as indicating a generic revision of a part. This type of instancing would be used when the part with the revision of "ANY" is a component in an assembly to indicate that any existing revision of the component is valid for the assembly.

The Product Definition Formation With Specified Source Entity

The product_definition_formation_with_specified_source entity is a subtype of the product_definition_formation entity. Therefore all guidance provided for the product_definition_formation entity applies to product_definition_formation_with_specified_source.

Pre-processor Recommendations: Pre-processors should implement the guidance for the supertype product_definition_formation.

The source attribute must contain a value of ".MADE.", ".BOUGHT." or ".NOT_KNOWN.". The value should be ".MADE." if the part is built within the company. value should be ".BOUGHT." for vendor parts. If it is possible for the part to be both made and bought (depending on serial number for example), the value should be ".NOT_KNOWN.". Only the organization that is the creator of the product_definition_formation_with_specified_source should modify this attribute.

Post-processor Recommendations: Processors should implement the guidance for the supertype product_definition_formation. Processors should preserve the value of the source attribute.

The Supplied Part Relationship Entity

Organizations often keep track of the relationship between the internal organization part number and the vendor part number for each of the vendor supplier parts used in products. The AP 210 Application object for this concept is Supplied_product_version. The supplied_part_relationship entity relates two product identification instances where one instance provides the vendor identification (through the product id attribute) and the other instance provides the organization identification. The relationship is established through two instances of product_definition, one instance of product_definition_formation_with_specified_source and one instance of product_definition_formation. The relationship is directed, with the 'related' value directed toward the vendor identification. The vendor identification is also using the instance of product_definition_formation_with_specified_source. This direction is invariant among exchange and data sharing scenarios between organization and vendor. Note that there may be more than one supplied_part_relationship for each vendor supplied product identification.

Pre-processor Recommendations: Vendor product_definition_formation_with_specified_source source attribute value should be ".MADE.", and the 'related' direction should be toward the vendor product identification.

Post-processor Recommendations: Values received should be maintained by the processor.

The Product Definition Entity

AP 210 and STEP use the product_definition entity to establish specific life cycle stage and design discipline views of the product data. AP 210 also uses product_definition and subtypes to provide a domain specific product model. The product_definition_context entity is used in AP 210 to distinguish view context (e.g., the design discipline identification). The AP 210 mapping table establishes the relationship between the product_definition entity attribute values and the corresponding context entity attribute values. In some cases, both the product_definition_context and the product_context attribute values are required to establish the context. In the case of shape_aspect subtype part_template_definition and component_shape_aspect, there is not an AP 210 specific subtype of product_definition required, but there are AP 210 requirements applied on the generic product_definition referenced by this shape_aspect subtype. In the case of shape_aspect subtype component_shape_aspect, there is an AP 210 specific subtype of product_definition required (component_definition), and there is also an AP 210 requirement applied on the generic product_definition referenced by this shape_aspect subtype.

It is possible to have many product_definitions for a part/version combination.

AP 210 provides domain specific product_definition subtypes in addition to the STEP generic subtypes. The following product_definition subtypes are considered in the AP 210 domain as complete product definitions and in many cases are the only product_definition associated with a product entity instance:

• analytical_definition,
• assembly_definition,
• bare_die,
• functional_unit,
• electrical_network,
• interconnect_definition,
• package,
• packaged_connector
• packaged_part,
• physical_unit,
• requirement_definition
• thermal_network.

A complete product definition in this context means that it may be the only product_definition in the exchange that directly points to the product_definition_formation that points to the product about which information is being exchanged.

The following "composing" product_definition subtypes are considered in the AP 210 domain as product definitions that are used in composing a complete product definition:

• bus_structural_definition,
• component_definition,
• component_functional_unit,
• network_node_definition,
• packaged_component
• printed_component,
• stratum
• thermal_component.

The "composing" product_definitions in this context implies that the product_definition is not required to point to a real product, (although it may point to a real product).

AP 210 provides the following externally defined product_definition subtypes to further establish the context:

• externally_defined_assembly_definition,
• externally_defined_bare_die,
• externally_defined_functional_unit,
• externally_defined_interconnect_definition,
• externally_defined_package,
• externally_defined_packaged_connector,
• externally_defined_packaged_part,
• externally_defined_physical_unit.

The above items are subtypes of both product_definition and externally_defined_item.

AP 210 provides the following externally defined product_definition subtypes to further establish the context:

• library_defined_assembly_definition,
• library_defined_bare_die,
• library_defined_functional_unit,
• library_defined_interconnect_definition,
• library_defined_model,
• library_defined_package,
• library_defined_packaged_connector,
• library_defined_packaged_part,
• library_defined_physical_unit.

The above items are subtypes of both product_definition and externally_defined_item with a further requirement that external_source attribute source_id is the library identification. In the AP 210 domain, libraries are not versioned, only the items in the library are controlled. The library_defined_model is additionally a subtype of analytical_model. This provides the functionality to provide the same level of configuration management to simulation models as available to product configuration management. All simulation model configuration management should use this subtype.

The shape_aspect entity provides subtypes that are used for definitions in the domain of interconnect and that use product_definition and product_definition_context as supporting entities. Important concepts such as land templates and other library symbology are supported in this manner. Instance data in the domain of interconnect design is also supported with subtypes of shape_aspect.

The Product_definition attributes

The name attribute of product_definition is used to help establish the "type" or "instance" values for the product_definition. This is a major change from the IS version of the standard, which attempted to map product_definition subtypes using product category constraints. This major source of confusion was eliminated by this change. The id and description attributes of product_definition are also used to identify either "type" or "instance" values. In this context "type" refers to a generic concept similar to an EXPRESS entity where the interpretation process did not create an AP 210 specific entity but chose to encode the information as a string value. In this context "instance" refers to the more usual identifier role. The "type" values are directly related to the requirements specified in relevant Application objects in clause 4 of AP 210.

The following are standard "type" mappings for the name attribute (These are formally documented in clause 5.1 in rev 1 of the standard.):

• assembly bond model,
• requirements model,
• interconnect module,
• printed connector component,
• assembly module,
• design layer,
• documentation layer,
• generic stratum.

The following are standard "type" mappings for the id attribute:

• "design composition path",
• "reference composition path".

The following are standard "type" mappings for the description attribute:

• "altered package",
• "altered packaged part",
• "bare die component",
• "join 2 physical connectivity definition supporting printed component",
• "laminate component",
• "mating connector"
• "packaged connector component",
• "placement group",
• "printed connector component",
• "routed packaged component",
• "thermal component".

These mappings are in the limited context as established by product_definition_context as documented in the AP 210 mapping table for the Application objects that correspond to these type names. The reference path and associated constraints define the structure that establishes the valid context.

Note: The part_template_definition is closely aligned with this usage but since it a subtype of shape_aspect it is not discussed above.

The id and description attributes of the product_definition associated with the part_template_definition are not directly controlled since the product_definition_context provides an unambiguous context for part_template_definition instance data.

Standard "instance" mappings for the name attribute are specified in clause 5.1 of rev 1 of the standard.

The following are standard "instance" mappings for the id attribute:

• reference designation for a functional unit in a hierarchical netlist,
• stratum name,
• mating connector component reference designation.

The following are standard "instance" mappings for the description attribute:

• context description of AP 210 application object Ee_product_definition and subtypes,
• "primary design layer stratum",
• "non primary design layer stratum".

The functional unit reference designation is a string usually composed of a concatenation of a function type and an integer in the limited context of functional networks as established by product_definition_context. Functions may be categorized into types using the product_category entity. Reference the AP 210 mapping table for the Application object Functional_unit for the exact structure that establishes the valid context.

The stratum name is usually represented by an integer (which indicates a relative position). Note that this integer is not the standard method for formally establishing the position of a stratum in the board stackup. There are no facilities in AP 210 for ensuring the relevant properties of the stratum name necessary for the integer to be an accurate representation of the position in the stackup. The only requirement in AP 210 on the stratum name is that it be unique for each instance of stratum. AP 210 uses shape_aspect_relationship between adjacent stratum surfaces to ensure unambiguous description of the stratum position in the stackup. The shape_aspect_relationship is directed; the stratum surfaces are identified as either primary or seconday; the result is that the stackup is determinant without relying on descriptors. The description attribute on shape_aspect_relationship shall be 'adjacent stratum surface definition'. The Inter_stratum_extent Application object should not be used to define stratum stackups, although there are some obvious business rules for valid Inter_stratum_extents (i.e., the extent has to exist!).

Organizations occasionally require explicit definition of mating connector relationships. This is modelled in AP 210 using the The Application object Mating_connector_component. A reference designation is usually composed of a concatenation of a type associated with a connector and an integer and is only applied to a product_definition of the type component_definition with a description value of "mating connector".

AP 210 requires that all product_definitions have a person_and_organization assigned in the role of "creator". This person_and_organization or organization is the one which defined the view. If the product_definition is being used as solely a connection to a property, this would be the person who filed the computer model of the property.

AP 210 requires that all product_definitions have a date_and_time assigned in the role of "creation date". This date and time is when the view was defined. If the product_definition is being used as solely a connection to a property, this would be the file date and time for the computer model of the property. If this is not the case, see the pre-processor recommendations.

AP 210 requires that all product_definitions have an approval. If this data is difficult to determine, use the creator data as source data.

Pre-processor Recommendations: Since there are so many standard mappings on the id and description attribute, it is infeasible to use the id attribute for describing the engineering discipline that created the definition. See the product_definition_context entity for the discipline.

Where values for the creator, creation date are not readily available, this information can be extrapolated from the creator and approval related to the product_definition_formation. Pre-processors shall not use product_definition_with_associated_documents to relate specification type documents to the product_definition.

Post-processor Recommendations: Post-processors shall follow the requirements of the mapping tables.

The Product Definition With Associated Document Entity

AP 210 has an optional feature where a product_definition may be related to document entities through the sub-type product_definition_with_associated_documents. In AP 210, this usage is intended only for documents which identify associated computer files where the document_type attribute product_data_type has the value "cad filename". A non-standard usage would be to associate computer files for drawings where the document_type attribute product_data_type has the value "drawing". The non-standard usage would require an exchange agreement.

There is a rule in AP 210 restricting the product_data_type of ee_specification subtype of documents, but the AP does not formally eliminate the possibility of relating ee_specification type documents using the product_definition_with_associated_documents sub-type.

When using product_definition_with_associated_documents to reference computer files, the document id attribute should contain the file name of the file with enough detail so that it is uniquely identified in the exchange. The following is the recommended list of {type, value} tuples:

• "OS_SUPPLIER_ID",
• "string",
• OS_NAME",
• "string",
• "OS_VERSION_ID",
• "string",
• "CAD_TOOL_SUPPLIER_ID",
• "string",
• "CAD_TOOL_NAME",
• "string",
• "CAD_TOOL_VERSION_ID",
• "string",
• "CAD_FILE_TYPE",
• "string",
• "CAD_FILE_TYPE_VERSION_ID",
• "string",
• "CAD_FILE_LOCATOR_TYPE".
• {"URL" | "DIRECTORY PATH"},
• "string",
• "CAD_FILE_DATE_TIME_STAMP",
• "string".

All uppercase strings should be provided verbatim, with the actual parameter values included in the positions identified by the keyword 'string' in the above list. This list is self-explanatory except for:

• "OS_SUPPLIER_ID" and "CAD_TOOL_SUPPLIER_ID" should be coded in accordance with id attribute recommendations for the AP 210 entity organization.
• "CAD_FILE_TYPE", which is the language reference manual for the file type or standard (e.g. IGES, STEP AP schema name, POSTSCRIPT, etc.));
• "CAD_FILE_TYPE_VERSION_ID", which is the version of the reference for the file type;
• "CAD_FILE_LOCATOR_TYPE", which is the first element of a three element tuple consisting of it plus an indicator of either a URL or an internal directory path, plus the value of the URL or internal directory path.
• "CAD_FILE_DATE_TIME_STAMP" should be coded in accordance with AP 210 date_and_time entity coding requirements, in order to be consident with the rest of the standard.

Due to the coding of data in the id attribute, the use of the name attribute and the description attribute is unnecessary.

Pre-processor Recommendations: Reference product_definition_context for discipline and life cycle view attributes. In order to implement concurrent engineering it is expected that exchange agreements would need to be implemented. Where values for the creator, creation date are not readily available, this information can be extrapolated from the creator and approval related to the product_definition_formation_with_specified_source. Pre-processors shall not use product_definition_with_associated_documents to relate specification type documents to the product_definition.

Pre-processors should implement the standard mappings as discussed above.

Pre-processors should use the coding specified in this document as computer sensible identification of sending system configuration for the document id attribute.

Post-processor Recommendations: All post-processors shall implement the standard mappings as discussed above.

All post-processors should utilize the values given above for document id attribute for pre-processors or implement appropriate exchange agreements.

Shape as a property

Shape is a basic property supported in AP 210 explicitly. Because it is possible to have several analysis shapes for the same product, the representation that identifies the purpose and other state information for the shape effectively identify the state of the product definition for which that shape is a property. This is required so that the alternate representation construct needed for backward compatibility with AP 203 can be supported. Reference clause 1.5.4.1 in this document for a description of the alternate representation recommendations.

Shape Aspect Entity

The shape_aspect name and description attributes standard mappings are defined in the mapping tables, clause 5.1 in the standard. There are many AP 210 domain specific subtypes of shape_aspect. Two subtypes of shape_aspect are of particular importance: part_template_definition and component_shape_aspect. part_template_definition is supported by a product_definition in a context of 'template definition' and is a definitional concept itself. component_shape_aspect is the occurrence of a part_template_definition, so there is an 'occurrence' context for instances of this entity type. There is a shape_aspect_relationship of 'instantiated template' identifying the definition for a component_shape_aspect.

Categorizing Products

AP 210 provides for assigning parts to categories and for creating a network of categories. There are standard categories in the AP 210 domain used to establish exchange contexts. Category networks can be extremely useful in adding intelligence to the data. The use of a network graph rather than a tree is crucial to the usefulness of the approach. A tree based approach with a single root node is impractical. AP 210 supports exchange of data sufficient to support part selection processes. Parts are assigned directly to categories though the product_related_product_category entity which is a sub-type of the product_category entity. Category hierarchies can be created by relating super and subcategories through product_category_relationship entity. An AP 210 product could be related to as few as one root node or as many root nodes are of interest in the enterprises exchanging or sharing data. In this way, multiple characteristics may be related to a product (e.g., "commercial", "serialized", "replaceable", "standard part", "assembly"). In this example, "assembly" is the value assigned to product_related_product_category name attribute. The other strings would be contained in individual instances of product_category name attribute and related to the product_related_product_category pointing to this product by four (4) instances of product_category_relationshp.

Pre-processor Recommendations: There are no standard mappings for the product_category_relationship name or description attributes. Since there are no standard mappings in the AP 210 application domain for these attributes, it is recommended that these attributes contain a null string as minimal content or any appropriate/ mutually agreed upon string. Pre-processors should use lower case for product_category name values. Leading and trailing blanks in the product_category name value should be removed.

Post-processor Recommendations: Since there are no standard mappings for the product_category_relationship name or description attributes, it is recommended that post-processors not assign any processing significance to these values. Post-processors should attempt to store all categories and subcategories and category relationships received in an AP 210 exchange as this information adds meaning to the received data. If it is impossible to store the data, the user should be informed of all categories and relationships not processed. This would be best done by presenting the user with a report on the category structure in the file with subcategories indented. Post-processors should use non-case sensitive checking when determining matches on processed category data. Leading and trailing blanks in the product_category name value should be removed.

AP 210 Standard Categories

AP 210 has the capability to exchange network structures of product categories where certain nodes in the network are standardized in the AP 210 domain. AP 210 rules control network entries that directly reference products. Generic names are included for interoperability purposes in order to allow product identification. The name attribute of each instance of product_related_product_category is constrained to be one of the following values (This is a major change from the IS version of the standard. These categories no longer constrain the product_definitions that may be used to define the product version):

• "assembly",
• "bare die",
• "functionality",
• "interconnect",
• "material",
• "package",
• "piece part",
• "printed part",
• "requirements model",
• "simulation model",
• "standard part",
• "technology specific model",
• "template model".

These categories should be considered as basic product types. If a network of product_related_product_categories that reference a product or products contains an instance of the product_related_product_category that is a "standard" category, the number of product_related_product_categories that are in that network shall be one or two. Otherwise the number of product_related_product_categories that reference a product or products shall be one.

As an example use of this capability, an interconnect substrate may be a flex rigid pcb. Normal industry usage for the network structure creation would be for the string "pcb" to be assigned to a higher level category name attribute, and each of the strings "flex-rigid", "flex", "rigid" to be assigned to a lower level element in the category network. One of the nodes (e.g., "flex-rigid") would be related to the product_related_product_category by a product_category_relationship entity.

If the product_related_product_category assigned to the specific product under design or usage had the string value "interconnect" assigned to the name attribute, that would have the effect of applying an industry specific or enterprise specific classification ("flex-rigid") to the AP 210 standard category of "interconnect".

Industry specifications and standards (e.g., IEC, IPC, ARINC) should be used where possible to establish the product category networks to maximize the benefit of this capability. It is recommended to represent the specification identifier (e.g., "IEC 1182-10") in the product_category description attribute, since there is no standard mapping or character strings assigned to this attribute in the AP 210 domain.

There are a few pre-defined strings in AP 210 for the value of the product_category name attribute when the instance created is not a product_related_product_category. The meanings for these pre-defined strings are included below. Otherwise there are no restrictions on the attribute. This means that when networks of categories are created there is no restriction (other than that stated above) on the names of the categories not directly related to a product.

Not all products in AP 210 are directly physically realizable (i.e., functionality, simulation model, requirements model, printed part, technology specific model, template model).

Standard Parts

AP 210 defines via its mapping table a mapping for standard parts. The defined mapping is that a product_related_product_category have the standard character string assigned of "standard". This mapping is in agreement with the PDM schema at this time. This mapping is different than the mapping of the DIS version of the standard.

Technology Specific Padstack

Some 2D CAD systems define default padstacks. AP 210 separates the (conceptual) definition of the barrel from the definition of the associated lands. Since a particular padstack is always based on a specific stratum stackup, a specific use of Interconnect_module is recommended that is composed of the specific Lands and Stratum needed to support the padstack definition. The recommendation is that a product_category be created and that this category be related through a product_category_relationship to a product_related_product_category related to a product. The recommended character string assigned for this purpose is "technology specific model". This category should only exist if the "interconnect" product_related_product_category is the relating end of the product_category_relationship.

Technology Specific Land Pattern

IPC Standards provide reference land patterns. These patterns are purely geometric shapes and have no connectivity information. AP 210 provides no explicit way to define land patterns because the location of the land in the pattern is derived from the connection_zone location for the terminal in the Package model. A Part_template is intended to be an individual thing. The standard is very specific in its use of Assembly_joint to ensure that the connectivity defined in the netlist is implemented in the Interconnect_module. In order to allow support for land patterns and subsequently derive footprints a specific use of Interconnect_module is recommended that is composed of the Lands necessary to support a specific Packaged_part. The recommendation is that a product_category be created and that this category be related through a product_category_relationship to a product_related_product_category related to a product. The recommended character string assigned for this purpose is "technology specific model". This category should only exist if the "interconnect" product_related_product_category is the relating end of the product_category_relationship. This product may include padstacks through the use of "technology specific model" products and breakout patterns and micro-vias etc.(This is obsolete for rev 1 since we have padstack_definition and footprint_definition.)

Reference Packaged Part Assembly Implementation

AP 210 supports gathering the information related to a specific combination of Packaged_part, assembly technology, and fabrication technology together in one place. The method is to use the Assembly_module as the composition vehicle. This provides a vehicle to gather together the bond definition, the component definition and the interconnect definition. The recommendation is that a product_category be created and that this category be related through a product_category_relationship to a product_related_product_category related to a product. The recommended character string assigned for this purpose is "assembly". This category should only exist if the "assembly" product_related_product_category is the relating end of the product_category_relationship.

Reference Packaged Part Interconnect Implementation

In order to support the particular fabrication technology, land patterns, padstacks, breakouts, and material stackup for a "reference packaged part assembly implementation", a particular Interconnect_module must be defined, since an Interconnect_module requirements are dependent on the requirements driven by the assembly. The reference interconnect may be composed of technology specific land pattern, technology specific padstacks, and other needed interconnect elements necessary to form a valid interconnect definition. The recommendation is that a product_category be created and that this category be related through a product_category_relationship' to a product_related_product_category related to a product. The recommended character string assigned for this purpose is "interconnect". This category should only exist if the "interconnect" product_related_product_category is the relating end of the product_category_relationship.

Recommended Categories

It is recommended that all implementations of AP 210 support the following high level categories which are not standardized in the AP, but will undoubtedly have common usage:

• "commercial" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) is a general-purpose commercially-available product.
• "customer furnished customer installed" - This category indicates that the product referenced by a product_related_product_category' that is related to this category (by a product_category_relationship) is part of the system or unit for requirements definition, but is actually placed in the system or unit after some portion of delivery.
• "government" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) is a product which has been developed or purchased to meet specialized government specifications.
• "hazardous material" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) either is or contains hazardous material.
• "interchangeable" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) is a product which requires no trimming or modification when replaced.
• "replaceable" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) is a product which requires trimming or some modification (usually for fit) when replaced.
• "serialized" - This category indicates that the product referenced by a product_related_product_category that is related to this category (by a product_category_relationship) is (or contains) a serialized product.

If multiple classifications are desired (for instance "commercial" and "replaceable"), then multiple instances of product_category_relationship should all point to the same instance of product_related_product_category. If desired, these could all be sub-categories of a product_category with a name attribute of "contractual classification".

Relating Specifications to Products

AP 210 provides backward compatiblity to AP 203. Using the AP 203 method, one relates specifications to entire parts by relating an applied_document_reference entity specified by applied_document_reference to the product and by the classification of the document as a specification. If the specification only relates to a portion of the part, the applied_document_reference document is related to a shape_aspect which is in turn related to the product_definition_shape of the part. AP 210 provides the ability to relate documents to product_definition_formation, product_definition and several other entities using the same mechanism.

The applied_document_reference entity identifies the owner of the specification through the source attribute. This attribute should contain an unambiguous identification of where the receiver of the data could obtain a copy of the document. The document related to the applied_document_reference must be uniquely identified in the exchange by the id attribute. This means that the id should contain any revision information needed to identify the document completely. The name attribute should contain the title of the document. The description attribute should contain an expanded explanation of the document's contents.

Since many specifications cover a variety of subtopics and options on a given topic, it may be necessary to identify a particular subtopic of the specification and assign option values. In AP 210 this is accomplished by relating a document_usage_constraint to the document. The subject_element attribute identifies the particular section or topic being referenced in the specification. The subject_element_value identifies any option choices or restrictions placed on the section or subtopic.

The document_usage_constraint should not be used to reference classes defined in specifications such as process specifications. This should be done by using the document entity sub-type document_with_class. If classed documents require further restriction of the class, a document_usage_constraint may be related to the document_with_class entity. This is also provided for backward compatibility. See the above note.

AP 210 provides for documents related to a product_definition to be related to other documents in a network type relationship. This is accomplished through the document_relationship entity. The standard usage for this relationship is to describe a version of a document. Reference clause 5.1 in AP 210.

AP 210 provides for directly exchanging requirements allocated to a product where the requirements were extracted from a document and where there may be more data than can conventiently fit in the document_usage_constraint. Reference requirements section of this document.

Post-processor Recommendations: Post-processors should store all data found in specification documents attached to product_definitions or shape_aspects. If it is not possible to store all the data, the user must be informed of the data being omitted and its relationship to the product_definition or shape_aspect.

Relating Product Data to Contracts

AP 210 provides an optional relationship of the following entities:

• Products,
• Product_definition_formation,
• Alternate_product_relationship,
• Directed_action to contracts through the applied_contract_assignment entity.

In AP 210, a contract can be used to represent either an explicit contract which provides the requirements (and typically the funds) for the activity or some other agreement (such as a purchase order) which fulfills the same function. The contract name attribute should contain the contract or agreement identifying number or name if no number exists. The purpose attribute should contain the reason for the existence of the contract or agreement. The contract_type description attribute may contain values such as "fixed_price" or "cost_plus" or other descriptors.

AP 210 requires that a contract have an associated approval. A contract must also have an associated person_and_organization in the role of "contractor". A contract may have an associated date_and_time in the role of "contract_date".

Pre-processor Recommendations: It may be difficult to obtain the approval and contractor information. If this information is not available, it should be provided either through user input or from default data based on the contract name value.

Relating Properties to Products

Shape State Information for product usage views

The AP 210 reference CAD model for the usage view 6includes the following properties in the ARM Application objects Physical_unit_planar_shape and Physical_unit_3d_shape to distinguish purposes for creating shape data:

• application_technology_constraint,
• shape_material_condition,
• centroid_location,
• shape_environment,
• shape_purpose.

The shape_purpose is one of:

• thermal_analysis,
• vibration_analysis,
• shock_analysis,
• electromagnetic_compatibility_analysis,
• design,
• design_profile,
• design_profile_above_seating_plane,
• design_profile_below_seating_plane.

The shape_material_condition is either: nominal_material_condition, maximum_material_condition, least_material_condition.

The shape_environment is either: end_user_application, manufacturing.

Assigning Shape properties to products

For backward compatibility to AP203, and specifically in support of shape properties, AP 210 uses several entities to form the link between the configuration management data for a product and the properties for a product. These entities are property_definition, property_definition_representation, product_definition_shape and shape_definition_representation. There are no standard mappings for the product_definition_shape name and description attributes. It should be noted that no link to property representation (such as shape) is required. It is possible to use the property_definition or product_definition_shape entity to indicate that a product has (or will have) properties without relating a property_definition_representation or shape_definition_representation.

There must be only one product_definition_shape for each product_definition in an AP 210 exchange file. If there are multiple shape_definition_representation entities related to the product_definition_shape, these relationships describe alternate representations. This is depicted in Figure 3.

Figure 3. Product with alternate shape representations

If the shape of the product is composed of shape constructs from multiple types of shape_representation to form the entire shape model, the main shape_representation shall be related to a shape_definition_representation which relates to the product_definition_shape. The other shape_representations are related to the main shape_representation through a shape_representation_relationship. This is depicted in Figure 4.

Figure 4. Single product with multiple shape representations

In some cases, the shape of a product is based on the shape of another product. This commonly occurs when one is the mirror image of the other. When this occurs, it is through a representation_relationship_with_transformation. This is structure is shown pictorially in Figure 5.

Figure 5. Product shape derived by mirroring another product shape

The transformation is constructed based on a functionally_defined_transformation. It is presumed that the transformation would be applied to the coordinate system of the source part prior to it being mapped to that of the mirrored part.

Note: This capability is provided for legacy compatibility with AP 203. It is not intended to be used to support AP 210 specific modeling constructs (i.e., 2D CAD system input/output).

Pre-processor Recommendations: There are no standard mappings for the name and description attributes for product_definition_shape. Since there are no standard mappings in the AP 210 application domain for these attributes, it is recommended that these attributes contain a null string as minimal content or any appropriate/mutually agreed upon string.

Post-processor Recommendations: Since there are no standard mappings for the name and description attributes for product_definition_shape, it is recommended that post-processors not assign any processing significance to these values.

Assigning Non-shape properties to products

For support of product properties applied at the product level only, and not dependent on product versions, AP 210 provides property assignment through specific subtypes of the product_category and characterized_object entities. Reference the section in this document specifying product categories for category determination. The specific AP 210 entities are characterized_product_category, product_related_characterized_product_category. A characterized_product_category may have one or more properties associated with it. The properties may be tuples of (identifier, data) or may be a data element type name assignment only. A product_related_characterized_product_category then associates a specific property assignment value for a specificy data element type for a specific product. For example a characterized_product_category may be a RAM memory array. There may be a memory size property assigned to the characterized_product_category as a data element type but no value assigned at the characterized_product_category level. A specific product would have a product_related_characterized_product_category with an assignment of "memory size" of "128Mb" as a value. The property "memory size" would be inherited from the characterized_product_category as an allowed data element type. Properties not included in a characterized_product_category are not allowed to be assigned values in the product_related_characterized_product_category.

In the AP 210 domain, it is not required that IP1 on product_category or IP1 on product_category_relationship be satisfied. AP 210 allows properties to be assigned to the AP 210 specific subtypes that are also subtypes of characterized_object. The assignment of specific property values requires multiple instances of entities which cause the violation of the two indicated IPs.

Renumbering Vendor Parts

In all realms of design and manufacturing business, it is common to buy parts from a vendor and renumber them under an internal numbering scheme. In today's practice, this is done through envelope, specification and source control drawings. An envelope drawing is used for a simple renumber of a part where the part is referenced on the envelope drawing and assigned a new part number via the associated parts list. A specification control drawing renumbers a part to show that it meets or exceeds the specifications defined on the drawing and to recommend sources for the part. A source control drawing renumbers a part and creates a restricted list of suppliers which are qualified to produce the part based on the specifications..

In AP 210, all of the above relationships are supported through the supplied_part_relationship. This relationship is used for the identification of part_suppliers and design_suppliers. The identification of "design_supplier" is actually redundant, since this information can be obtained from the person_and_organization related to the product_definition_formation in the role of "design_supplier". This document will only address the use of supplied_part_relationships for renumbering of parts. The structure of a supplied_part_relationship is shown in Figure 6.

Figure 6. Supplied part relationship

To renumber parts through a supplied_part_relationship, both parts must be defined. The supplied_part_relationship relates the "customer" part number's product_definition in the relating_product_definition attribute to the "supplier" part number's product_definition in the related_product_definition attribute. There are no standard data or mappings for the name and description attributes. The id attribute must be unique, but there is, again, no standard mapping.

Certification of suppliers can be indicated through a supplied_part_relationship. This is accomplished by populataing an applied_certification_assignment which relates a certification to the relationship. There are no standard mappings for the values of the name and purpose attributes for the certification entity. There are no standard mappings for the values of the certification_type description attribute. If a certification is used, AP 210 requires that the certification be related to an approval. It is further required that the certification be associated with a date_and_time in the role of "certification_date".

Pre-processor Recommendations: It may be difficult to obtain the data for the certification's approval and "certification_date". Where this data is not immediately available, it can be extrapolated from the approval related to the product_definition_formation found on the path referenced by the relating_product_definition attribute.

There are no standard mappings for the name and description attributes in a supplied_part_relationship. Since there are no standard mappings in the AP 210 application domain for these attributes, it is recommended that these attributes contain a null string as minimal content or any appropriate/ mutually agreed upon string. The id attribute must be constructed so as not to duplicate any assignments made to other entities which are sub-types of product_definition_relationship.

There are no standard mappings for the name and purpose attributes in a certification. Since there are no standard mappings in the AP 210 application domain for these attributes, it is recommended that these attributes contain a null string as minimal content or any appropriate/ mutually agreed upon string.

Post-processor Recommendations: Since there are no standard mappings for the name and description attributes for a supplied_part_relationship, it is recommended that post-processors not assign any processing significance to these values.

Since there are no standard mappings for the name and purpose attributes for a certification, it is recommended that post-processors not assign any processing significance to these values.

Alternate Part Concepts

AP 210 supports several variants of designating alternative parts.

Alternate Parts

Alternate parts in AP 210 are defined through the alternate_product_relationship entity with the basis attribute assigned a value of 'alternate product'. This relationship is used in the definition of parts list data for alternate item designations. There are no standard mappings to the name and description attributes of this entity.

Pre-processor Recommendations: There are no standard mappings for the name and description attributes of alternate_product_relationship. Since there are no standard mappings in the AP 210 application domain for these attributes, it is recommended that these attributes contain a null string as minimal content or any appropriate/ mutually agreed upon string.

Post-processor Recommendations: Since there are no standard mappings for the name and description attributes of alternate_product_relationship, it is recommended that post-processors not assign any processing significance to these values.

Test Select Parts

AP 210 provides support for exchanging one or more lists of parts that may be selected from at final test. The list is identified as a single item on the parts list for the product, but the quantity of each item in the list is an indication of the relative frequency of occurrence of that value in production of the end product. The standard mapping for this is alternate_product_relationship basis attribute is 'test select product'. The list is a product with it's own part number, version, and parts list. The recommendation is that the relative frequency of occurrence is normalized to a total population of 100, with 2 digit precison applied. This allows the use of integers where the total value of all entries in the list is 100.

Assembly specific alternate parts

AP 210 provides the ability to identify two-way alternates within the context of a single assembly by assigning the value of 'assembly alternate product' to the basis attribute of alternate_product_relationship.

Substitute parts

AP 210 provides the ability to substitute one part for another within the context of a single assembly or a single assembly relationship. The assembly_component_usage_substitute entity provides this capability. This is a one way substitution capability with no guarantee of form, fit, or functional 100% equivalence.

Product association

AP 210 provides the ability to associate two products based on a specification. This capability is encoded in the product_definition_formation_relationship with the name attribute assigned a value of 'product association'. The business purpose should be described in the specification.

Make From Relationships

In AP 210, the fact that the design or design usage for a product is made from the design or design usage for another product is indicated by the design_make_from_relationship. To indicate the above, both products must be defined in a design or design usage view. The design_make_from_relationship relates the source product's product_definition in the relating_product_definition attribute to the resultant product's product_definition in the related_product_definition attribute. Figure 7 illustrates this relationship.

Figure 7. Design make from relationship

Typical usage of this capability in the electronic domain is for programmable devices.

Note: Since AP 210 supports functional products this relationship can be used to define functional definitions that are derived from other functional definitions.

Pre-processor Recommendations: The attributes should be set to null strings.

Post-processor Recommendations: It is recommended that post-processors not assign any processing significance to the attribute values for design_make_from_relationship.

Assembling Products

In AP 210, an assembly is defined as a product that has other products related to it which represent the detail products and sub-assemblies which comprise the assembly. This relationship of an assembly product to its components is defined through a next_assembly_usage_occurrence in AP 210. The structure of this relationship is shown in the Assembly module section of this document. Most usages of assemblies using next_assembly_usage_occurrence are single level bill of material. Special domain specific sub-assemblies are supported. Reference the Associated parts section of this document.

Note: Processors may use a version id of "ANY" where they wish to indicate a generic revision of a product when the product is a component in an assembly. This indicates that any existing revision of the component is valid for the assembly. This type of instancing reduces the amount of data to be sent in change packages. When this is used, it reduces the ability to track the actual contents of parts lists at a particular change level when the organization versions products.

The next_assembly_usage_occurrence id attribute inherited from product_definition_relationship has standard mappings defined in the mapping table. The name attribute inherited from product_definition_relationship has standard mappings defined in the mapping table. The item/find number from the parts list should be represented by a descriptive_representation_item with a name attribute value of 'item find number' and the description attribute of descriptive_representation_item assigned the value for the string representing the actual item/find number. It is recommended that the representation_context context_type attribute for the descriptive_representation_item be set equal to 'item find number representation context'. It is recommended that the name attribute of property_definition be set equal to 'item find number' as well. It is usually the case that the number is a positive integer greater than zero, but there are no rules to formalize this. It is possible and likely that multiple instances of next_assembly_usage_occurrence will be assigned to the same instance of descriptive_representation_item. The description attribute inherited from product_definition_relationship has standard mappings defined in the mapping table. The reference_designator attribute of next_assembly_usage_occurrence inherited from assembly_component_usage designates a unique positional location within the context of the assembly referenced by the relating_product_definition inherited from product_definition_relationship. There is a rule in the standard that requires the combination of reference_designator and relating_product_definition to be unique.

It should be noted that since the usage is described by a product_definition_relationship, many different views of the usage can be established by varying the relating_product_definition. AP 210 can maintain one usage based on the "design" product_definition and another based on the "manufacturing" product_definition. The various product_definitions can move into other life cycle stages for the product as well. In this way, usages or parts lists can be defined for any of a number of views and life cycle stages of a design.

AP 210 requires that all assembly_component_usages and therefore all next_assembly_usage_occurrence entities be associated with a security_classification.

Pre-processor Recommendations: The id attribute of the next_assembly_usage_occurrence must be constructed so as not to duplicate any assignments made to other entities which are sub-types of product_definition_relationship.

The security_classification classification officer, classification date, approvers and approval dates can be extrapolated from the version creator and approval data for the assembly part if no appropriate data is available.

Instances in Multi-Level Assemblies

Reference designation

AP 210 supports data in conformance with IEC 750:1983 through the use of reference designation for components. Use of AP 210 consistent with this IEC standard provides the ability to unambiguously identify individual component locations in the product definition. The use of reference designation often makes other forms of instance tracking through multiple levels of assembly unnecessary.

Quantities in Assemblies

AP 210 provides for designating quantities of components in next assemblies and higher assemblies. The most common types of quantities are next assembly quantity and quantity for an end item. A next assembly quantity is the amount (count or other measure) of a part in its immediate parent part. The quantity for an end item is the amount (count or other measure) of a part in a finished manufactured item. The end item itself is designated by the organization and may be a configuration item. These two types of quantity and their related data is typically what comprises the body of a parts list. Much of the normal industrial usage of AP 210 is for the end item and the next assembly to be the same instance.

Next Assembly Quantity

AP 210 provides two methods for specifying next assembly quantity. One method is to count the number of next_assembly_usage_occurrences where the pair of the relating_product_definition and related_product_definition attributes are identical among multiple instances of the next_assembly_usage_occurrence entity. This type of quantity specification can only be used for items which are counted one piece at a time as there can be no unit of measure attached to this type of quantity. This method is extremely valuable where all instances of a component are specified geometrically as well as in the product structure. This method is used where the reference designation is applied in accordance with the principles of IEC 750:1983.

The other method of specifying next assembly quantity in AP 210 is by creating a complex instance involving both next_assembly_usage_occurrence and quantified_assembly_component_usage. The quantity is explicitly stated in the measure_with_unit related to the quantified_assembly_component_usage.

Note: Since these constructs are sub-types of assembly_component_usage, they will require a security_classification.

Quantity designations are used on parts lists for products. The AP 210 data structure is quite capable of providing the data for the body of a parts list. The information for each record in this list is generated for an assembly by obtaining the data for the products related to it through next_assembly_usage_occurrences.

Specified Higher Usage Occurrence

There is no standard mapping for specified_higher_order_usage_occurrence. This entity type may be used to capture properties related to an instance within a multi-level assembly where the instance property is spacially and environmentally dependent (e.g.. temperature of a component where the assembly the component is part of is used multiple times in higher level assemblies, as in an equipment rack with multiple line cards and the temperature of the voltage regulator in line card three is of interest.). The specified_higher_usage_occurrence would also allow direct identification of the reference designation as specified in IEC 60750:1983. Note that as described above, the reference_designator attribute of assembly_component_usage as defined in ISO 10303-41 (1994) is considered a partial reference designation in the context of IEC 60750. For further details of application of specified_higher_usage_occurrence, reference AP 209 recommended practices document.

Make from Part

For a make from part, the same rationale is applied to the design_make_from_relationship with the resultant part from the make from also being called out. Reference the Make from relationships discussion in this document.

Material Callout

For a material callout, the parts list is determined from the material_specifications related to its product_definition unless the bulk material is assigned a part number internally by the organization or a quantity unit of measure other than a simple count is needed. If a bulk material is assigned an internal part number by an organization or a unit of measure other than a simple count is needed, the usage of the material becomes a next_assembly_usage_occurrence. Material callout for bulk material is formalized in AP 210 with the ARM Application object of Assembly_material_composition_relationship and the relevant mapping table.

End Item Quantity

End Item Quantity is the total quantity of a component in either the entire delivered unit or some major subsection of a delivered unit. This quantity is designated in AP 210 by establishing a complex instance of promissory_usage_occurrence and quantified_assembly_component_usage. The quantity in the measure_with_unit related to the quantified_assembly_component_usage is the quantity of the part in the final article. This relationship is described pictorially in Figure 8.

Figure 8. End item quantity

It should be noted that this could be a simple direct relationship or a more complex relationship. In the simple instance, the relating_product_definition will point to the product_definition of the product which is designated as the end item. In this case, the quantity is the total for the component (specified by the related_product_definition) in the end item for the indicated effectivity. In the more complex instance, the relating_product_definition will point a product_definition of a higher assembly which is not the end item. In this case, the quantity is for the component (specified by the related_product_definition) in the assembly (specified by the relating_product_definition) as the assembly is used in the end item for the indicated effectivity.

Promissory_usage_occurrence

Since promissory_usage_occurrence is a sub-type of assembly_component_usage, it will require a security_classification. This relationship is a type of product_definition_relationship and as such may have specifications related to it.

Note: The relationship described here is intended for part based systems and has been show to be problematic for drawing based systems.

Substituting Parts in Assemblies

Refer to the following subclause in this document: "Alternate product concepts in AP 210.

Assemblies and Shape

The shape of an assembly is most often derived from the shape of its components. AP 210 provides three methods for dealing with the shape of an assembly. These are: replicating the shape of the components in the shape of the assembly, mapping the shape of the component into the shape of the assembly, and referencing the shape of a component. The following subsections will deal with each of these methods. AP 210 provides component_definition to represent the occurrence of a part in the the assembly. There is the possibility for the part shape, the assembly_component shape and the assembly shape to exist at the same time. Details of implementation scenario will determine the usefulness of maintaining a shape occurrence for the component_definition separately from the shape of the part.

Replicated Shape

One method for representing the shape of an assembly is to collect together all the elements of all the shapes of all the components explicitly in the shape of the assembly. This is the typical practice used in industry today, but it is highly inefficient. Using this method, the shape entities of the components of an assembly become shape entities in the assembly. The assembly shape becomes a conglomerate with no segregations of the various component shapes. This is represented by collecting all the geometry and topology of the components in an appropriate sub-type of shape_representation. Use of this capability is deprecated, but is provided in order to be backward compatible with AP 203.

Mapped Shape

In this method, the shape of the component is mapped into the shape of the assembly. This is done through the use of the mapped_item entity which can be used to map one shape_representation into another. (See G.1.15 on page 84 for an implementors agreement that affects this entity.) This method is the most efficient and versatile, but it may only be used where the component and the assembly shapes are of the same type of shape_representation. In this case, there need not be a shape occurrence for the component_definition that is a separate shape occurrence from that for the part. AP 210 provides a label for shape_representation_relationship of 'component part planar shape' to indicate that this shape is to be used for both component_definition and the part definition.

The mapped_item entity is used for transformation without scaling on the component shape. Transformation without scaling is accomplished by relating an axis2_placement in the component identified as the mapping_origin in the representation_map to an axis2_placement in the assembly identified as the mapping_target in the mapped_item. AP 210 extends this by using a cartesian_transformation_operator_2d (in place of the axis_placement) for the planar case.

Referenced Component Shape

In this method, the shape of the part is referenced to the shape of the component_definition through the same shape_representation_relationship, but there are two separate shape occurrences. The shape of the component_definition is still mapped using mapped_item to the shape of the assembly, so those two shapes have to be compatible.

Referenced shape

In this method, the shape of the part is referenced or related to the shape of the assembly. This is done through the use of the context_dependent_shape_representation entity. This method is not dependent on both the component and assembly shapes being the same type of shape_representation.

In this method, a complex instance of representation_relationship, representation_relationship_with_transformation, and shape_representation_relationship relates the shape_representations for the component and assembly together and relates an item_defined_transformation to the relationship. The context_dependent_shape_representation entity relates the complex relationship with the transformation to a product_definition_shape which is related to the next_assembly_usage_occurrence. Reference the AP 203 recommended practices for more details on this approach. Since the primary vehicle in AP 210 is use of library data, it is not expected that this option will be of much interest for purely AP 210 applications, but will primarily be of interest for data sharing between electrical and mechanical systems in order to preserve existing geometric models.

Assemblies and Specifications

AP 210 provides explicit ARM concepts to support product specifications. Reference the ARM concepts of Requirement_allocation and Specification_allocation for further information. There are standard mappings provided in clause 5.1 of the standard to support these requirements.

Engineering Release/ Change Data

AP 210 provides data structures for representation of the data used in the engineering release and change process. The structures are based on a request and action process where a request is established documenting the need for a potential release or change which may or may not ever be incorporated. If the request is incorporated, it is done through some action being taken on the request which results in either a new release of a design or a change to a existing design.

It should be noted that these constructs have been designed to represent all request and incorporation structures in the AP 210 application domain. All release and change proposals and requests (Engineering Change Proposals, Requests for Engineering Action, etc.) are represented by the request portion of the structure. All release and change incorporations are represented by the action portion of the structure. Differentiation between types of requests and actions can be done structurally based on the guidance in this section, by its identification (id for requests, name for actions), or by the originator. Differentiation by identification or originator is very process dependent but can be necessary particularly for preliminary requests and proposals.

Some types of releases and changes in organizations may not involve a two step process. In this case, both data structures are implemented simultaneously and reference the same release or change documentation. Since these constructs in AP 210 are intended to support many different release and change processes/documentation, in some cases, some of the required data may not exist.

The release process is initiated through an AP 210 versioned_action_request which is related to the design being released through a start_request. The versioned_action_request has a related action_method. In this case, both the versioned_action_request and the action_method would indicate that the respective purposes were to initially release the design or create the design for the initial release. This request process is followed (in the data) by an action_directive which is related to the design to be released through a start_work. The action_directive also identifies the start_request as the request being satisfied/ incorporated. A directed_action relates the action_method to the action_directive which in the case of initial release may be moot. The structure of these relationships (at a high level) is shown in Figure 9.

Figure 9. Change requests

The change process is initiated through an AP 210 versioned_action_request, as well, which is related to the design proposed to be changed through a change_request. The versioned_action_request has a related action_method. In this case, there may be many action_methods or ways to solve the problem. This request process is followed (in the data) by an action_directive which is related to the new design or version to be released through a change. The action_directive also identifies the change_request(s) as the request(s) being satisfied/ incorporated. A directed_action relates the action_method to the action_directive indicating which of possibly many methods for the request or requests incorporated was chosen. The structure of these relationships (at a high level) is shown in Figure 9.

Requests for Release/Change

Requests for release or change are created in AP 210 by relating a versioned_action_request to a product_definition_formation through a start_request or change_request. The start_request or change_request identifies through the items attribute the product_definition_formation to be released or changed. In the case of a start_request, this is a bit odd as this structure in AP 210 requires an identification of a version at request time which will in fact result from the request. This may be changed in future editions of the AP.

The versioned_action_request id attribute contains the identification of the request. This information is the document or request number. The version attribute is the version of the request itself. This attribute is used to identify actual versioning of the request or reissues of the request. The purpose attribute should contain text identifying the end result anticipated from this version of this request. The description attribute should contain a general description of the request. In AP 210, a versioned_action_request is required to have an associated action_request_status. The AP restricts the values for the status attribute to "proposed", "in_work", "issued", or "hold".

A request for release or change may have many possible ways it can be resolved. This is more common for changes than releases, but the AP 210 data structure supports the documentation of the engineering thought process gone through in either case. This is accomplished through a combination of the action_request_solution and action_method entities. Action_request_solution relates an action_method to a versioned_action_request. The action_method name attribute should contain a reference to any formal documentation for a proposed solution to the release/ change request. The description attribute should contain a detailed description of the method through which the request is to be satisfied. The consequence attribute should contain any determined or perceived consequence to using this method to satisfy this request. The purpose attribute should contain the intention of the method as a single method may be used to satisfy many requests.

AP 210 requires that a start_request and a change_request have a related approval. As these requests normally have a number of signatories, there should be no problem obtaining this data if it is stored in electronic form. A start_request or change_request is required to be associated with a date and time in the role of "request_date" which indicates when the request was created. Lastly, a start_request or change_request is required to be associated with at least one person and organization in the role of "initiator" or "request_recipient".

AP 210 provides the ability to identify specifically what product data entities differ from one revision to the next, with the use of:

• add_design_object_assignment,
• add_design_object_request_assignment,
• change_from_design_object_assignment,
• change_to_design_object_assignment,
• change_from_design_object_request_assignment,
• change_to_design_object_request_assignment.
• delete_design_object_assignment,
• delete_design_object_request_assignment,
• product_definition_relationship name attribute of {design object addition, design object deletion, design object change},

AP 210 provides the ability to state the characteristics that are the reason for the change or work item with the representation_relationship with name attribute of 'evaluated characteristic'. The representation_relationship is one of the items in the start_request or change_request if it is supplied. Otherwise the reason is encoded in the purpose attribute of versioned_action_request. The DIS version of AP 210 AIM did not contain representation_relationship in the items attribute of these entities. This has been added for the IS version.

Release/Change Incorporation

Release of a design or change incorporation into a design is accomplished in AP 210 through the start_work and change constructs which relate an action_directive to the new design or new design version by pointing to the product_definition_formation which results from the release or change. A directed_action related to the action_directive identifies the action_method actually used to satisfy the requests related to the action_directive. In the case where many requests are being incorporated, there many be many directed_actions to indicate the appropriate methods.

The action_directive name attribute is the identification of the formal documentation to incorporate the change or release the design. In cases where there is no second set of paper work or documentation (i.e. there is a one to one correspondence between versioned_action_request and action_directive), the action_directive name value is the same as the versioned_action_request id value. The description attribute should contain a phrase or group of phrases indicating the final result of the release or change. The analysis attribute should identify any investigative results which support the release or change. Likewise, the comment attribute should contain any textual commentary which supports the release or change. An action_directive may be associated with an action_status which serves the same function as action_request_status in the previous request section. It is not required, in AP 210, that the action_directive be related to an action_status as the two sets of data may represent one or two documents.

The directed_action name attribute should contain the identification of the formal documentation as to why the method identified was chosen. The description attribute should contain a textual description, either in summary or detail, supporting the chosen method.

In AP 210, a start_work or change is required to have an associated approval. If these constructs are representing the same document, they could share the approval. A start_work or change is required to have a date and time associated with it in the role of "start_date" which is when the work to satisfy the request or requests began. Once completed, a start_work or change may have a date and time associated with it in the role of "release_date".

Release/Change Reissues

Engineering release and changes are reissued. This can be caused by an error or omission in the change package. It may also be done to signify changes in effectivity which have no effect on the version of the part.

AP 210 supports the reissue of releases and changes. To reissue a release or a change, a versioned_action_request is created with an id attribute value equal to the action_directive name being reissued. The versioned_action_request version attribute contains the reissue identifier. This new versioned_action_request is added to the set of requests in the original action_directive that was issued.

Configuration Identification

Configuration identification in AP 210 is done through the configuration_item entity. This entity identifies products as end items or items which are sold or delivered. As in industry, this designation can be applied to full systems or spares (which are also referred to as the lowest level replaceable units).

The configuration_item id attribute is a unique identification of the item which may be a part number but more probably a moniker. The name attribute is a short description of the item. The description attribute is optional and would be the expanded name or description of the item. The purpose attribute is also optional and would contain a description of the item's intended use.

A configuration_item is related to a product_concept. The product_concept id attribute is more commonly known as the model designation. The product_concept taken together with the configuration_item describe a model series or configured production run. The name attribute is a short description of the model. The description attribute is the expanded name or description of the model. The product_concept is related to a product_concept_context where the market_segment_type attribute identifies what customer or group of customers provided the requirements for the model.

AP 210 requires that a configuration_item have an approval. A configuration_item must also be associated with a person_and_organization in the role of "configuration manager".

Pre-processor Recommendations: In some cases, it may be difficult to determine the approval and "configuration manager" for a configuration_item. If the item has effectivity (see next section), this information may be extrapolated from the approval and "creator" information for the product_definition_formation for that product. If not, this information should be obtained from user input or a default based on the configuration_item id attribute.

Effectivity

Effectivity is the designation that something or a relationship between two things is used or planned to be used in some configuration_item. In AP 210, effectivity is designated on relationships between product_definitions by either ranges of serial numbers, ranges of dates or a lot. This is accomplished through a complex instance of the entities effectivity, configuration_effectivity, product_definition_effectivity and one of either serial_numbered_effectivity, dated_effectivity or lot_effectivity.

A serial_numbered_effectivity specifies an effectivity_start_id with an optional effectivity_end_id. If the effectivity_end_id does not exist, the effectivity is good for the starting serial number and all following serial numbers. A dated_effectivity follows the same pattern using dates rather than serial numbers. A lot_effectivity indicates an effectivity_lot_id and an effectivity_lot_size.

The above entities specify the effectivity identifiers. These entities are related to a product_definition_relationship through the usage attribute in the product_definition_effectivity entity. The effectivity entity id attribute has no standard mapping. The configuration_effectivity entity relates these relationships to a configuration_design which relates a configuration_item to a product_definition_formation or design version. Figure 10 shows this relationship pictorially for a serial_numbered_effectivity.

Figure 10. Effectivity

The whole relationship here can be simply stated as a range of serial numbers, dates or a lot number related to a product_definition_formationor design version which is designated as a configuration_item. This does mean that all configuration_items must be associated to a design version in order to have effectivity. In AP 210, an effectivity requires an approval. This information may be difficult to find in some instances (see pre-processor recommendations for guidance.

It should be noted that since the effectivity is related to a product_definition_relationship, many different views of the effectivity can be established by varying the relating_product_definition. AP 210 can maintain one effectivity based on the "design" product_definition and another based on the "manufacturing" product_definition. The various product_definitions can move into other life cycle stages for the design as well. In this way, effectivities can be defined for any of a number of views and life cycle stages of the design.

The conformance classes in AP 210 do not require that effectivity relationships be instantiated. The reason for this is that there are occasions where data needs to be exchanged or shared prior to an effectivity being defined. This tends to occur early in a new design.

All effectivities in AP 210 are explicit effectivities and there are no assumed effectivities. Some systems in existence today assume a part is effective for all planned or actual instances of a product model if the effectivity is not explicitly defined. This is not the intent in AP 210. If a part has no effectivity in the AP 210 data structures, it has no effectivity. If a part is effective for all instances of a product model, the data should explicitly state all the effective instances. The effectivities in AP 210 contain open ranges for serial numbers and dates to allow for open or full effectivities. Using these constructs, all that is required is a start point. If there is a desire for full effectivity and the start point is not defined, the value "1" should be used for the serial_numbered_effectivity effectivity_start_id or the equivalent date of January 1st year 1 should used for dated_effectivity effectivity_start_date.

Note: Open effectivity does not make sense for a lot effectivity as it is inherently closed (other than lot size). Lot effectivity is typically an effectivity designated in the manufacturing view of a product or part.

The exchange or sharing of effectivity information creates the need for optional processing capability in at least pre-processors to allow for perspective. It is typically desirable for the lead contractor in a partnership or team to provide effectivity definitions to sub-contractors. It is usually undesirable for the lead contractor to utilize effectivities echoed back by sub-contractors as they reflect what was originally sent but not necessarily the most current data (in some cases).

The above is a simple case. Most cases involve even more variables such as who in the exchange or sharing arrangement is the defining body for the effectivity of a particular part or usage. One way to deal with this situation is for pre-processors to provide options for ignoring effectivity entirely, loading it or either ignoring or loading it based on externally defined criteria such as the part's design owner, design supplier or part number and for post-processors to provide a switch for a user choice on whether or not defined effectivity information in the system should be used in the interchange.

Pre-processor Recommendations: There is no standard mapping for the id attribute of the effectivity entity. Since there is no standard mapping in the AP 210 application domain for this attribute, it is recommended that this attribute contain a null string as minimal content or any appropriate/ mutually agreed upon string. If the effectivity approval information is not readily available, it can be extrapolated from the engineering change which designated the effectivity. Pre-processors should interpret the value "1" for the serial_numbered_effectivity effectivity_start_id or the equivalent date of January 1st year 1 for dated_effectivity effectivity_start_date as full or open effectivity when the values are specified with no ending range value. It is recommended that pre-processors provide options for ignoring effectivity entirely, loading it, or either ignoring or loading it based on externally defined criteria such as the part's design owner or part number to allow for a user choice as to whether the data is utilized or not depending on the source.

Post-processor Recommendations: There is no standard mapping for the id attribute of the effectivity entity. Since there is no standard mapping in the AP 210 application domain for this attribute, it is recommended that post-processors assign no processing significance to this value. When there is a need for full effectivity and the start point is not defined, post-processors should use the value "1" for the serial_numbered_effectivity effectivity_start_id or the equivalent date of January 1st year 1 for dated_effectivity effectivity_start_date. It is recommended that post-processors provide a switch for a user choice on whether or not defined effectivity information in the system should be used in the interchange.