Guidelines_for_application_interpreted_model_development.pdf

ISO TC 184/SC4 N532

1997-02-19

ISO TC 184/SC4 STANDING DOCUMENT

Technical Committee 184 for Industrial Automation Systems and Integration Subcommittee 4 for Industrial Data

SC4 Secretariat

National Institute of Standards and Technology Building 220/Room A127

Gaithersburg, Maryland 20899

USA

Guidelines for application interpreted model development

ISO/TC 184/SC4 N532:1997(E)

ii

Contents Page

1 Scope

2 Normative references

3 Definitions and abbreviations

3.1 Terms defined in ISO 10303-1

3.1.1 application

3.1.2 application activity model

3.1.3 application context

3.1.4 application interpreted model

3.1.5 application object

3.1.6 application protocol

3.1.7 application reference model

3.1.8 conformance class

3.1.9 data

3.1.10 implementation method

3.1.11 interpretation

3.1.12 product data

3.1.13 resource construct

3.1.14 unit of functionality

3.2 Terms defined in ISO 10303-202

3.2.1 application interpreted construct

3.3 Abbreviations

4 Interpretation process in STEP

4.1 Preparation phase

4.1.1 Analyze ARM requirements

4.1.2 Assess integrated resource constructs

4.1.3 Identify potential usage of AICs

4.1.4 Plan for interpretation phase

4.2 Interpretation phase

4.2.1 Select resource constructs

4.2.2 Capture interpretation in mapping table

4.2.3 Develop AIM EXPRESS short listing

4.2.3.1 Establish a formal interface to the resources

4.2.3.2 Develop unique AIM constructs

4.3 Documentation phase

4.3.1 Perform consistency checks

4.3.2 Define new and modified AIM constructs

4.3.3 Produce AIM EXPRESS expanded listing

4.3.4 Produce AIM EXPRESS-G diagrams

4.3.5 Produce short names table

iii

5 EXPRESS usage guidelines for interpretation

5.1 Schema interface

5.1.1 Visibility

5.1.2 Content of AIM expanded listing

5.1.3 Independence

5.2 Entity type specialization

5.2.1 Localization of constraints

5.2.2 Specialization of attribute definitions

5.2.3 Concept completion and assignment

5.3 Use of global rules

5.3.1 Supertype constraint

5.3.2 Cardinality constraint

5.3.3 Referential integrity constraint

5.3.4 Attribute domain constraint

5.4 Use of functions

Annexes

A AIM core entities

B Constraint templates

B.1 Dependent instantiation B.2 Mandatory subtype B.3 Cardinality B.4 Value restriction

C Steps for writing AIM short form EXPRESS

D Standardized string values for resource attributes

E Bibliography iv

Figures

Figure 1 - a_geometry_schema EXPRESS-G diagram

Tables

Table 1 - String values standardized in ISO 10303-202 Table 2 - String values standardized in ISO 10303-203 v

Foreword

The International Organization for Standardization (ISO) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. Each member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

This standing document was prepared by Technical Committee ISO/TC 184, Industrial automation systems and integration, Subcommittee SC4, Industrial data.

ISO/TC 184/SC4 standards are prepared according to guidelines put forth in the following standing documents:

— Guidelines for application interpreted construct development;

— Guidelines for application interpreted model development;

— Guidelines for the development and approval of STEP application protocols;

— Guidelines for the development of abstract test suites;

— Guidelines for the development of mapping tables;

— ISO/TC 184/SC4 organization handbook;

— Supplementary directives for the drafting and presentation of ISO 10303.

vi

Introduction

ISO 10303 is an International Standard for the computer-interpretable representation and exchange of product data. The objective is to provide a neutral mechanism capable of describing product data throughout the life cycle of a product independent from any particular system. The nature of this description makes it suitable not only for neutral file exchange, but also as a basis for implementing and sharing product databases and archiving.

This International Standard is organized as a series of parts, each published separately. The parts of ISO 10303 fall into one of the following series: description methods, integrated resources, application interpreted constructs, application protocols, abstract test suites, implementation methods, and conformance testing. The series are described in ISO 10303-1.

The purpose of this document is to provide methods and procedures for the development of application interpreted models for STEP application protocols. The expected audience for this document includes developers of STEP application protocols and users of STEP application protocols who are interested in a more in-depth understanding of the origins of the structure of application protocols. This is one of several documents intended to be of use to this audience. Others include Guidelines for the development and approval of STEP application protocols, Guidelines for the development of mapping tables, and Guidelines for application interpreted construct development.

A principle feature of the STEP architecture is that it has two distinct data specifications: integrated resources and application protocols. Three classes of information models are specified within these two types of specifications. The first class of information model is a collection of standardized EXPRESS schemas that is contained in the integrated resources. Each integrated resource schema is a representation of a specific subject area within the domain of product data. The integrated resources are abstract conceptual structures of information that are generic with respect to various types of products and different stages of the product life cycle.

The second and third classes of information models are contained in application protocols (APs): the application reference model (ARM) and the application interpreted model (AIM). An ARM captures the information requirements for an application context which has a scope bounded by a specific set of product types and product life cycle stages. ARMs are presented informatively in one of three graphical modeling languages (IDEF1X, NIAM or EXPRESS-G) as well as normatively in text. An AIM is an EXPRESS schema that selects the applicable constructs from the integrated resources as baseline conceptual elements. An AIM may augment the baseline constructs with additional constraints and relationships, which are specified by entities that may contain local rules, refined data types, global rules, and specialized textual definitions. An AIM is documented in three forms within an AP: an EXPRESS short listing containing inter-schema references and constructs unique to the specific subject area, a completely independent EXPRESS expanded listing where all references are resolved, and a set of EXPRESS-G diagrams that correspond to the expanded listing. The process of identification of the baseline constructs and specification of the additional constraints and relationships necessary to satisfy the information requirements defined in the ARM is called interpretation.

vii

Interpretation is the process by which meaning is assigned to an abstract representation of an event, object, or concept. Within an AIM, the abstract representation is specified by an EXPRESS construct.

The interpretation of a construct defined in an integrated resource results in the creation of a new construct in the AIM that may restrict, narrow, or constrain the semantic scope of the integrated resource construct, thereby specializing the construct.

Interpretation is ultimately grounded in human understanding. Interpretation draws not only on the meaning of the constructs themselves, but the context within which the constructs are generated, used, or received. The context specified in the ARM is defined by such things as the life cycle stage and the application domain that bounds the scope of the AP. The scope of STEP is the representation of product data. The integrated resources were developed within the framework of that context; the context of the integrated resources is not limited to a specific life cycle stage or to a type of product. Because the integrated resources and the ARMs are developed as representations of information in different (though established and related) contexts, they are subjected to the influence of different contextual factors. In order to account for contextual factors, interpretation of integrated resources in STEP (particularly the selection of integrated resource constructs) relies on human comprehension of the requirements represented in the ARM and the in-depth knowledge of the semantics and contextual factors under which the STEP resources are developed.

A key part of the interpretation process is to ensure the consistent interpretation of the same requirements found in different APs. Data sharing and communication among implementations of various APs cannot be accomplished without consistent interpretation of the resource constructs. Consistency is achieved when the same integrated resource constructs, specializations, and constraints are specified for the same requirements in different APs. In addition to the integrated resources, the STEP architecture provides a tool that may be used to ensure this consistency, the application interpreted construct (AIC). An AIC is an EXPRESS schema that is an interpretation of the STEP integrated resources and that satisfies a specific set of application requirements. This document regards AICs as resources to be drawn upon when developing AIMs, much like the integrated resources. Guidelines for application interpreted construct development describes the characteristics of AICs and the procedures and methods for developing AICs. This consistency may be achieved through the use of AICs.

The interpretation process is presented in the fourth clause of this document through a description of the objectives and deliverables of each phase of the process. Documentation of the interpretation using the EXPRESS language is described in detail in the fifth clause of this document. The fifth clause includes guidance on developing the short and expanded EXPRESS listings, as well as the specific application of EXPRESS semantics.

STANDING DOCUMENT ISO/TC 184/SC4 N532:1997(E)

Guidelines for application interpreted model development

1 Scope

This SC4 standing document specifies procedures and practices for the development and documentation of application interpreted models within ISO 10303 application protocols.

The following are within scope of this standing document:

— description of the interpretation process for ISO 10303 application protocols;

— description of how the interpretation results are captured in mapping tables;

— decomposition of the process of developing an application interpreted model short form EXPRESS schema;

— decomposition of the process of documenting the interpretation, including a list of consistency checks that verify the quality of the interpretation;

— guidelines for the use of the EXPRESS language for writing an application interpreted model for an ISO 10303 application protocol;

— a listing of entities from the ISO 10303 integrated resources that are common to all ISO 10303 application protocols;

— EXPRESS templates for commonly used global rules;

— a list of steps for writing application interpreted model short form EXPRESS;

— tables listing string values for integrated resource entity attributes that have been standardized within ISO 10303 application protocols.

The following are outside the scope of this standing document:

— specification of presentation information for the documentation of any portion of an ISO 103030 application protocol;

NOTE 1 - This information is found in Supplementary directives for the drafting and presentation of ISO 10303.

— detailed guidance on how to select constructs of the ISO 10303 integrated resources that map to the information requirements of an ISO 10303 application protocol;

NOTE 2 - This information is planned to be covered in greater detail in a forthcoming document entitled Guidelines for application interpretation.

— guidelines for the use of EXPRESS in information models other than ISO 10303 application interpreted models.

NOTE 3 - The EXPRESS language is described in ISO 10303-11. This document provides EXPRESS usage guidance only in the context of application interpreted model development.

2 Normative references

The following standing documents and standards contain provisions which, through reference in this text, constitute provisions of this standing document. At the time of publication, the editions indicated were valid. All standing documents and standards are subject to revision, and parties to agreements based on this standing document are encouraged to investigate the possibility of applying the most recent editions of the standing documents and standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standards.

ISO/TC 184/SC4 N534:1997, Guidelines for application interpreted construct development.

ISO/TC 184/SC4 N535:1997, Guidelines for the development and approval of STEP application protocols.

ISO/TC 184/SC4 N533:1997, Guidelines for the development of mapping tables.

ISO/TC 184/SC4 N537:1997, Supplementary directives for the drafting and presentation of ISO 10303.

ISO 10303-11:1994, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: Language reference manual.

3 Definitions and abbreviations

3.1 Terms defined in ISO 10303-1

This SC4 standing document makes use of the following terms defined in ISO 10303-1.

3.1.1 application: a group of one or more processes creating or using product data.

3.1.2 application activity model (AAM): a model that describes an application in terms of its processes and information flows.

3.1.3 application context: the environment in which the integrated resources are interpreted to support the use of product data in a specific application.

3.1.4 application interpreted model (AIM): an information model that uses the integrated resources necessary to satisfy the information requirements and constraints of an application reference model, within an application protocol.

3.1.5 application object: an atomic element of an application reference model that defines a unique concept of the application and contains attributes specifying the data elements of the object.

3.1.6 application protocol (AP): a part of this International Standard that specifies an application interpreted model satisfying the scope and information requirements for a specific application.

NOTE: This definition differs from the definition used in open system interconnection (OSI) standards.

However, since this International Standard is not intended to be used directly with OSI communications, no confusion should arise.

3.1.7 application reference model (ARM): an information model that describes the information requirements and constraints of a specific application context.

3.1.8 conformance class: a subset of an application protocol for which conformance may be claimed.

3.1.9 data: a representation of information in a formal manner suitable for communication, interpretation, or processing by human beings or computers.

3.1.10 implementation method: a part of this International Standard that specifies a technique used by computer systems to exchange product data that is described using the EXPRESS data specification language [ISO 10303-11].

3.1.11 interpretation: the process of adapting a resource construct from the integrated resources to satisfy a requirement of an application protocol. This may involve the addition of restrictions on attributes, the addition of constraints, the addition of relationships among resource constructs.

3.1.12 product data: a representation of information about a product in a formal manner suitable for communication, interpretation, or processing by human beings or by computers.

3.1.13 resource construct: a collection of EXPRESS entities, types, functions, rules and references that together define a valid description of an aspect of product data.

3.1.14 unit of functionality (UoF): a collection of application objects and their relationships that defines one or more concepts within the application context such that removal of any component would render the concepts incomplete or ambiguous.

3.2 Terms defined in ISO 10303-202

This SC4 standing document makes use of the following terms defined in ISO 10303-202.

3.2.1 application interpreted construct (AIC): a logical grouping of interpreted constructs that supports a specific function for the usage of product data across multiple application contexts.

3.3 Abbreviations

For the purposes of this SC4 standing document, the following abbreviations apply.

AAM application activity model

AIC application interpreted construct

AIM application interpreted model

AP application protocol

ARM application reference model

CC conformance class

IR integrated resource

UoF unit of functionality

4 Interpretation process in STEP

The interpretation process is a formal and established part of the AP development process. STEP has defined standardized resources that are used as the basis for interpretation: the integrated resources and AICs1. The interpretation process includes activities such as: analyze ARM requirements, determine, and select the corresponding resource constructs (from the integrated resources or AICs), develop the ARM to AIM mapping table, and create the AIM EXPRESS short and expanded listings.

1 The term “resources” is used throughout this document to refer to both constructs in the integrated resources and the AICs.

The individual AP projects are responsible for the interpretation activities; these activities are supported by the Quality Committee through documentation of the process and the metrics with which to evaluate the execution of the process. Interpretation typically takes place in one or more workshops. During an interpretation workshop the AIM is constructed by interpreting the integrated resources. The number of AIM development workshops required to complete the interpretation for each application protocol project depends on the complexity of the information requirements and the size of the scope for the application protocol's domain. It is the responsibility of the AP team to ensure participation of properly skilled resources at each interpretation meeting. The AP project team brings to the process a detailed understanding of the domain information requirements. Workshop participants must also include individuals with a detailed understanding of the integrated resources, existing AICs, and the interpretation process.

The AIM development activities, of which the interpretation process is the primary focus, may be organized into four phases: preparation, interpretation, documentation, and review/sign-off. This document describes the technical activities involved in the first three phases. Review and sign-off phase follows the procedures defined in the ISO TC 184/SC4 organization handbook.

4.1 Preparation phase

The preparation phase of the interpretation process consists of an initial workshop to review the scope and requirements of the AP as documented in clauses 1-4 of the AP. The primary objective of the workshop is to educate the group of people who will be participating in the interpretation on the scope of the application protocol. This workshop focuses on a walk-through and analysis of the ARM, and can typically be accomplished in one day. Participants in the workshop must include: application domain experts, ARM developers, STEP integrated resource experts, and interpretation experts. Goals of the initial workshop are to:

— provide the interpretation experts with an initial understanding of the intended semantics of the ARM so they can adequately prepare for the interpretation workshop;

— enable the STEP resource experts to assess the availability of the resources required by the ARM;

— allow the STEP resource experts to identify requirements common to other APs, for the potential usage of existing AICs or the identification of new AICs; and

— plan for the interpretation phase.

4.1.1 Analyze ARM requirements

A walk-through and analysis of the ARM is required to provide an understanding of the AP’s information requirements. During the initial workshop, developers of the ARM (i.e., the AP project team) present explanations of the use of modeling constructs to capture the information requirements of the application domain.

Clause 4 of the AP is reviewed by the interpretation experts following the initial workshop. This clause provides a textual specification of the ARM that is organized by units of functionality (UoFs). A review of clause 4 is performed to identify nuances in the definitional material which are not explicitly represented in the ARM diagrams.

4.1.2 Assess integrated resource constructs

Based on the understanding of the ARM requirements, experts on the STEP integrated resources will assess the available resource constructs from the integrated resources that can satisfy the requirements. If voids in the integrated resources are identified, issues will be documented to describe the AP requirements and the voids. The decision is made during the workshop to either eliminate the requirements from the AP or promote the modification or further development of the integrated resources.

This decision reflects consensus among members of the AP and experts on the integrated resources and may be influenced by schedules and budget of the AP project team. Any change to the AP scope should be documented as an issue and must be reflected by changes to the AP document. Significant scope changes, for any reason, may require a new work item ballot.

4.1.3 Identify potential usage of AICs

During the ARM walk-through and analysis, requirements that are common with other APs will be identified. Existing AICs which may satisfy the requirements are identified for potential use. If no AIC exists to meet the common requirements, then the possibility of defining a new AIC is raised (see Guidelines for application interpreted construct development). The initial scope and contents of each potential new AIC may be discussed. Further review of existing AICs and of APs with common requirements may be needed during the preparation phase to determine the requirements for AICs.

Meetings among AP development projects with the common requirements may be organized to develop any new AICs.

4.1.4 Plan for interpretation phase

At the initial workshop, planning for interpretation takes place. This planning may include scheduling of the interpretation workshop, identification of participants and the roles they will play in the interpretation, discussion on the preparation that is required of the AP development team, and identification of materials required at the interpretation workshop. The AP team will be required to bring to the interpretation workshop copies and view graphs of the ARM diagrams, copies of the first four clauses of the application protocol document, and a partially completed ARM to AIM mapping table. The partially completed mapping table contains the entities, attributes, and assertions from clause 4 of the AP, organized into sub-tables by UoF. Details on the presentation of the mapping table are found in Guidelines for the development of mapping tables.

4.2 Interpretation phase

The interpretation phase is the primary component of the interpretation process; the AIM is produced during this phase. Interpretation is based on the foundation laid by the review of the scope and requirements documented in clauses 1 through 4 of the AP during the preparation phase. The objectives of the interpretation phase are:

— to select the required STEP standardized resource constructs (from IRs or AICs) to satisfy ARM requirements;

— to map ARM constructs to the selected resource constructs; and

— to create the additional EXPRESS constructs and constraints needed to satisfy ARM requirements and to specify the AIM short listing.

This phase usually requires a number of workshops depending on the complexity and size of the ARM.

Workshop participants must include the STEP resource experts, interpretation experts, and ideally three individuals from the AP development team. The resources from the AP development team should include one person to lead the detailed walkthrough of the ARM, one to take notes on the documentation of the AIM short listing, and one to take notes on the mappings.

A typical workshop is organized as follows:

— identify and prioritize the UoFs to be interpreted during the workshop;

— by UoF, walkthrough each ARM element selecting and mapping ARM constructs to the resources;

— identify usage of AICs based on common requirements with other APs;

— establish the scope and content of any new AICs;

— define resource voids and requirements.

The goal of the workshops in the interpretation phase is to capture the interpretation in the ARM to AIM mapping table and to identify the new constructs and constraints that will be documented in the AIM EXPRESS short listing to the extent that the AP team will be able to complete the mapping table and the short listing on their own. It is important that notes be taken during the workshop, by members of the AP development team, such that contentious, complex, or confusing mappings are captured sufficiently so that the AP team will be able to document them in the AIM and explain the mappings to implementors.

4.2.1 Select resource constructs

During the interpretation workshop, STEP resource experts determine which resource constructs are appropriate to meet the requirements for the ARM constructs. The selection process often involves further discussions or clarifications of the ARM constructs; these may include review of the intended information requirements, the usage of the information, or description of real-world usage scenarios of the application protocol. (Such information should be documented in the AP validation report, as described in Guidelines for the development and approval of STEP application protocols.) These discussions build on the understanding of the AP that was gained through the preparation phase. The result of these discussions is the specification of one or several resource constructs which satisfy the requirements of the ARM construct, along with any needed constraints.

As mentioned in the introduction, the objective of interpretation is to ensure the consistent interpretation of the same requirements found in different APs. Consistency can only be guaranteed when the requirements are understood to be the same. As the interpretation process is grounded in human understanding, consistency depends on an accurate understanding of requirements--which are often implicit or incorrectly specified in the AP document. The discussions during the interpretation sessions are intended to result in an accurate comprehension of the requirements of the application protocol.

It is possible that these detailed discussions of the requirements documented in an AP will lead to changes to the ARM. There are four primary reasons for such changes:

— Semantic analysis undertaken during the interpretation workshop has revealed a deficiency in the requirements (i.e., missing requirements) and additional constructs are required by the AP project team to sufficiently state the requirements.

— Semantic analysis undertaken during the interpretation workshop has revealed an error or errors in the model and modifications are desired by the AP team to "fix" the model.

— The application of the rules for specification of application objects and assertions in the mapping table to the ARM model structure will result in an unclear, convoluted, or lengthy reference path in the mapping table. A restructuring of the ARM objects and relationships will result in a much simpler and clearer specification of the mapping of the same requirements and is desired by the AP project team.

— Integrated resources are insufficient to support a particular requirement, and the decision is made not to enhance the integrated resources, but to remove the requirement from the application protocol (see 5.1.2).

In no case will the interpretation process change the requirements that the AP supports without the agreement of the AP development team.

The integrated resource constructs are designed for generic use by all APs. Some APs have more requirements than others. In the selection process, the best entity for an ARM requirement may have attributes that are not supported by requirements in the ARM. As long as the additional attributes have underlying types that are base types, this is not considered a problem. For example, many resource entities include required attributes such as name and description. These attributes have the base type STRING. Where there is no data to support the instantiation of these attributes, the developers of an application protocol may choose to document recommended values for these attributes in the “Implementation usage guide” annex of the AP.

4.2.2 Capture interpretation in mapping table

The mapping table is a pivotal component of an AP. The mapping table specifies the relationship between the requirements as specified in the ARM and the resource constructs that satisfy those requirements. This clause discusses how interpretation results are captured within the mapping.

Details and examples for the development and documentation of a mapping table are provided in Guidelines for the development of mapping tables.

The AP development team brings a partially completed ARM to AIM mapping table (see 4.1.4) to the interpretation workshop. During the workshop, as STEP resource experts determine which resource constructs are appropriate to meet the requirements for the ARM constructs, the AP development team populates other portions of the mapping table.

There is rarely a one-to-one mapping between constructs in the ARM and AIM because the ARM and the STEP integrated resources were defined under different contexts. During the interpretation workshop, integrated resource experts will identify the constructs in the integrated resources to which the ARM constructs map. A particular ARM object may map to one resource construct or more than one resource construct in an AND situation, an OR situation or a combination of the two. The details of the mapping, including the circumstances under which each mapping applies will be identified by the interpretation team and documented in the partial mapping table by the AP project team.

The mapping table specifies the data reference path for certain mappings. A data reference path is a directed sequence of (AIM) entities that are linked through attribute relationships or subtype/supertype relationships. Reference paths are specified in the mapping table only when the mapping of the application object from the ARM to the resource constructs creates one of the following circumstances:

— A new entity is defined in the AIM as a subtype of an integrated resource entity. Constructs that represent completely new concepts cannot be independently specified in the AIM, but must be derived from existing resource constructs. The AIM extends the definitions from existing resources through specialization. All new entities introduced in the AIM are subtypes of resource entities with refined definitions or added constraints. New entities are created in order to add constraints to an existing concept (represented by a construct from the resources). These extensions to the generic definitions apply only within the particular application context defined in that AP. The reference path for new entities introduced in an AIM must include a resource supertype entity.

— An ARM attribute and the ARM entity do not map to the same entity. An ARM attribute may be mapped to either a resource entity or an attribute of a resource entity. When the ARM entity to which this attribute belongs is mapped to a different resource entity, a reference path specification is required. The reference path specification provides the entire access path which begins at the AIM element corresponding with the ARM entity to which the ARM attribute belongs, and ends at the AIM element corresponding with the ARM attribute. When the ARM attribute maps to an attribute of the AIM entity to which the ARM entity maps, no reference path is required.

— An attribute of an AIM entity must be assigned a specific value. The mapping of an ARM entity to a resource entity may require that an attribute (or attributes) of the resource entity have a specific value. In the mapping, the value of the attribute(s) must be restricted or assigned in the specification of the reference path. A reference path will show the mapped AIM entities and attributes and the attribute values.

— A relationship exists between two ARM entities that map to different resource entities. The relationship is mapped as a reference path between AIM entities. The reference path shows the entire data access path between the mapped resource constructs.

— A constraint on the mapping must be documented. Such mapping rules may be included in reference paths that are required for one of the above reasons, or a path may be specified for the sole purpose of including a mapping rule.

The critical elements of the reference paths will be specified by the interpretation team during the workshop and documented in the partial mapping table by the AP development team. To save time, not all paths will be completely specified by the interpretation team during the workshop. Some paths are trivial; some paths are repetitive. The interpretation team will ensure that the AP development team has an adequate understanding of the mappings so that the details of documenting the paths can be completed outside of the workshop.

4.2.3 Develop AIM EXPRESS short listing

An AIM is constructed from the resources (IRs or AICs) through the use of an inter-schema reference specification; this AIM schema is called the short listing. The short listing consists of two parts. The first part contains the interface specification which provides the relationship between the resources and the AIM. The second part defines the unique AIM constructs that refine or specialize the usage of the integrated resources.

The development of the short listing consists of two tasks:

— specify the interface to the resources; and

— specify AIM unique constructs and constraints.

During the interpretation workshop, the new constructs and constraints are identified. The encoding of these constructs and constraints in EXPRESS, and the specification of the interfaces to the resources is accomplished by the AP development team outside of the interpretation workshop.

This clause of this document describes the development of the short listing from a functional perspective.

Clause 5 of this document provides more detail on the use of EXPRESS to document the short listing.

4.2.3.1 Establish a formal interface to the resources

The EXPRESS short listing reflects the selection of the resource constructs through a formal interface specification method. This interface is accomplished through the EXPRESS USE FROM specification described in clause 11 of ISO 10303-11. The objective of employing USE FROM in an AIM is to specify a schema that may be implemented independently from any another schema. The AIM schema is considered conceptually self-contained by virtue of the use of the USE FROM keyword. This functionality contrasts with the integration practice in which schema extensions are made by using the EXPRESS REFERENCE FROM keyword to link together schemas with different scopes, thereby extending the scope of the collection of linked schemas. This is the process used to develop the integrated resources. USE FROM is the interface mechanism that is employed to specify the relationship between the resources and the AIM. The information provided in clause 5.1 of this document will provide more details on how to use the EXPRESS language to completely specify the interface to the integrated resources.

NOTE - The distinction between self contained and extended schemas was a requirement for EXPRESS that is not explicitly stated in ISO 10303-11; however, this is an established STEP practice.

The STEP integration architecture requires that a minimum set of constructs be included in the AIM to ensure the completeness of the semantics of product information. Regardless of its domain and scope, each AP must include resource constructs which identify the product, the product type, the version of the product, the product definition and the applicable life cycle stage of the definition. Annex A provides a listing of the EXPRESS constructs from the integrated resources that will appear in every AP. In the case where these concepts are not explicitly stated in the ARM, they will be documented in the AIM as associated information that supports the primary information required by the ARM.

4.2.3.2 Develop unique AIM constructs

The AIM short listing also specifies all constructs that are new and unique to the AIM, which may include entities, attributes, type definitions, local and global rules, and functions. Only two classes of new constructs are allowed in an AIM; those that:

— complete and assign a concept definition; and

— constrain a generic concept.

4.2.3.2.1 Concept completion and assignment

In the STEP integrated resources, there are a number of template structures that have been used to specify product data management resources, such as the construct specified in annex E of ISO 10303-41. These template structures are semantically incomplete by themselves; they are designed to be used by application protocols to specify structurally similar though semantically dissimilar concepts in a standard and consistent manner. The template entity is completed by an explicit and unique assignment of semantics in the AIM. The explicit assignments are made between the management concepts (e.g., approval or organization) and the items that require the management information. Details on how the new AIM constructs which complete the assignment template structure are documented in the AIM short listing are provided in clause 5.2.3 of this document.

4.2.3.2.2 Constrain generic concept

Standardized STEP resource constructs are generic in nature and designed to be shared by multiple application contexts. Several APs may require the same generic concept that a resource construct represents, but each may constrain the generic concepts in order to represent a specific usage within the AP domain. New AIM constructs may be created (through subtyping) to:

— constrain a generic concept;

— constrain the relationship between generic concepts; or

— create multiple, specialized concepts of the generic concept, through specification of different constraints representing different usages of the same generic concept under specific circumstances within the domain of the AP.

4.3 Documentation phase

The objective of this phase is to document the interpretation results by producing the formal document elements of the AP. No workshops are necessary for this phase of the AIM development process. The AP development team is responsible for the documentation of the AIM components. The rules for documenting the AIM and its constituent elements are defined in Supplementary directives for the drafting and presentation of ISO 10303. The main components of the AIM documentation are the:

— AIM EXPRESS short listing;

— mapping table;

— definitions of newly-defined constructs and modifications to integrated resources as included in the AIM;

— AIM EXPRESS expanded listing and corresponding short names table; and

— EXPRESS-G corresponding to the AIM EXPRESS expanded listing.

The first step of the documentation phase is the completion of a consistency check of the interpretation.

Because the AP is interpreted by UoFs, and may have been interpreted in a series of workshops, it is important to conduct several consistency checks prior to completing the documentation of the interpretation. The consistency checks may identify the need for additional global and local rules, or reinterpretation of certain constructs.

Following the consistency checks, development of the AIM short form EXPRESS and the mapping table that was started in the interpretation phase is completed. Guidance on completing the mapping table is found in Guidelines for the development of mapping tables, and guidance on completing the AIM short form is given in clause 5 of this document. Once these are complete and correct, definitions for the newly defined AIM constructs and modified definitions for the constructs imported from the resources are written. The AIM EXPRESS expanded listing and the EXPRESS-G diagrams for the expanded listing are produced directly from the AIM EXPRESS short listing. The short names are generated from the AIM EXPRESS expanded listing in the final step of the documentation phase.

4.3.1 Perform consistency checks

Because the interpretation was performed UoF by UoF, an potentially over the course of several workshops, after the interpretation is completed, an ARM wide consistency review must be performed.

There are several consistency checks required.

— ARM/AIM cardinality consistency check. This check involves examining all the cardinalities in the ARM and ensuring they match the cardinality in the AIM. If any ARM cardinalities are other than zero, one or many (0,1,M), examine how the cardinality is reflected in the AIM. If the cardinality in the AIM is different, write a global rule to constrain the AIM cardinality.

— Mapping table consistency check. In this check, the mapping is examined to ensure that different ARM constructs are not mapped to the same instance of an AIM construct. First, identify all ARM elements that map to the same AIM element and determine whether they map to the same instance.

Examine the reference paths, particularly the path constraints as well. If multiple ARM constructs map to the same attribute of the same instance, the mapping must be changed. Raise issues against the mapping to the interpreters and re-map problem areas.

— Subtype and supertype consistency check. This check examines the relationships between subtypes created in the AIM and their relationships to other subtypes of the same supertype that would be imported into the AIM EXPRESS expanded listing. Examine whether the supertype can be instantiated itself. Write global rules to restrict instantiation of subtypes.

— Mapping rule consistency check. This check is to ensure that string values in the mapping rules found in reference paths in the mapping table are consistent with the types and values in the ARM.

— Value domain consistency check. This check results in rules constraining a string population to be of a defined set. Examine the mapping rules that were identified during the interpretation and determine whether you know the complete set of populations of a string attribute. If so, you can write a global rule that requires the string value to be limited to that set. Such a rule cannot be written for open-ended enumerations. The constraint could also be written as a local rule if the restrictions all apply to one mapping and a subtype was created as a place holder for other local rules.

— Context consistency check. In this check, guidance for population of values for application_-context_schema attributes is derived from usage scenarios. Examine the activity model. If the same data set can flow in two or more paths, then multiple values may be needed. If a data set is only valid in one environment, the values may need to be constrained on a per conformance class basis.

— Dependent instantiability consistency check. This check is performed once the AIM is complete.

This check is described in steps 6 and 7 of annex C of this document.

4.3.2 Define new and modified AIM constructs

The AP document must include complete definitions of all new AIM constructs found in the AIM EXPRESS short listing. It may also include textual definitions and descriptions from the interfaced integrated resource constructs that have been further modified to suit the established application context of the AP.

4.3.3 Produce AIM EXPRESS expanded listing

The expanded form of the AIM is a single EXPRESS source schema which contains all constructs that are defined in the AIM short listing and all constructs explicitly or implicitly interfaced from the integrated resources or AICs. No references to any integrated resource or AIC schema are allowed in the EXPRESS expanded listing. In development of the EXPRESS expanded listing, constructs from the integrated resources which are not in scope of the AP are “pruned” from the subtype/supertype trees and select lists.

This process is described in clause 5 in more detail. The algorithm for expanding references in a short form schema is provided in clause 11 of ISO 10303-11. Software tools that perform this function are available in the public domain for use by AP developers [Libes].

4.3.4 Produce AIM EXPRESS-G diagrams

The AIM EXPRESS-G diagrams correspond to the AIM expanded listing. All the named data types (entities and types) in the AIM expanded listing shall be presented in the diagrams with two exceptions:

EXPRESS base types and any select types that are not referenced by other entities do not need not be shown on the EXPRESS-G diagrams. If non-referenced select types are eliminated from the diagrams, a note that lists the eliminated types must be provided in the annex containing the EXPRESS-G diagrams.

The note is placed after the boilerplate text for the annex and is of the form:

NOTE - The following select types: <select_type_1>, <select_type_2>, and <select_type_n> are interfaced into the AIM expanded listing according to the implicit interface rules of ISO 10303-11. These select types are not referenced by other entities in this part of ISO 10303.

4.3.5 Produce short names table

Short names are required for each entity in the AIM EXPRESS long form schema. An explanation of short names is found in the AP Guidelines. The short names are generated by a software tool used by the SC4 Secretariat at NIST. Prior to publication of any part containing an EXPRESS schema, the schema shall be sent to NIST for short name generation. Guidance on documenting short names in the AP is given in the Supplementary directives for the drafting and presentation of ISO 10303.

5 EXPRESS usage guidelines for interpretation

In the previous clause, the process of interpretation was presented from a functional viewpoint. This clause will describe the use of the EXPRESS language for developing the AIM EXPRESS short listing to be used in processes described in clause 4.2.3, and provide additional details that describe the semantics of a particular usage of EXPRESS.

5.1 Schema interface

The need for an AIM to establish a formal relationship to the integrated resources through the EXPRESS USE FROM keyword is described in 4.2.3.1. USE FROM is the only interface mechanism that shall be employed in an AIM.

The USE FROM keyword is employed to interface named data types and entire schemas into another schema. In an AIM EXPRESS short form, if the interface is to a construct defined in the integrated resources, the desired construct is individually named in the interface specification for the schema in which the construct is defined. If all constructs from an integrated resource schema are desired, the entire schema may be interfaced by providing only the schema name in the interface specification. If the interface is to an AIC, only the AIC schema name is provided. The AIC must be used in its entirety; the use of subsets of an AIC is not allowed.

The objective in specifying the interface to the resources is to specify the minimum set of constructs in USE FROM statements that:

— satisfies the visibility requirements for creation of unique AIM constructs;

— results in the required content of the AIM; and

— satisfies the requirements for independent instantiability.

In order to be able to accomplish this objective, the AP development team must understand the interface mechanism as described in ISO 10303-11, and know which constructs from the integrated resources are required in the AIM. The following text provides guidance on how to satisfy the above requirements and meet the objective of having the minimum set of interfaced entities.

5.1.1 Visibility

A construct defined in a foreign schema must be visible to be named in the declaration of another construct in the local schema. Employing the USE FROM keyword has the effect of making explicitly mentioned named data types visible within the local schema. Therefore, every entity or type that is called out in the declaration of a type, entity, global rule, or function within the AIM short listing must be explicitly mentioned in the interface specification if it is not locally declared. This includes (but is not limited to) the supertype entities that are being subtyped in the AIM, the entities being constrained in global rules, the entities in the parameter list and return type of functions.

Entities that are named in strings in calls to the EXPRESS built-in function TYPEOF are not required by ISO 10303-11 to be visible. However, in practice, the naming of entities that are not in the scope of the AIM schema in TYPEOF strings shall be avoided in locally defined constructs. Where interfaced entities name non-interfaced entities in strings, it is not required that these entities be interfaced into the AIM schema. In these cases, calls to the TYPEOF function containing entities that are outside the APs scope will always be false. The AP team shall include a note to that effect for specific cases.

The USE FROM keyword only applies to named data types (see clause 11.1 of ISO…