Generic Product Semantics

From WikiSTEP

Contents 1 People and Organizations 1.1 People 1.2 Organizations 1.3 Roles of People and Organizations 2 Dates and Times 2.1 Dates 2.2 Time 2.3 Roles of Dates and Times 3 Approvals 3.1 Approval 3.2 Approval_status 3.3 Approval_date_time 4 Security 5 Units of Measure 6 Shape Representation 6.1 Units for Shape Representation 6.2 Boundary Representation Models

People and Organizations

AP 210 represents people and organizations as they perform functions related to other data and data relationships. A person or a person in an organization is associated to some data or data relationship in some role indicating the function being performed.

Both people and organizations may have addresses associated with them. This is entirely optional in AP 210 and is done through the address entity being related to the person (through personal_address) or organization (through organizational_address).

People

AP 210 specifies information about people through the person entity. A person is identified by an id with other data representing their name and optionally titles which may apply to them. In populating the data, the id must be unique if the person is associated with an organization through the person_and_organization entity.

Pre-processor Recommendations: All pre-processors should provide values for at least the last_name and first_name attributes for the person entity.

Organizations

AP 210 represents groups of people (e.g. design departments, industrial engineering departments, reliability engineering departments, companies, countries, etc.) through the organization entity. The identification or id data is optional. This information can be highly important in providing unique identification to the organization or company. It is recommended that this field always be populated with unique data. The name attribute must contain a short identifier or acronym for the organization. The description attribute may contain the full name of the organization or a textual explanation its reason for existence.

Pre-processor Recommendations: All pre-processors should provide a unique organization id to eliminate ambiguities where organizations may have the same names. If the intended domain for the data is large, the reader is referred to ISO/IEC 8824-1 which can provide some guidance on creating unique identifiers. For example, if the organization typically used a CAGE identifier of "93699" and the identifiers associated with CAGE were registered by the US government (i.e., "CAGE" is defined in the US "federal stock number system"), the actual value of the organization id would be "COUNTRY,USA,CAGE,93699". Since the CAGE code is widely used, including traceability of "CAGE" to "federal stock number system" and thence to USA is not recommended.

Post-processor Recommendations: All post-processors should make use of any provided information in the id attribute to eliminate ambiguities where organizations may have the same name.

Roles of People and Organizations

The connection of people to organizations is accomplished through the person_and_organization entity. It is used to identify approvers for different aspects of the product data. It is also related to certain constructs to identify the people and organizations responsible for them and how they are responsible. This is done through the applied_person_and_organization_assignment entity which relates a person_and_organization or organization in some role to an entity. The role is established in the person_and_organization_role entity name attribute. Standard character strings are established for this attribute in AP 210 mapping tables and are used in the rules in clause 5 in AP 210.

Pre-processor Recommendations: Standard character strings shall be used if provided.

Post-processor Recommendations: All post-processors should make use of any provided information in the person_and_organization_role entity name attribute, when the data in the mapping table does not apply.

Dates and Times

AP 210 represents dates and times to record when something occurred. AP 210 requires both a date and a time for all events.

Dates

AP 210 provides one way to represent a date, calendar_date.

Time

AP 210 represents time through the entity local_time. As mentioned earlier, the requirement that time be provided for every date may involve the invention or defaulting of data.

The local_time entity references a time zone identification through the zone attribute. The referred to coordinated_universal_time_offset entity identifies the delta from the current time zone to coordinated universal time.

For AP 210's application domain, this should be considered the delta in hours and minutes between Greenwich Mean Time (GMT) and the local time zone.

Note: Coordinated Universal Time is NOT exactly Greenwich Mean Time (GMT). The hour and minute offset is the same, but the second offset varies due to seasonal variations in the earth's axis orientation. The difference between GMT and coordinated universal time is on the order of .05 seconds which has essentially no effect in a configuration management (AP 210) application.

Pre-processor Recommendations: All pre-processors should use noon in the originating time zone as a default for local_time when this data is unavailable. All pre-processors should view Greenwich Mean Time and coordinated universal time as equal.

Roles of Dates and Times

The connection of dates to times is accomplished through the date_and_time entity. It is used to identify when an approval occurred for different aspects of the product data. It is also related to certain constructs to identify the date and time something started, stopped or occurred and what started, stopped or occurred. This is done through the applied_date_and_time_assignment entity which relates a date and time in some role to some construct. The role is established in the date_time_role entity name attribute. The data allowed in this attribute is constrained by the applied_date_and_time_assignment entity or by the applied_date_assignment entity in the data model.

Pre-processor Recommendations: See above.

Post-processor Recommendations: Post-processors shall interpret string values in accordance with the AP 210 mapping table.

Approvals

Approval

There are many constructs in AP 210 which require approvals. Approving in AP 210 is accomplished by establishing an approval entity and relating it to some construct through a applied_approval_assignment entity. There are rules related to the use of the approval entity which require it to have an associated approval_person_organization and approval_date_time.

Every construct which requires an approval is allowed only one approval. This might lead to the misconception that only one person on one date/ time can approve something. This is not the case. The approval constructs in AP 210 actually designate that an approval cycle is required. This cycle may only need one signature.

The approval level attribute in AP 210 is mapped to the domain requirement for identification of activities within a broader life cycle stage through the AP 210 application object Ee_product_version and associated attribute life_cycle_status. The standard string values are:

• "conceptual design",
• "preliminary design",
• "detailed design",
• "final design".

"final design" is intended to allow interoperability with APs that are focused at the broad life cycle stages as it is typically assigned at design release. There are no rules in AP 210 to require these values. Exchange agreements will need to enforce these strings.

Pre-processor Recommendations: It is recommended that this attribute contain one of the strings identified above as minimal content. If no appropriate data for the approval_role attribute (why this person_and_organization or organization is approving) is available it is recommended that this attribute contain the value "approver". It is recommended that all approval_person_organization instances have associated applied_date_and_time_assignment entities to provide complete clarity.

Post-processor Recommendations: Industry domain agreements should enforce the allowed values for approval level attribute value.

Approval_status

The approval_status name attribute in AP 210 has a restriction on its possible values. The values shall only be "approved", "not_yet_approved", "disapproved" or "withdrawn". This restriction is enforced by the restrict_approval_status rule.

Approval_date_time

The approval_date_time records the date/ time the status was changed. It does not record (necessarily) when the approval was given by the approval_person_organization as there can be multiple approval_person_organizations related to an approval entity. If there is only one approval_person_organization and the approval_status is "approved", the approval_date_time indicates that this person/organization approved it on this date/time. When an approval event is a cycle which requires multiple people to concur on possibly differing dates/times, the dates/times are recorded through the relation of a applied_date_and_time_assignment entity with the date_time_role being "sign off date". This relation is not required in the AP. In the cycle case, the approval_date_time only indicates when the status of the approval was last changed.

Security

AP 210 requires that certain constructs indicate their sensitivity to the owning organization. This is accomplished by establishing the security_classification entity and relating it to the construct via the applied_security_classification entity. The classification is given in security_classification_level name attribute. Suggested values of this attribute are: "unclassified", "classified", "proprietary", "confidential", "secret", and "top_secret". It should be noted that the value of "classified" only indicates that the data is not unclassified. This value is used when an organization has a security classification which does not exactly match any of the other values.

A security_classification in AP 210 requires an approval, a person_and_organization or organization in the role of classification_officer and a date and time in the role of classification_date. It should be noted that the AP provides for indication of an expiration date for the classification by relating a date/ time in the role of declassification_date, but this is not required.

Pre-processor Recommendations: There is no standard mapping for the security_classification purpose attribute. 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. There is no standard mapping for the security_classification name attribute. 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 security_classification_level name attribute is the value "classified", it is recommended that the organization's classification designation be placed in the security_classification name attribute. For example, if an organization had a security classification of "secret restricted", the security_classification_level name attribute value would have the value "classified", and the security_classification name attribute would have the value "secret restricted".

Post-processor Recommendations: There is no standard mapping for the security_classification purpose attribute. 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 security_classification_level name attribute is the value "classified", it is recommended that post-processors regard the security_classification name data as the identification of a special or non-standard classification. If the security_classification_level name attribute has a value of other than "classified", it is recommended that post-processors not assign any processing significance to the name attribute value.

Units of Measure

AP 210 provides for a number of units of measure which can be used for quantities or determining the dimensionality of a set of information. All units of measure information supported in ISO 10303-41 are supported in AP 210.

Shape Representation

AP 210 provides multiple types of shape_representation which are grouped into conformance classes as shown in clause 6 of the AP. These classes are:

• geometrically bounded shape models:
  • geometrically bounded surface model
  • geometrically bounded 2d wireframe model
  • Curve 2d
  • Basic curve 2d
• wireframe with topology shape models which are represented by
  • edge_based_wireframe_shape_representation
  • shell_based_wireframe_shape_representation,
  • edge_based_2d_wireframe_shape_representation,
  • shell_based_2d_wireframe_shape_representation,
• open shell model which is represented by manifold_surface_shape_representation (with additional constraints),
• constructive solid geometric model which is represented by csg_shape_representation
• and boundary representation model which is represented by advanced_brep_shape_representation.

This document will not go into detail on shape_representation. It will only present clarifications and practices for the different types of shape as appropriate. There are a number of potential implementor agreements in regard to shape.

Units for Shape Representation

Units are defined for a type of shape_representation through the use of a complex instance of global_unit_assigned_context and geometric_representation_context. When global units are used, units must be defined for length_unit, plane_angle_unit, and solid_angle_unit. The base units for STEP are Standard International (SI) units which are represented through the named_unit sub-type si_unit. All other units (such as English units) are represented as conversion_based_unit entities which reference si_units. Physical file examples for SI and English units can be found in appendix D on page 68. (See G.1.9 on page 83 for an implementors agreement that affects units).

======reference needs updating

In addition to the global measurement units described in the prior paragraph, AP 210 provides for the definition of a global gap tolerance for a shape model through the addition of global_uncertainty_assigned_context to the complex representation_context instance. This entity defines a set of uncertainty_measure_with_unit entities to represent various gap type measurements. Physical file examples for SI and English units of uncertainty can be found in appendix D on page 68.

======reference needs updating

As a clarification to 10303-42, units on parametric representations are taken from the global_unit_assigned_context entity. They are not always degrees as might be extrapolated from reading the text of 10303-42. This is a consideration on choosing the global units for plane angles as radian units are irrational and potentially unstable.

Pre-processor Recommendations: If a pre-processor uses global_uncertainty_assigned_context, it should point to one uncertainty_measure_with_unit which should identify a length_measure. The value of the name attribute shall be "closure". The length_measure shall contain the value of the largest gap anticipated between elements that should be deemed coincident.

Pre-processors should use degree as the unit for plane_angle_unit as it is more stable than using a radian unit.

Post-processor Recommendations: Post-processors shall use the uncertainty_measure_with_unit value for error checking of the file where an error is a gap in the shape which is larger than the length_measure value.

Boundary Representation Models

This sub-section will not provide detailed information on boundary representation models. It should be noted that most AP 210 conformance class 17 implementations are providing surface, seam and intersection curves in the data. This has been noted and is being considered for future editions. This practice may also be formalized through an implementors agreement in the interim. Organizations implementing AP 210 should provide provisions for this data in their post-processors even though AP 210 has a rule which precludes it.

Pre-processor Recommendations: Pre-processors should not use face_outer_bound designations on closed periodic surfaces (cylinder, sphere, torus) as this designation is ambiguous.

Post-processor Recommendations: Post-processors should ignore the face_outer_bound designations on closed periodic surfaces (cylinder, sphere, torus) as this designation is ambiguous.