STEP标准执行方法-ISO-10303-21

    STEP- File是的STEP应用最广泛的数据交换格式。由于它的ASCII码的结构很容易阅读与通常每行一个实例。STEP文件格式是Exchange结构在ISO 10303-21 EXPRESS编码定义。

ISO 10303-21定义的编码机制，关于如何根据通过一个Express Schema 表达数据，不是Express Schema本身。一个Step文件也被称为P21 -文件和STEP物理文件。文件扩展名为：‘.STP’和‘.step’。扩展名称同时表明该文件包含的数据符合STEP应用协议。 相对的扩展名为‘.P21’的文件是为其他目的。

1. 历史

      具体细节如下：

• ISO 10303-21:1994的第一个版本有一些错误，这是由一个技术勘误更正。因此，建议用户学习第二版代替（见下文） 。
• 第二版的ISO 10303-21:2002 ，包括所有的修正和扩展多个数据段。
• Part 21定义了两种一致性等级。它们的区别仅在于如何编码复杂的实体实例。

• 一致性等级1 ，总是使用执行所谓的内部映射，这是更紧凑。
• 一致性等级2 ，这是不是在实践中，始终强制执行外部映射。在理论上，这将允许更好的AP的互操作性，因为一个后处理器可能知道如何处理一些超类型，但可能不知道指定的亚型。

• Part 21第1版强制使用的所谓的短名称，它是可选的第二版。然而在实践中，短名字很少被采用。
• 第二版允许使用多个数据段。然而在实践中，大多数的实现只使用一个单一的数据部分（第1版编码）。

1. ISO 10303-21 构建块例子

下面给出了一个典型的示例

ISO-10303-21;

HEADER;

FILE_DESCRIPTION(

/* description */ ('A minimal AP214 example with a single part'),

/* implementation_level */ '2;1');

FILE_NAME(

/* name */ 'demo',

/* time_stamp */ '2003-12-27T11:57:53',

/* author */ ('Lothar Klein'),

/* organization */ ('LKSoft'),

/* preprocessor_version */ ' ',

/* originating_system */ 'IDA-STEP',

/* authorization */ ' ');

FILE_SCHEMA (('AUTOMOTIVE_DESIGN { 1 0 10303 214 2 1 1}'));

ENDSEC;

DATA;

#10=ORGANIZATION('O0001','LKSoft','company');

#11=PRODUCT_DEFINITION_CONTEXT('part definition',#12,'manufacturing');

#12=APPLICATION_CONTEXT('mechanical design');

#13=APPLICATION_PROTOCOL_DEFINITION('','automotive_design',2003,#12);

#14=PRODUCT_DEFINITION('0',$,#15,#11);

#15=PRODUCT_DEFINITION_FORMATION('1',$,#16);

#16=PRODUCT('A0001','Test Part 1','',(#18));

#17=PRODUCT_RELATED_PRODUCT_CATEGORY('part',$,(#16));

#18=PRODUCT_CONTEXT('',#12,'');

#19=APPLIED_ORGANIZATION_ASSIGNMENT(#10,#20,(#16));

#20=ORGANIZATION_ROLE('id owner');

ENDSEC;

END-ISO-10303-21;

HEADER 段

就像在上面的例子中，文件在初始关键字‘ISO- 10303 -21’后被分成两部分：

HEAD部分具有由3〜 6组给定的顺序固定的结构。除了数据字段TIME_STAMP和FILE_SCHEMA，所有字段可能包含空字符串。

• FILE_DESCRIPTION

• Description：描述说明
• implementation_level：这个文件的版本和一致性选项。可能的版本是“ 1 ”为原标准早在1994年，1995年“ 2 ”为技术勘误和“3”的第二版。一致性选项可以是“ 1”的内部和“2”为复杂的实体实例的外部映射。通常情况下，人们会发现这里的值__ '2 ; 1'__ 。该值'2 2'执行外部映射也是可能的，但只有很少使用。该值'3 ， 1'和'3 2'表示在2001年的标准有几个数据段，多个模式和FILE_POPULATION支持定义的扩展STEP-文件。

• FILE_NAME

• name of this exchange structure：名字：可能对应于文件名的文件系统或反映在该文件中的数据。没有严格的规则如何使用这个领域
• time_stamp：表示创建此文件时的时间。时间是由于在国际数据时间格式ISO 8601 ，如2003 - 12 - 27T11 ： 57:53 2003年12月27日， 2分钟，中午的时候。
• Author：建立这个交换结构的人的姓名和邮寄地址
• Organization： 创建这所属的组织
• preprocessor_version：该系统及其版本产生这个STEP文件的名称
• originating_system：该系统及其版本，最初创建包含在这个STEP-文件中的信息的名称。
• Authorization： 版权所有者的名称和邮寄地址

• FILE_SCHEMA.

• 指定一个或多个Express schema 控制在数据段的信息，对于第一版本来说，仅一个Express schema 并且这个schema必须符合ASN.1对象标识符规则的可以被列在这里。第二版后可以指定多个 EXPRESS schema.

后续的三个头段的组，仅在第二版有效，具体如下

• FILE_POPULATION：表示一个有效的实体实例集合数（实体实例集合），它符合一个Express Schema。这是通过收集从几个data_sections和参考实例从其它的数据段的数据进行。

• governing_schema：EXPRESS Schema到指定的实体实例集合数属于与通过它可以进行验证。
• determination_method找出哪些情况属于实体实例集合数。三种方法是预先定义：

• SECTION_BOUNDARY ，
• INCLUDE_ALL_COMPATIBLE
• INCLUDE_REFERENCED 。

•  governed_sections ，数据部分的实体实例完全属于实体实例集合数。
•  FILE_POPULATION的概念是非常接近SDAI的schema_instance 。不幸的是，在标准化的过程中，这是不可能达成协议，以合并这些概念。因此， JSDAI进一步增加了属性FILE_POPULATION智能意见涵盖schema_instance所有丢失的信息。这都支持导入和导出。

• SECTION_LANGUAGE: 允许的默认语言为所有或特定的数据段分配。这是必要的，不提供来指定，如名称和描述实体的语言字符串属性被赋予能力的快速模式。
• SECTION_CONTEXT ：提供的功能来指定所有或单个数据段的附加上下文信息。这可以例如使用用于STEP - AP以指示哪些一致性等级所覆盖的特定​​数据段中。

DATA 段

数据部分根据一个特定的快递模式包含应用程序数据。这个数据的编码遵循一些简单的原则。

• 实例名称（Instance name）: 在STEP文件中交换结构的每一个实体实例的形式给出一个唯一的名称“ ＃ 1234” 。实例名必须包含一个正数（> 0）和通常小于263 。实例名称仅在本STEP文件中有效。如果相同的内容从系统再次导出的实例名称可能是相同但实例不同。实例名也被用来通过属性值或聚合成员引用其他实体实例。所引用的实例之前或之后的当前实例进行定义。
• 单一实体的数据类型的实例:通过写大写字母实体的名称来表示，然后接着在括号内定义的顺序的属性值。参见，例如“ ＃ 16 = PRODUCT （ ... ） ”上面。
• 复杂的实体数据类型:实例是通过使用内部映射或外部映射为代表的STEP文件。
• 外部映射一直被使用，如果复杂的实体实例由一个以上的休假实体。在这种情况下，所有的单个实体实例的值彼此独立地在如上述定义与分组一起在括号中所有的实体值按字母顺序给出。
• 内部映射默认情况下使用的一致性选项1 ，当复杂的实体实例只包含一个假的实体。编码是类似与子类型定义中给出的附加顺序单个实体实例之一。
• 属性值的映射:

• 只有明确的属性被映射。逆，派生并重新申报未列出属性，因为它们的值可以从其他的推断。
• 取消设置属性值给定为“$” 。
• 它得到了重新声明为导出的一个子型明确的属性被编码为在父属性的位置“*” 。

• 映射其它数据类型：

• 枚举，布尔和逻辑值在一个大写字母开头和结尾点，如“.TRUE” 。

• 字符串值在“ ” 。用于与代码字符大于126的特别编码。支持定义在ISO 8859和10646的字符集。需要注意的是典型的8 （例如西欧）或16 （ Unicode）的位字符集不能直接采取STEP文件的字符串。他们有一个非常特殊的方式来进行解码。
• 整数和实值与典型的编程语言相同
• 二进制值（位序列）被编码为十六进制，并用双引号包围，与领先的字符指示未使用的比特数（ 0 ， 1 ​​， 2 ，或3 ），其次是数据的大写的十六进制编码。要注意，在整个二进制值被编码为一个十六进制数，以在所述第一进制字符的最高阶比特和在最后一个最低阶位是很重要的。
• 聚集（SET，BAG,LIST， ARRAY ）的元素在括号中给出，以“，”分隔。
• 注意要采取基于定义的数据类型选择数据类型。这里定义的数据类型的名称都映射了。

  对应数据段和HEADER段，通过不同的Schema定义，数据段与应用协议相关，HEAD段的Schema定义如下：

ISO-10303-21 头

原始文件内容如下：

SCHEMA header_section_schema;

TYPE exchange_structure_identifier = STRING;

END_TYPE;

ENTITY file_description;

  description          : LIST [1:?] OF STRING (256) ;

  implementation_level : STRING (256) ;

END_ENTITY;

ENTITY file_name;

  name                 : STRING (256) ;

  time_stamp           : time_stamp_text ;

  author               : LIST [ 1 : ? ] OF STRING (256) ;

  organization         : LIST [ 1 : ? ] OF STRING (256) ;

  preprocessor_version : STRING (256) ;

  originating_system   : STRING (256) ;

  authorization        : STRING (256) ;

END_ENTITY;

TYPE time_stamp_text = STRING(256);

END_TYPE;

ENTITY file_schema;

  schema_identifiers : LIST [1:?] OF UNIQUE schema_name;

END_ENTITY;

TYPE schema_name = STRING(1024);

END_TYPE;

ENTITY file_population;

  governing_schema      : schema_name;

  determination_method  : exchange_structure_identifier;

  governed_sections     : OPTIONAL SET [ 1 : ? ] OF section_name;

END_ENTITY;

TYPE section_name = exchange_structure_identifier;

END_TYPE;

ENTITY section_language;

  section          : OPTIONAL section_name;

  default_language : language_name;

UNIQUE

  UR1: section;

END_ENTITY;

TYPE language_name = exchange_structure_identifier;

END_TYPE;

ENTITY section_context;

  section             : OPTIONAL section_name;

  context_identifiers : LIST [1:?] OF context_name;

UNIQUE

  UR1: section;

END_ENTITY;

TYPE context_name = STRING;

END_TYPE;

END_SCHEMA;