名称

定义

举例说明

倒栽跳水部分

数据部分

历史

外部链接

名称

ISO 10303-21 步文件 是最用途广泛的数据交换的形式 步. 由于它 ASCII 结构它是容易阅读的以典型地每条线一个事例。 步文件的格式在ISO 10303-21中被定义 交换结构的明码文本内码. ISO 10303-21定义了内码机制关于怎样根据指定的代表数据 明确图解，但不是明确图解。 步文件也叫 p21文件 并且 步物理文件. 文件扩展名 .stp 并且 .step 表明文件包含数据符合步应用协议。

定义

ISO 10303-21 步文件 是最用途广泛的数据交换的形式 步. 由于它 ASCII 结构它是容易阅读的以典型地每条线一个事例。 步文件的格式在ISO 10303-21中被定义 交换结构的明码文本内码. ISO 10303-21定义了内码机制关于怎样根据指定的代表数据 明确图解，但不是明确图解。 步文件也叫 p21文件 并且 步物理文件. 文件扩展名 .stp 并且 .step 表明文件包含数据符合步应用协议。

举例说明

一个典型的例子如下所示:

ISO-10303-21;倒栽跳水;

FILE_DESCRIPTION ( /*描述* (‘一个最小的AP214例子以单件’)，

/* implementation_level * ‘2; 1’);

FILE_NAME ( /*名字* ‘演示’，/* time_stamp * ‘2003-12-27T11 ：57 ：53’，

/*作者* (‘Lothar Klein’)，

/*组织* (‘LKSoft’)，

/* preprocessor_version * "，

/* originating_system * ‘IDA-STEP’， /*授权* ");

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

ENDSEC;

数据;

#10=ORGANIZATION (‘O0001’， ‘LKSoft’， ‘公司’);

#11=PRODUCT_DEFINITION_CONTEXT (‘部分定义’， #12， ‘制造业’); #12=APPLICATION_CONTEXT (‘机械设计’);

#13=APPLICATION_PROTOCOL_DEFINITION ("， ‘automotive_design’， 2003年， #12); #14=PRODUCT_DEFINITION (‘0’， $、#15， #11);

#15=PRODUCT_DEFINITION_FORMATION (‘1’， $， #16);

#16=PRODUCT (‘A0001’， ‘测试第1部分’， "， (#18)); #17=PRODUCT_RELATED_PRODUCT_CATEGORY (‘部分’， $， (#16));

#18=PRODUCT_CONTEXT ("， #12， ");

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

#20=ORGANIZATION_ROLE (‘id所有者’);

ENDSEC;

END-ISO-10303-21;

倒栽跳水部分

您能从在文件之上的举例子看被分裂成二个部分从事最初的主题词 ISO-10303-21;:

倒栽跳水部分 有一个固定的结构包括的3到6小组在被发布的命令。 除了数据域 time_stamp 并且 FILE_SCHEMA 所有领域也许包含空字符串。

FILE_DESCRIPTION 描述 implementation_level. 这个文件的版本和依照选择。 可能的版本是1为原始的标准后面1994年， 2为技术错误1995年和3为再版。 依照选择是二者之一1为内部和2为外在映射复杂个体事例。 您这里经常将发现价值__ ‘2; 1’ __。 价值‘2; ’强制执行外部映射的2也是可能，但只很少使用。 价值‘3; 1’和‘3; 2’在2001标准表明延长的步文件如被定义与几数据部分、多个图解和FILE_POPULATION支持。 FILE_NAME 名字 这个交换结构。 它在这个文件也许对应于文件的名字在文件系统的或反射数据。 没有严密的规则如何使用这个领域。 time_stamp 当这个文件被创造了，表明时候。 时间在内部数据时间格式ISO 8601中被测量，即。 2003-12-27T11 ：57 ：53 为27 2003年12月， 2分钟到中午时间。 作者 创造这个交换结构的人的名字和邮寄的地址 组织 人属于的组织 preprocessor_version 生产这个步文件系统和它的版本的名字 originating_system 最初创造信息系统和它的版本的名字在这个步文件包含了。 授权 批准这个文件人的名字和邮寄的地址。 FILE_SCHEMA. 为版本2仅一个明确图解与图解的对象标识符一起可以这里被列出。 从版本3在此为几个词条是轻松。

最后3个倒栽跳水小组从版本3只合法的打开。

FILE_POPULATION，表明conformas对明确图解的合法的人口(设置个体事例)。 这由另外收集数据完成从几data_sections和参考事例从其他数据部分。 governing_schema明确图解被表明的人口属于，并且由哪些它可以被确认 determination_method 推测事例属于人口。 三mehods被预定义： SECTION_BOUNDARY、INCLUDE_ALL_COMPATIBLE和INCLUDE_REFERENCED。 governed_sections个体举例的数据部分充分地属于人口。 FILE_POPULATION的概念是非常紧挨SDAI schema_instance。 不幸地在标准化过程期间达到协议得到这些概念充分地同步是不可能的。 所以JSDAI增加进一步属性到FILE_POPULATION作为聪明的评论报道所有缺掉信息从schema_instance。 这为两个，进口和出口支持。 SECTION_LANGUAGE准许分配缺省语言为所有或为一个具体数据部分。 这为在的那些明确图解是需要的例如名字和描述给个体哪些语言串属性不提供有能力指定。 SECTION_CONTEXT提供有能力为所有或唯一数据部分指定另外的上下文信息。 可以使用这即。 为步APs表明哪依照类由一个特殊数据部分包括。

数据部分

数据 部分根据一个具体明确图解包含应用数据。 这数据内码根据一些简单的原则。

事例名字： 在交换结构给每个个体事例一个唯一名字以形式“#1234”。 事例名字必须包括一个正数(>0)并且是典型地少于2. 事例名字在步文件之内当地只是合法的。 如果同一个内容从系统再被出口事例名字也许是不同的为同样事例。 事例名字也使用通过属性值或聚集成员参考其他个体事例。 参考事例由在当前事例前后被定义。 唯一个体数据类型事例通过用大写字母写个体的名字在括号之内代表由属性值然后跟随在被定义的顺序。 看见即。 “#16=PRODUCT (...)”上述。 复杂个体数据类型事例在步文件代表通过使用内部映射或外在映射。 外部映射，如果复杂个体事例包括超过一事假个体，总有使用。 所有唯一个体事例价值从彼此以字母顺序独立地在这种情况下被测量如上所定义以括号内一起被编组的所有个体价值。 当复杂个体事例只包括一事假个体时，默认情况下内部映射为依照选择1使用。 内码是相似的到那个一个唯一个体事例以子型定义发布的另外的命令。 映射属性值： 仅明确属性得到映射。 因为他们的价值可以从其他部分，被推论相反，获得的和再宣称的属性不是列出的。 未装配属性值被给和“$". 在子型得到再宣称如获得的明确属性被输入和“*“在supertype属性的位置。 映射其他数据类型： 列举，布尔和逻辑值用大写字母测量与一个带领的和落后的小点例如“.TRUE.". 字符串值被测量在““。 对于字符以代码大于126一个特别内码使用。 如在ISO 8859和10646中被定义支持字符集。 注意，典型8 (即。 西欧人)或16个(Unicode)位字符集不可能为步文件串直接地被采取。 他们必须被解码用一个特别方式。 整数和真正的价值与典型的编程语言是半新相同的 聚集体的元素(设置，请求，列出，列阵)在括号里被给，分离由“,". 必须为根据被定义的数据类型的精选的数据类型保重。 被定义的数据类型的名字这里达到目的也是映射。 为此的更多细节参见“映射明确对Java”。

历史

有些细节照料：

ISO 10303-21的初版：1994有有些臭虫和得到固定由一个技术错误。 如果您想要学习这个标准您更好读… 再版ISO 10303-21 ：2002年，包括所有固定和引伸为几个数据部分。 第21部分定义了二依照类。 他们在怎样仅不同输入复杂个体事例。 总使用的依照类1强制执行所谓 内部映射 哪些是更加紧凑的。 没有得用于的依照类2实践强制执行 外在映射 总。 在理论，因为后处理也许会处理一些supertypes，但可能不知道指定的子型，这将允许更好的AP互用性。 第21的第1编辑部分强制执行对所谓的短的名字的用途。 哪些是任意的在第2编辑。 今天实践上没有使用短的名字。 第2编辑考虑到几个数据部分。 在只实践一个数据部分使用(第1个编辑内码)

外部链接

步指南 详细步骤文件文献 [! 它不是步文献，它是PDM (产品数据管理)图解描述，虽然用步表达…!]