ISO 10303-214:2010(E)

5.2.1 Fundamental concepts and assumptions

This subclause describes fundamental concepts and assumptions related to the data structure defined within this part of ISO 10303.

ISO 10303-214 is designed to be used for data exchange, sharing, modeling, and storage in the design phase.

The intention is to gather information on a technical product related to various applications of product data.

5.2.1.1 Usage of global rules

Many of the relationships among different entities in the integrated resource parts of ISO 10303 are specified using the most generic cardinality of zero or more between two related entities. This cardinality means that the relationship is optional or there may be one or more instances of a related entity that is related to a single instance of the relating entity or vice versa.

This part of ISO 10303 uses global rules to constrain these cardinalities.

Examples of these rules include product_requires_category and restrict_effectivity_for_effectivity_relationship.

Global rules are also used to restrict values of STRING type attributes to be only those that are applicable within the context of ISO 10303-214.

5.2.1.2 Product, Product Versions, and Views on Product Versions

Every product has to be related with one or more instances of product_definition_formation, each representing a version of the product.

A product_definition_formation may be represented by different instances of representation such as various kinds of geometric representations, kinematic structures, drawings, i.e., different kinds of data for a product.

product_definition represents a view onto the data of a product_definition_formation and establishes the relationship to the various representations. Note that representations may be shared by several product_definitions (views). Also a product_definition may have several alternative representations of the same kind, e.g. shape_representations of a wireframe and a surface model, attached to it.

5.2.1.3 Context information

5.2.1.3.1 application_context

The application_context entity identifies the application domain that defined the data. The application_context entity may have an identifier associated with it through the entity id_attribute and its attribute_value attribute. The application_context entity may have a description associated with it through the entity description_attribute via the attribute attribute_value. The application attribute identifies the name of the general application domain that defined the data.

This entity should be instantiated once in the data set for each relevant application domain. Where appropriate, the value 'assembly study', 'digital mock up', 'process planning', 'electrical design', or 'mechanical design' should be used. Note that 'electrical design' and 'mechanical design' are not understood to mean the design life cycle - e.g., within the application domain 'mechanical design', you may have concurrent 'manufacturing' and 'design' life-cycle view definitions.

5.2.1.3.2 product_context

The product_context entity is a subtype of application_context_element.

All STEP products must be founded in a product_context to specify the point of view on the application. The product_context entity identifies the engineering discipline's point of view from which the data is being presented.

This entity will establish the context perspective and source of requirements for product entities. The discipline_type attribute contains a description of the discipline point of view for a product. It is recommended to instantiate this entity exactly once in the data set.

5.2.1.3.3 product_definition_context

The product_definition_context entity is a subtype of application_context_element.

All STEP product_definitions must be founded in a product_definition_context to identify the product definition type and life-cycle stage from which the data is viewed.

There are two ways to implement the product_definition_context:

The value of the attribute product_definition.frame_of_reference is a product_definition_context that represents the 'primary' defining context for a view. In general this defining context is qualified both by type (product_definition_context.name) and by life-cycle (product_definition_context.life_cycle_stage) information. The primary context also has associated application domain information. The inherited name attribute provides a distinction on the type of view on a part version ('part definition') from one of a document version ('digital document definition', 'physical document definition'). This attribute may also indicate other types of definitions: e.g., 'functional definition' for a product_function, 'conceptual definition' for a product_component, or 'spatial' and/or 'zonal'.

NOTE 1 sharing of this kind of product_definition_context entities is not possible by different ARM objects product_function, product_component, or design_discipline_item_definition because of different application_context_element.name values.

The life_cycle_stage attribute identifies the life-cycle view on the associated product_definition. Recommended values include 'design' and 'manufacturing'.

NOTE 2 There are no constraints for sharing of this kind of product_definition_context entities by different ARM objects product_function, product_component, or design_discipline_item_definition, even if referred by product_definition.frame_of_reference.

The product_definition_context_association entity allows for multiple additional contexts to be associated with a single product_definition.

There is always one required 'primary' context that identifies the defining application domain and life-cycle information. Additional product_definition_context entities identify additional concurrent relevant views on the product_definition.

These product_definition_contexts are related to the product definition by product_definition_context_association.

5.2.1.4 Shape of a product

5.2.1.4.1 Relating the shape of a product to administrative product data

The shape of a product is represented by shape_representation.

This entity and its subtypes are defining valid combinations of entities of type geometric_representation_item and topological_representation_item to describe the shape of the product.

shape_representation is related to product_definition by shape_definition_representation and product_definition_shape, which points to product_definition via two select types: characterized_definition and characterized_product_definition.

Due to the global rule shape_representation_subtype_exclusiveness, shape_representation shall be an instance of at most one of its subtypes.

5.2.1.4.2 Identification of a portion of the shape of a product

A portion of the whole shape of a product may be identified by a shape_aspect that points to a product_definition_shape. The shape_aspect may be related via shape_definition_representation to shape_representation, representing the portion of shape.

5.2.1.4.3 Types of shape representation

By this part of ISO 10303 nine model types for representation of the shape of a product are defined:

All these except for the last are subtypes of shape_representation.

Each type is self contained, meaning that one type may not contain another, enforced by the global rule shape_representation_subtype_exclusiveness.

Local rules, defined for every subtype, describe restrictions on geometric and topological entities, as applicable, that may be referenced by the respective shape_representation subtype. The local rules in the subtypes of shape_representation uniformly allow for instances of axis2_placement, mapped_item, and one or more specific subtypes of geometric_representation_item according to the subtype of shape_representation. In the case of a mapped_item, the mapped_representation of the associated instance of representation_map is restricted to the same subtype of shape_representation in order to avoid mixed shape representation types.

The shape_representation with a name of 'hybrid 3D shape representation' is an exception of this rule. It is especially created to allow for a mix of different kinds of shape_representation as it usually occurs in CAD systems. Therefore the allowed types of instances of geometric_representation_item are not further constrained, and the type the mapped_representation for a mapped_item instance is restricted to shape_representation only, but not to a specific subtype.

5.2.1.4.4 Relation of units, coordinate space, and accuracy information to shape information

Information on units related to the shape of a product as well as information on the coordinate space and the accuracy (uncertainty) of the shape information is assigned to instances of shape_representation by subtypes of representation_context, i.e. global_unit_assigned_context, geometric_representation_context, and global_uncertainty_assigned_context, respectively.

These subtypes allow for definition of a set of units, of the coordinate space dimension, and of one to three accuracy values for distance, angular, and curvature accuracy to be assigned to a shape_representation.

In the case where an instance of representation_context shall be shared by two or more shape_representation instances with different accuracy values, complex instances of shape_representation and uncertainty_assigned_representation shall be used to assign the various accuracy values through the uncertainty_assigned_representation instances independent from the representation_context. The accuracy information defined by the uncertainty_assigned_representation takes precedence over any global_uncertainty_assigned_context that is referenced by the shape_representation.

5.2.1.5 Product structure

This clause describes the AIM entities used by this part of ISO 10303 that provide the capability to describe explicit hierarchical product structures representing assemblies and the constituents of those assemblies. These explicit part structures can be used to define the traditional engineering and manufacturing bill of material indentured parts list. Each assembly and constituent part within an explicit hierarchical product structure is defined by a product that is element in the set of products of a product_related_product_category with a name of 'part'. A product that is categorized as part may be a single piece part or an assembly of arbitrary complexity. Associated product_definition_formations represent specific versions of the base product. product_definitions attached to these product_definition_formations represent particular views on a product_definition_formation that may only be relevant for the requirements of particular life-cycle stages (e.g., design, manufacturing) and application domains. There may be more than one product_definition associated with a particular product_definition_formation.

Relationships between product_definitions that have an associated product_definition_context with a name of 'part definition' are the principle elements used to define explicit hierarchical product structures.

In order to define different types of assembly relationships, assembly_component_usage has various subtypes:

If a next_assembly_usage_occurrence is not instantiated in combination with a quantified_assembly_component_usage, it is used to represent a single occurrence of the component part in the context of the immediate next higher assembly part.

A promissory_usage_occurrence may be instantiated in combination with a quantified_assembly_component_usage.

If the quantity, in which the component part is used in the assembly can not be expressed as a particular value, but depends on certain constraints, an assembly_component_usage relationship with a name of 'selected instance usage' shall be used instead of the quantified_assembly_component_usage subtype with an associated property_definition and an associated representation with a name of 'selection criteria' that defines the quantity by a representation_item with name 'selection quantity' of type measure_representation_item or value_range.

The specified_higher_usage_occurrence identifies with its inherited attribute related_product_definition the component in the assembly structure, with its inherited attribute relating_product_definition the higher-level parent assembly, with the next_usage attribute the component usage within the immediate parent assembly, and with its upper_usage attribute the usage between the higher-level parent assembly and the immediate parent identified by next_usage. In case the higher-level parent assembly to the component has more than one intermediate assembly level the upper_usage attribute refers to another specified_higher_usage_occurrence (recursive use). See Figure 78 for an example instantiation.

The assembly_component_usage and its subtypes described above represent individual usages, i.e., occurrences, of either a single or multiple instances of a component part in the context of an assembly part, i.e., within an explicit hierarchical part structure. In order to be able to use and represent these individual occurrences in the context of specification control (UoF S7), e.g., to configure them for the usage in the context of a product_class, or to use them in the context of variational bills of material as product constituents in conceptual or functional definitions or in alternative solution definitions of those, a separate product_definition has to be created describing an individual occurrence view of the component part.

When moving from an explicit part structure to a variational product structure, individual usages of a component part in the context of an assembly part that are described as part of an explicit hierarchical part structure by assembly_component_usage relationships or its subtypes, have to be related to a corresponding product_definition with an associated product_definition_context with a name of 'part occurrence' through a product_definition_occurrence_relationship.

The product_definition_occurrence_relationship associates this product_definition and the assembly_component_usage. The product_definition referenced by the occurrence attribute has an associated product_definition_context with a name of 'part occurrence'. It represents explicitly an occurrence of the component that is also implicitly defined by the associated assembly_component_usage.

The definitional product_definition of the component (with product_definition_context with name 'part definition') is referred to by the inherited related_product_definition attribute of the assembly_component_usage as well as associated to the product_definition representing explicitly the occurrence through a product_definition_relationship with a name of 'definition usage' (see Figure 79 for an example instantiation).

Thus, the product_definition_occurrence_relationship allows the association of an individual occurrence of a constituent part definition in an explicit part structure, represented by assembly_component_usage relationships, to a specific product_definition describing explicitly the individual occurrence of the component part in the context of specification control (UoF S7). See Specification control in clause 5.2.1.8 for further details about the usage of those product_definitions for specification control.

5.2.1.6 Shape of an assembly

5.2.1.6.1 Relating the shape of a component to the shape of its assembly

In order to build assembly structures, relationships between the assembly and component(s) have to be defined.

Two alternatives for the implementation of assembly structure representations are recommended:

Both mechanisms make sense even in mixed combinations. The product structure, i.e. next_assembly_usage_occurrence is identical and is required for both approaches.

5.2.1.6.2 mapped_item approach

This approach represents the assembled model completely. It is appropriate for explicit representation of assemblies. It uses mapped_item in combination with representation_map which takes a representation, i.e. the shape_representation of the component and turns it into an item in a second representation, i.e. a mapped_item included in the shape_representation of the assembly. The transformation to be applied is determined from the mapping origin and the mapping target, which are items of the two instances of representation and therefore founded in the two contexts. mapped_item is constrained such that:

There is no constraint to prevent both instances of representation having the same context (i.e. the new item is shifted in position but does not change spaces). This allows the use of mapped_item to position sub-models in a single coordinate space. It is even possible to define an identity matrix transformation by referring to the same entity instance as both mapping_origin and mapping_target. This represents the case where a component is defined in (one of) its final positions. Until it is mapped into the second representation, it is not included in the representation even though defined in the same space.

The mapping of the Assembly_component_relationship implies that the relationships between the assembly and the component on the product_definition level and the mapped_item for the shape_representation level have to be linked through an additional separate shape_representation containing, only the mapped_itemand a shape_definition_representation and a product_definition_shape.

This is necessary to distinguish between several occurrences of the same component within an assembly.

5.2.1.6.3 representation_relationship_with_transformation approach

This approach represents the components and the set of instructions how to build the assembly. This approach is adequate for the implicit representation of assemblies.

Thus, representation_relationship_with_transformation is used to define the relative positions within an assembly. It does not allow for:

The shape_representation may be defined explicitly and completely for the assembly and the representation_relationship_with_transformation gives just the additional information how an instance of shape_representation for a component geometrically relates to the shape of the assembly.

The rule coordinated_assembly_and_shape implies that the relationships between the assembly and the component on the product_definition level and the shape_representation level have to be linked through a context_dependent_shape_representation.

This is necessary to distinguish between several occurrences of the same component within an assembly.

According to ISO 10303-43 the attributes rep_1 and rep_2 of representation_relationship_with_transformation are determined as follows:

Based on this definition, the attributes of representation_relationship_with_transformation should be instantiated as follows:

Further restrictions are implied by the informal proposition on representation_relationship_with_transformation, defined in ISO 10303-43: If the transformation is an item_defined_transformation, the ordering of the instances of representation given for the inherited attributes of representation_relationship shall be consistent with the ordering of the two instances of representation_item given as attributes of item_defined_transformation.

Therefore the inherited attributes transform_item_1 and transform_item_2 of item_defined_transformation shall be used as follows:

5.2.1.6.4 Representation of transformations

Transformation information is represented for an item_defined_transformation using the inherited attributes transform_item_2 and transform_item_1, and for a mapped_item using attribute mapping_target of mapped_item and attribute mapping_origin of the referenced representation_map as a combination of two instances of representation_item.

The allowed combinations for these two instances of representation_item are as follows:

For a representation_relationship_with_transformation there may be also an instance of functionally_defined_transformation used that is a cartesian_transformation_operator.

For any usage of an instance of cartesian_transformation_operator to define the transformation information of an instance of assembly_component_usage the derived attribute scl shall be 1.0, since scaling is not allowed for components within an assembly.

5.2.1.7 Document management

5.2.1.7.1 Document identification

This standard deals with documents as products, according to an interpretation of 'Document as Product'. As with 'Part as Product', there are three basic concepts central to document identification:

These fundamental concepts are described for 'Part as Product' also in clause 5.2.1.2. The following provides specifics on the distinction and additions for the 'Document as Product' approach.

'Document as Product' identifies a managed document object in a PDM system.

A managed document is under revision control, and may distinguish various representation definitions of a document version. The document version represents the minimum identification of a managed document under revision control. A document representation definition may optionally be associated with one or more constituent external files that make it up.

EXAMPLE 1 A configuration controlled managed paper document like a drawing would generally be represented by the entity product, with version identification and a (physical) representation/view definition according to the 'Document as Product' approach.

External files in the PDM schema represent a simple external reference to a named file. An external file is not managed independently by the system - there is usually no revision control or any representation definitions of external files. Version identification may optionally be associated with an external file, but this is for information only and is not used for managed revision control.

If a file is under configuration control, it should be represented as a constituent of a document definition. In this case it is actually the managed document that is under direct configuration control, the file is in this way indirectly under configuration control. A change to the file results in a change to the managed document (i.e., a new version) - the changed file is a constituent of a document definition of the new document version. A simple external reference alone is not configuration controlled, it is just an external file reference to product data.

Documents may be associated with product data in a specified role, to represent some relationship between a document and other elements of product data.

Constraints may also be specified on this association, in order to distinguish an applicable portion of an entire document or file in the association. With 'Document as Product', additional entities are required to relate a managed document to other product data. Included among these is the entity document.

The document.id should not be used as valid user data - the document entity does not always need to be instantiated using 'Document as Product', it is done only to assign the document to other product data via applied_document_reference.

5.2.1.7.2 Document as product

The interpretation of 'Document as Product' uses basic product master identification for the fundamental requirements of document identification, versioning, and representation definition. 'Document as Product' is distinguished from 'Part as Product' in each of the three basic elements of product identification:

Document, Document versions, and Document definitions As with 'Part as Product', the concepts of base identification, version identification, and view definition are structurally the same as in 'Document as Product'.

Base document identification is represented by the entity product referred to by a product_related_product_category with a name of 'document' (to make the distinction to 'Part as Product') and is always associated with at least one document version represented by the entity product_definition_formation. Multiple document versions of a base document identification may be related together by product_definition_formation_relationship to represent document version history.

Context information Context information provides a scope and necessary circumstance for product identification information. It consists of two separate and related areas:

Application protocol identification and general context information are handled structurally the same for 'Document as Product' as for 'Part as Product'. A single instance of the entity application_context should be referenced by all product_context entities, for both parts and documents. This application_context should be referenced by the single instance of the entity application_protocol_definition.

The application context information is managed differently to distinguish documents from parts:

5.2.1.7.3 Document definition

The product_definition entity denotes the definition of a particular view of a representation of a document version. There may be more than one document definition associated with a single document version. The document definition of a document version is used for association of document properties, to build document structures, or to associate a document with the set of constituent external files that make it up. The entity product_definition supports property association and document structure by product_definition_relationship.

The subtype product_definition_with_associated_documents is used to associate a representation of a document version with the set of constituent files that make it up. The id attribute indicates the unique identifier of the document definition. The value shall be unique relative to other product_definition entities related to the same product_definition_formation. The description attribute provides optional additional words describing the document definition; the formation attribute references the document version of which this is a document definition; the frame_of_reference attribute references the context information related to this document definition.

5.2.1.7.4 Document type classification

Following the 'document as product' approach the type classification of managed documents is done in symmetry to the specific type classification for parts.

There are two classification mechanisms that can be used when exchanging classification information with this Standard. One type of classification works by assigning categories to product data items. These categories are identified by name labels that define the related classification. This type of classification is referred to as specific classification in the ARM. It provides the basic capability to distinguish product entities interpreted to represent documents from those interpreted as parts by product_related_product_category referring to the product and with the inherited name attribute set to 'document' for the 'Document as Product' case or to 'part', 'tool', or 'raw material' for the 'Part as Product' case. Other values for the name attribute may be used additionally for a more specific classification of documents.

The specific classification capability relies exclusively on the name labels of the categories for the interpretation of the category semantics. Exchanges of specific classification information are only meaningful when the category names are agreed upon between the exchange partners.

All the categories used for the specific document type classification of managed documents should be defined in a single taxonomy with the product_related_product_category with name attribute ‘document’ as the root element. The category hierarchy is defined via relating the categories as super/sub-categories by a product_category_relationship.

To fulfil advanced requirement there is the possibility to classify product data items according to a classification system with explicit reference to the classification criteria and related properties of the product data items.

This classification mechanism is called General_classification in the ARM.

The class or externally_defined_class entity identifies the classification information.

This information can be associated to product, product_definition_formation, product_definition and document_file by applied_classification_assignment.

It allows for the classification of documents, document versions, document representations and document files in the ARM.

5.2.1.7.5 External files

External files represent a simple external reference to a named file. The external file may identify a digital file or a physical, 'hardcopy' file. As opposed to a managed 'Document as Product', an external file is not managed by the system - there is no capability for managed revision control or any document representation definitions for an external file.

An external file is simply an external reference that may be associated with other product data.

document_file properties may be associated with an external file as with an identified managed document.

In the case where properties differ with different versions, the managed 'Document as Product' approach shall be used.

If a file is under configuration control, it should be represented as a constituent of a document definition view/representation according to 'Document as Product'. In this case, it is actually the managed document that is under direct configuration control; the file is, in this way, indirectly under configuration control. A change to the file results in a change to the managed document (i.e., a new version) - the changed file would be mapped as a constituent of a view/representation definition of the new document version.

A simple external reference alone is not configuration controlled, it is just an external file reference to product data.

While managed revision control representing multiple versions and version history is not available for external files, external files may have an optional version identification providing a string labelling the version of the file.

Identification of an external file is done using the entity document_file. The document_file entity is a defined subtype of the entity document. It is also a subtype of the entity characterized_object, which allows association of properties to the identification of an external file.

A simple one-level type classification can be applied to external files. A document_file provides in its attribute kind a pointer to the entity document_type. document_type.product_data_type can be used for the classification of the type of the document_file. This simple classification shall only be used, if the 'Document as Product' approach is not used.

An External file may represent geometry. In this case it has an external_model related to it representing the coordinate space of the externally defined geometry. This externally defi ned geometry may represent the shape of a product. Such an external shape is related to a product in the same way as described in clause 5.2.1.4.4. To specify that it is an external shape, the value ‘external’ for representation_context.context_type shall be used. For external shapes the subtypes of shape_representation shall not be used. In general, no dedicated geometric elements as items of the shape_representation shall be instantiated. However, certain detailed elements of the shape are required to be able to place and relate the external geometric models together. Therefore, placement information is placed in the set of items of each shape_representation. Placement information is represented by the entity placement, respective one of its subtypes. The external file that contains the detailed geometry is related to the shape_representation representing the external shape using the entities property_definition_representation and property_definition with name 'external definition'.

5.2.1.7.6 Document assignment

Documents shall be assigned to other product data in order to make use of the document information in the context of these product data. In case of a simple External file this is an applied_document_reference assigning the document_file that represents the external file.

In case of a managed document with the 'Document as Product' approach the applied_document_reference assigns a 'dummy' document of with a special document_type. This dummy document is linked to the managed document by the entity document_product_equivalence, a subtype of document_product_association. The related_product is either the product representing the document in the ARM (in this case the 'dummy' document is of kind document_type.product_data_type = 'configuration controlled document') or it is the product_definition_formation representing the document_version in the ARM (in this case the 'dummy' document is of kind document_type.product_data_type = 'configuration controlled document version') or it is the product_definition representing the document_definition in the ARM (in this case the 'dummy' document is of kind document_type.product_data_type = 'configuration controlled document definition').

The entity document_product_equivalence and its supertype document_product_association is used throughout the AP only for this purpose of assigning managed documents to product data.

5.2.1.8 Specification control

This clause describes the AIM entities used by this part of ISO 10303 that provide the capability to describe automotive products with a large number of variants.

EXAMPLE 1 Examples for automotive products are passenger cars, trucks, busses, engines, or components of these products.

Because of the large number of variants there is no explicit representation for each of the variants that could be produced. The main concepts that are used to handle this large number of variants are illustrated in Figure 80.

These main concepts are the following:

A product_class is a product_concept and a characterized_object. The characterized_object may have property_definition entities associated to it through property_definition.definition and the select type characterized_definition.

NOTE 1 The described Mapping is for the case that UoF S7 is used in the considered conformance class. In case only UoF S4, but not UoF S7 is used in the considered conformance class a product_class is a product_concept where no property_definition entities can be associated to. This case is for compatibility with ISO 10303-203.

The same is true for product_identification that is a configuration_item and a characterized_object, where property_definition entities may be associated to, in the case that UoF S7 is used in the considered conformance class. In the ISO 10303-203 compatible case where only UoF S4, but not UoF S7 is used in the considered conformance class a product_identification is a configuration_item where no property_definition entities can be associated to.

The instances of product_class may build a hierarchical tree-like structure through instances of product_concept_relationship that have the attribute name set to 'hierarchy' and that reference with the attribute related_product_concept the product_class that is a subclass of the product_class referenced by the attribute relating_product_concept.

NOTE 2 Since the market context information is not needed from an ARM perspective, the mandatory attribute market_context points to an

as described in Annex C for such cases.

The product_concept_feature is associated to a product_class through a product_concept_feature_association with the attribute name set to 'replaceable standard', 'non replaceable standard', 'availability', 'identification', 'option', 'part usage', or any other non standardized value.

For a definition of the meaning of the standardized values see ARM definition for Class_specification_association in clause 4.2.67.3 for the permissive list definition. A package_product_concept_feature is a subtype of product_concept_feature that is used when the characteristic is in fact a set of other characteristics, e.g., a package of several options for a passenger car. In this case there is an inclusion_product_concept_feature, a subtype of conditional_concept_feature, with the inherited attribute condition referencing a concept_feature_relationship_with_condition with the attribute conditional_operator set to 'implication'. The inherited attribute relating_product_concept_feature of the concept_feature_relationship_with_condition references the package_product_concept_feature, and the inherited attribute related_product_concept_feature references either the one product_concept_feature that belongs to the package or another conditional_concept_feature that references the product_concept_feature instances of the package through an 'and' operation (for an example of package with two product_concept_feature see Figure 81).

A product_concept_feature_category is a group that groups instances of product_concept_feature. Instances of product_concept_feature are assigned to product_concept_feature_category through applied_group_assignment that is a subtype of group_assignment. For this group_assignment the attribute items references, through the select type group_item, instances of product_concept_feature or package_product_concept_feature, the attribute assigned_group references product_concept_feature_category or exclusive_product_concept_feature_category, the attribute role references object_role with the attribute name set to 'specification category member'.

exclusive_product_concept_feature_category is a subtype of product_concept_feature_category that is used when the members of the group are mutually exclusive in their usage within a product, e.g., there is exactly one outside colour that can be choosen for a particular product. product_concept_feature_category is associated to product_class through product_concept_feature_category_usage that is subtype of group_assignment. For this group_assignment the attribute items references, through the select type category_usage_item, an instance of product_class, the attribute assigned_group references product_concept_feature_category or exclusive_product_concept_feature_category, the attribute role references object_role with the attribute name set to 'mandatory category usage' or 'optional category usage'. For a definition of the meaning of the two values see ARM definition for Class_category_association in clause 4.2.64.3.

The conditional_concept_feature is subtype of product_concept_feature.

The conditional_concept_feature is used to build up boolean conditions for instances of product_concept_feature. The conditional_concept_feature references with its attribute condition a concept_feature_relationship_with_condition that represents a binary boolean operation. A concept_feature_relationship_with_condition is subtype of concept_feature_relationship with the attribute conditional_operator pointing to a concept_feature_operator with the attribute name set to 'and', 'or', 'oneof', 'not', or 'implication'. The intended usage of the unary 'not' operation is that the inherited attributes relating_product_concept_feature and related_product_concept_feature reference the same instance of product_concept_feature.

The value 'implication' is only allowed, if a suptype of conditional_concept_feature is used, i.e., inclusion_product_concept_feature. This is ensured by the rule restrict_concept_feature_operator. For a definition of the meaning of the other values see ARM definition for Specification_expression in clause 4.2.470.4.

conditional_concept_feature may be associated to a product_class through product_concept_feature_association with the attribute name set to 'part usage', 'identification', 'validity', 'design case', or any other non standardized value. For a definition of the meaning of the standardized values see ARM definition of Class_condition_association in clause 4.2.65.3. The value 'part usage', which is also applicable for the association of a product_concept_feature to a product_class, see above, indicates that the conditional_concept_feature (or product_concept_feature) controls the usage of a part within a product of the associated product_class.

In this case the product_concept_feature_association is referenced by a configured_effectivity_context_assignment that is a subtype of effectivity_context_assignment through the select type configured_effectivity_context_item.

Such instances of product_definition for functional requirements may be related to instances of product_class through an instance of configuration_design and configuration_item. In this case the attribute name of configuration_design is set to 'functionality'. For a definition of the meaning of the standardized value see ARM definition of Class_structure_relationship in clause 4.2.68.4.

Such instances of product_definition for a common decomposition structure may be related to instances of product_class through an instance of configuration_design and configuration_item. In this case the attribute name of configuration_design is set to 'realization'.

For a definition of the meaning of the standardized value see ARM definition of Class_structure_relationship in clause 4.2.68.4.

An instance of product_definition with context 'alternative definition' shall be associated to another product definition where it is a variant of through an instance of product_definition_relationship with the attribute name set to 'solution alternative definition'. The related_product_definition points to the variant (with context 'alternative definition') and the relating_product_definition references a product_definition with context 'functional definition', 'conceptual definition', or 'alternative definition'. In the latter case the product_definition instance with context 'alternative solution' defines a variant of another instance of product_definition with context 'alternative solution', e.g., where the first level defines technically different solutions and the second level defines different suppliers for the same technical solution.

All instances of product_definition with context 'alternative definition' that are defined through this path as variant of the same instance of product_definition are the mutually exclusive alternate solutions, i.e., variants.

A product_definition with context 'part occurrence' defines exactly one occurrence of a part within a given assembly structure. An instance of product_definition with context 'part occurrence' may be defined as an element, i.e., as related_product_definition, of a product_definition instance with context 'alternative solution', i.e., as relating_product_definition, through a product_definition_relationship with the attribute name set to 'realization'.

A product_definition with context 'part occurrence' may also represent a component occurrence in an explicit product structure defined by assembly_component_usage.

In this case it is linked to the assembly_component_usage by a product_definition_occurrence_relationship, see clause 5.2.1.5.

The related_product_definition is an instance of product_definition with context 'functional definition', 'conceptual definition', or 'part occurrence'. With this tree-like decomposition structures for product_definition instances with the same context, attribute name set to 'decomposition', 'specialization', or 'occurrence' as well as relationships between product_definition_instances with different context, attribute name set to 'realization' or 'functionality', can be defined. For a detailed definition of the meaning of the standardized values for the attribute name of product_definition_relationship see ARM definition of Product_structure_relationship in clause 4.2.400.4.

The configured_effectivity_context_assignment is a subtype of effectivity_context_assignment that references with its attribute items, through the select type configured_effectivity_context_item, the product_concept_feature_association that defines the usage case or condition. The inherited attribute assigned_effectivity_assignment references the configured_effectivity_assignment instance.

configured_effectivity_assignment is a subtype of effectivity_assignment that references with its attribute items, through the select type configured_effectivity_item, the product_definition with context 'part occurrence', 'alternative definition', 'conceptual definition', or 'functional definition' to which the usage case or condition applies, e.g., the variant to be controlled. The attribute role references an object_role instance with the attribute name set to 'design' or 'usage' and with the attribute description set to 'inherited', 'local', or 'exception'. For a definition of the meaning of the standardized values for the name attribute and for the description attribute see ARM definition of Configuration in class 4.2.94.1 and clause 4.2.94.3 respectively.

configured_effectivity_assignment references with its inherited attribute assigned_effectivity an instance of effectivity that is instantiated solely as the supertype effectivity (i.e. not as one of the effectivity subtypes) with an id of 'configuration validity' to indicate the valid use of the item contained in the items attribute. dated_effectivity or time_interval_based_effectivity instances may additionally be assigned to a configured_effectivity_assignment through applied_effectivity_assignment instances to indicate the time range for which the configuration is valid.

configurable_item is a subtype of configuration_item that references with its inherited attribute item_concept the product_class of the manufacturable product. The attribute item_concept_feature points to a set of product_concept_feature_association instances that define the specified characteristics of the manufacturable product.

The attribute id of the product instance represents the serial number, the lot id and/or inventory number may be associated to this instance additionally through applied_identification_assignment with the attribute role referencing an instance of identification_role with the attribute name set to 'lot context' and/or 'inventory number', respectively. If none of these ids are defined, then product_definition with context 'physical occurrence' shall be linked to a product_definition with context 'part definition' through a product_definition_relationship with name 'physical realization'.

5.2.1.9 Form Features

This clause describes the concept concerning the definition and application of form features in this part of ISO 10303. This standard includes the definition of various form features for the application in panel like parts, i.e., with negligible thickness, and for the application in solid volume parts.

Also included is a concept for so-called general features whose semantics and parameters are not predefined as well as for transition features and for threads. This standard distinguishes between the definition of the features that is realized by the entity feature_definition which is a subtype of characterized_object and their occurrence on a part. Predefined form features specified for an application in panels are bead, joggle, hole_in_panel, barring_hole, locator, and feature_in_panel that has either the shape of a boss, a pocket, or a stairstep. These features are provided with a set of parameters, profiles, or paths that are sufficient to determine the shape of a part after the feature is applied. Predefined form features specified for an application in solid parts are boss, pocket, rib, round_hole, and slot. These features are specified by a volume that is defined by a set of parameters, a profile, and by a path along which the profile is swept.

The feature itself is created by adding or subtracting this volume from the shape of the part. All additional parameters are provided in an implicit representation that is of type shape_representation_with_parameters. For the definition of predefined features a set of predefined profiles, i.e. circular_closed_profile, ngon_closed_profile, rectangular_closed_profile, partial_circular_profile, rounded_u_profile, square_u_profile, tee_profile, and vee_profile, as well as two general profiles, closed_path_profile and open_path_profile, are included. The paths that may be used to define form features are represented by the entity path_feature_component. This is either a predefined type of path, if path_feature_component.name is set to 'linear', 'partial circular', or 'complete circular', that is specified by a set of parameters or a general type of path, if the path_feature_component.name is set to 'complex'. In the latter case the path is specified by a curve. Paths and profiles are specified as instances of shape_aspect. Here, a distinction is made between the definition of such feature components and their occurrence. The definitions of paths and profiles are subtypes of shape_aspect that reference a feature_component_definition which is a subtype of characterized_object as of_shape. This definition of a feature component is associated with its occurrence which is a shape_aspect of a feature_definition through a subtype of shape_aspect_relationship named shape_defining_relationship. For the application of form feature definitions this standard supports two approaches:

The approach using instanced_feature supports the identification of 'areas of interest' on an already designed shape that are of a certain meaning to the user, e.g., that correspond to a process operation. The identification of parameters on these features does not mean that a variation of the parameter values results in an automatic update of the shape but is only meant to support the specification of these areas in a more appropriate way, e.g., to support process planning. In the case of the application of a feature as an instanced_feature the feature itself as well as all of its components, paths or profiles, are defined in the part coordinate system. The approach using placed_feature supports the definition of the feature independent of its application in its own coordinate system and a placement of the representation of the feature_definition into the representation of the placed_feature using a mapped_item and a representation_map. The shape of the feature need not be represented since a receiving system is supposed to be able to create the shape that results from the application of the feature_definition on a base shape interpreting the values of the feature parameters and the semantics included in the type of feature. In the case of the application of a feature as a placed_feature the feature itself and possibly a path used for the feature definition are defined in one coordinate system, a profile that is used is defined in its own coordinate system. Profiles are placed in the feature coordinate system using a mapped_item and a representation_map.

This standard supports the application of surface conditions and tolerances to form features only implicitly by applying surface conditions and tolerances to elements of the shape representation of the form feature. An exception are tolerances applied to the location and orientation of the features that may be realized by using axis2_placement entities representing the feature coordinate system. Thread features are available as instanced_features only. The identification of a thread is splitted in two parts. First, a type of thread is specified. This specification may represent all necessary parameters either explicitly, if a thread is used, or by an externally_defined_feature_definition that refers to an external specification. The type of thread is applied to the shape of a part by an applied_area that identifies the effective length ant the placement of the thread onto the part. Two mechanisms of creating complex features using the flat feature_definitions as base features are supported, the compound_feature and the replicate_feature. The compound_feature allows to create hierarchies of either solid features or panel features.

EXAMPLE 1 In order to create a fixture point on a solid piece part, a compound_feature is created that consists of a boss and a thread_feature.

A special case of a compound_feature is the composite_hole, which is the definition of two commonly used types of compound_features, the countersunk and the counterbore hole. The other mechanism is the replicate_feature that supports the repeated use of a base feature in order to create patterns on the surface of a piece part. Three types of patterns are supported. The circular_pattern and the rectangular_pattern define the layout of the resulting pattern by parameters. The resulting pattern lies in a plane. The ommission and offsetting of elements of the pattern are supported by the use of pattern_omit_membership and pattern_offset_membership, which identify shape_aspects of feature_component_definitions that represent the omitted or offsetted elements of a pattern. The layout resulting from such an operation is identified as a modified_pattern.

The feature_pattern is the third mechanism for creating patterns. It supports the definition of an arbitrary layout that is not restricted to lying in a plane. Such a pattern is defined by a set of axis2_placements that participate in the implicit representation of the feature_pattern.

Compound features and patterns of features may be nested within each other and are applicable for both the instanced_feature and the placed_feature approach.

EXAMPLE 2 A flange is created by means of a compound_feature that consists of a round_hole and a thread applied to it, and a circular_pattern that distributes the compound along the flange.

5.2.1.10 Process planning

This clause describes the concept concerning the definition and application of process plans and the included process operations in this part of ISO10303. This standard includes the definition of reusable process operations and occurrences of process operations in specific process plans. This standard defines the relation from a process operation to the concerned product description as input or output to that process operation. This standard also defines the relation from a process operation to the concerned tool or manufacturing resource as the resource used to perform the process operation. The manufacturing planning information is defined by a process_plan, which is a subtype of action. If the manufacturing planning information is directly concerned with a specific product version, product_definition_formation, as output from the process plan definition the manufacturing planning information is defined by product_process_plan which is subtype of product_definition_process.

A version of the process_plan is defined by associating the supertype action with identification_item, identification_assignmentand identification_role with the name value 'version'. Multiple process_plan objects can be related to each other using action_relationship.

This relation is used to handle multiple versions of the same process_plan concerning the same product. The definition of a process step within a process_plan is described by process_operation which is a subtype of action_method.

The process_operation defines a general process step and can be associated to multiple and different process plans, in this way reuse of generically defined process steps is allowed. When a process step is used in a process plan, the association is considered to define an occurrence of the process_operation in the process_plan. This association, occurrence, is defined by action and action_relationship linking the two by action_relationship.related_action.

The relation to the concerned process step description is action.choosen_method which relates to the process_operation via its supertype action_method. The relation to the concerned process plan is action_relationship.relating_action which relates to the process_plan, or the product_process_plan and product_definition_process if a product_definition_formation is defined as output, via its supertype action.

Two occurrences of a process step can be related to each other with action_relationship. The general use of this relationship is to build structures of occurrences, e.g. process operation lists. This relationship can express different semantics depending on the value assigned in action_relationship.name:

The 'decomposition' and 'alternative' values give a structural meaning to the relationship whereas the 'sequence', 'exclusiveness' and 'simultaneity' values add the meaning on the time of execution to the relationship.

In order to express the refinement of parts or material into products by the process plan, relevant parts of the product structure or descriptions can be associated to a particular occurrence of a process step in the process plan. Association of the relevant product description is made by product_process_association where the value of product_process_association.name defines whether the associated product description appears as an input or an output to the occurrence of the process step. Values used are 'input' or 'output'. This assures that the input and output is relevant only for the occurrence of a particular process step within a particular process plan enabling the reuse of generically defined process steps.

To each occurrence of a process step the manufacturing resource(s) used to perform the operation can be associated using requirement_for_action_resource which is subtype from action_resource_requirement.

The concerned occurrence of a process step is defined by action_resource_requirement.operations and the performing resource by action_resource_requirement.resources.

The performing manufacturing resource is defined by product_definition_resource which is subtype of action_resource and product_definition where the value of the associated application_context_element.name gives semantically different meaning to the use of the resource:

product_definition with application_context_element.name 'physical occurrence': This represents a physical manufacturing resource in an existing manufacturing system.

In the general case a textual description can be used to define a manufacturing resource. This definition is given in the resource_requirement_type by the action_resource_requirement.kind.

5.2.1.11 Dimensioning and Tolerances

This standard supports dimensioning with respect to size and location. The dimensions may be tolerated by individual tolerances or by provision of general tolerances. Default values may be assigned for thickness and dimensions through a representation that has a representation_context with a context_type of 'default setting' and a name of 'default thickness' for characterization of piece parts with an evenly shaped cross section or for sheet metal, and a name of 'default setting' for general tolerances that apply to all dimensions of a work piece. The concept of limits_and_fits and plus minus bounds by specification of a tolerance_value with upper_bound and lower_bound are supported. A tolerance table may be provided using a default_tolerance_table that consists of a set of default_tolerance_table_cells which provide a relationship between ranges of dimensions and the applicable tolerance values. Geometric tolerances are supported as defined in ISO~10303-519 and are in accordance with ISO~1101. Location of parts in in datum reference frame is accomplished by use of datum_targets. These may be defined either explicitly by identification of a shape_aspect that refers to an area with a closed boundary, or implicitly using placed_datum_target_feature, by which points, lines, circles, and rectangles may be defined by specification of an axis2_placement and the necessary parameters. Common datums that consist of two datum objects may be created using the common_datum.

The usage of common_datum is shown in Figure 82.

The geometric tolerances support the concept of viewing planes, i.e., if a viewing plane is specified, the geometric tolerance applies in a tolerance zone that is bounded by two planes a distance apart as specified by the tolerance value, and with infinite extent normal to the viewing plane. This capability is provided for line_profile_tolerance, parallelism_tolerance, perpendicularity_tolerance, position_tolerance, straightness_tolerance, and symmetry_tolerance.

A viewing plane is specified by a shape_aspect_relationship with a name of 'affected plane association' that associates the toleranced shape_aspect and another shape_aspect that identifies a plane, see Figure 83. In the case of using viewing planes, the tolerance_zone is made up by the superposition of all boundaries defined by the viewing planes. The necessity to associate viewing planes and the tolerance objects they apply to requires the instantiation of a shape_aspect of the tolerated item for each use case.

5.2.1.12 Multi-language support

This clause describes the concept concerning the definition and application of languages used for multilingual support of string valued attributes in this part of ISO 10303. This standard includes the definition of a language, the association of the primary language to a string valued attribute and the association of additional values in different languages.

The definition of the language in which an information is given is done using the entity language. The language entity is a subtype of the entity group. The inherited attribute name specifies a language code according to ISO 639-2, and, if present, the inherited attribute description specifies a country code according to ISO 3166-1.

The specification of the primary language for a string valued attribute of an entity is done by an attribute_language_assignment to this entity with an attribute_name of the concerned string valued attribute. Attribute_language_assignment is a subtype of attribute_classification_assignment. To indicate that the primary language is meant, the attribute_classification_assignment has an associated classification_role with the name attribute set to 'primary'. The assigned_class attribute refers to the language entity.

EXAMPLE 1 The primary language for the name attribute of a product would be represented by an attribute_language_assignment with attribute_name set to 'name'.

Multi_language_attribute_assignment, a subtype of attribute_value_assignment, is used to specify additional language dependent strings for a string valued attribute. The inherited attribute attribute_name is set to the name of the attribute for which an additional value is defined. The additional string value is represented by the attribute_value. To indicate that the assignment specifies a value in an alternate language, the attribute_value_assignment has an associated attribute_value_role with the name attribute set to 'alternate language'. The language for the alternate string value is specified in the same way as for the primary language. However, the name attribute of the classification_role associated with the attribute_language_assignment is set to 'translated'.

EXAMPLE 2 Figure 84 illustrates the instantiation of a product with name 'oil pan upper part'. The primary language for this name is English with country code United Kingdom. There is an alternate language string defined with value 'Oelwannenoberteil'. This string is given in German with country code Germany.



© ISO 2010 — All rights reserved