PDX和ODX关系

来源：ASAM_AE_MCD-2_D_BS_ODX_V2-2-0.pdf
第九章：PDX-PACKAGE ODX DATA

9.1概述

ODX数据的交换可以通过一个名为“PDX Package"的文件容器来实现。所有要交换的文件都打包在一个PDX包中。一个PDX包可以处理不同类型的ODX文件与以下文件扩展名:

PDX包可能不仅包含ODX数据、文本或图片，还可能包含任意格式的任意文件。
PDX包的内容描述在一个单独的XML文档中，称为“PDX Package Cataloge目录”。PDX包目录本身不包含ODX数据，它被用作交换过程中元数据的存储库。
包含ODX数据或涉及到ODX/PDX交换过程的所有文件的文件名必须由所有符合ODX的工具以区分大小写的方式处理。文件扩展名应该总是用小写字母表示。PDX包目录的文件名应该总是小写的“index.xml”。

9.2PDX包的结构

9.2.1PDX Package Cataloge结构

一个PDX包由一个文件集合组成。PDX包的内容在PDX包目录中描述，它是存储在PDX包中的文件之一。PDX包目录UML建模如下。

PDX包目录由一个CATALOG实例表示;它提供了存储在相应PDX包中的所有文件的列表。这些文件条目可以逻辑地分组。例如，ODX数据文件可能存储在一个组中，用于文档的文件(手册、图片等)可能存储在另一个组中。
为此，目录包含一个所谓ABLOCKs的列表;每个ABLOCK表示一个逻辑组，并且可以包含任意数量的文件成员，每个成员表示PDX包中的单个文件。可选地，可以为ABLOCK指定类别成员。这允许为文件的分类，定义特定于流程的标准。

以下是为类别预定义的值:

• ODX-DATA用于派生自ODX-CATEGOBY的所有文件
• ODX-JOB用于所有job code文件(例如java文件、类文件、jar文件、dll文件)，
• LIB，用于job可以使用或导入的所有库程序
• PROGRAMMING-DATA用于ECU程序设计并从ECU-MEM中引用的二进制/十六进制文件的数据

预定的分类列表可以根据实际用例进行扩展。短名称是每个ABLOCK的强制成员。它标识了ABLOCK中的文件所属的logical组，而不是ABLOCK本身。具有相同短名称的多个ABLOCKs可能存在于一个PDX包目录中。每个ABLOCK可能包含一个可选的ADMIN-DATA成员来存储特定于ABLOCK的修订信息，即它引用ABLOCK中的所有文件。对PDX包中的所有文件有效的ADMIN-DATA和其他全局元数据(如COMPANY-DATA)可以直接存储在目录中(关于ADMIN-DATA和COMPANY-DATA的详细描述，请参阅第7.1.2.3小节)。ABLOCK具有一个强制的UPD成员，该成员描述数据交换过程中ABLOCK文件的更新状态。

• 属性UPD可以有以下值之一:
  
  

每个文件成员指定在PDX包中定位一个文件的文件名。可以使用可选属性指定此类文件的MIME-TYPE、创建者和创建日期。可以使用已经标准化的MIME类型作为MIME类型的值。因为ODX文档是XML文档，所以可以为它们使用MIME-TYPE的“text/xml”。为了消除不同类型的ODX数据之间的差异，应在目录中使用下图定义的MIME-TYPE- PDX包中使用的MIME-TYPE(非规范):

9.2.2PDX软件包的技术方面(TECHNICAL ASPECTS OF PDX PACKAGE)

一个PDX包被实现为一个ZIP归档文件的扩展名”.pdx”(“包装的 ODX”）。一个PDX包包含一个带有PDX包目录的文件(见上面的例子)，该文件名为“index.xml”。，位于PDX包的内部文件系统层次结构的根目录中。
PDX包是一个自包含的文件，即，PDX包目录只引用PDX包内的文件。因此，PDX包目录中不允许引用外部文件。
一个PDX包支持文件存储在一个层次目录结构。在分层文件存储的情况下，PDX包目录中的所有文件路径都被制定为绝对路径，从PDX包的内部文件系统层次结构的根目录开始(例如，PDX包的内部文件系统层次结构)。“zipdirectory1 / zipdirectory2 / myfile.odx”)。对于java job，需要在PDX文件中包含java包结构产生的完整路径，以保持java作业的不确定性
PDX包中的文件命名约定:文件名通常按照以下方案构建:

文件的类型由MIME-TYPE成员显式指定。因此，不需要符合ODX的工具来将文件扩展名映射到MIME类型。文件扩展名应该作为文件名的一部分处理。
为了在一个单独的ODX容器中存储同一文件的多个版本(在ODX中称为“多版本化”)，每个文件版本都存储在一个单独的ABLOCK中。包含同一文件的修订的所有ABLOCKs共享相同的短名称。

9.3PDX包的使用场景结构(USAGE SCENARIOSSTRUCTURE OF PDX PACKAGE)

9.3.1PDX包在交换过程中(PDX PACKAGE IN THE EXCHANGE PROCESS)

交换ODX数据和其他支持文件是PDX包的主要目的。流程合作伙伴通过包含他想要传输的所有文件并在PDX包目录中描述这些文件来构建PDX包(参见下面的图)。另一个流程合作伙伴接收PDX包并提取文件;PDX包装目录可以提供信息，这些文件必须根据数据交换过程处理。
下图数据交换过程中使用的ODX容器在序列图中说明了数据交换过程中的ODX容器。

完整的数据交换

诊断所需的所有诊断层实例都打包在一个PDX包中。支持文件，例如手册或图像，被添加到PDX包。

增量(部分)数据交换

为了减少传输数据的数量，PDX包中只包括新的或更改的文件。所有未更改的文件从PDX包被省略;它们使用UPD成员设置为“未更改”的ABLOCK在PDX包目录中列出。未使用/重用的文件可以通过同样的方式处理，将UPD设置为未使用/重复使用。
流程合作伙伴必须就一组公共文件达成一致，作为数据交换流程的基础。在数据交换过程开始时，可以通过完整的数据交换建立这样的公共集合。

注意，流程合作伙伴可以*决定他们是否保留自上次数据交换以来没有更改的PDX包目录中的ABLOCKs。包括PDX包目录中所有未更改的ABLOCKs，最终会得到一个到目前为止数据交换过程中涉及的所有文件的列表。这个列表是对数据交换过程的文档化很有用。然而，PDX包目录可能变得非常大，难以维护。

9.3.2配置管理和版本控制(CONFIGURATION MANAGEMENT AND VERSION CONTROL)

9.3.2.1概述

ODX被设计成独立于使用的工具和应用的过程，以支持ODX数据的可交换性。因此，像存储结构或文件修订这样的特定于进程的信息应该保存在ODX数据之外，PDX包目录可以用来将这类信息从一个进程伙伴传输到另一个进程伙伴。一般来说，我们区分了两种类型的修订信息:公共修订信息可以被所有过程合作伙伴使用，而内部修订信息只提供给公司内部使用(详见子条款7.1.2.3)。

9.3.2.2修订历史的交换

在某些情况下，必须交换文件的完整公共修订历史，例如，如果流程合作伙伴第一次得到一个之前已经更改过多次的文件。通过为文件的每个新修订向文件的ABLOCK的ADMIN-DATA添加一个新的DOC-REVISION成员，可以创建文件的公共修订历史。如果ABLOCK包含多个文件，那么所有文件都具有相同的修订历史。为了保存文件的公共修订历史，流程合作伙伴必须保留文件的ABLOCK及其关联的ADMIN-DATA，直到交换下一个文件修订。否则，以前积累的任何修订信息都将丢失。

9.3.2.3CMS版本控制(CMS-SPECIFIC VERSIONING)

如果流程合作伙伴使用CMS管理ODX文件，那么该CMS通常会应用自己的版本控制机制。这包括一个自己的版本控制方案等等。CMSspecific数据存储为内部修订信息在PDX包目录允许准确的版本跟踪独立于公共修订信息。
每当流程合作伙伴的CMS更新其文件的内部修订信息时，一个新的COMPANY-REVISION-INFO成员就会被添加到该文件的最新文档修订中。COMPANY-REVISION-INFO中的COMPANY-REF用于标识创建该内部修订信息的流程合作伙伴。这允许过程合作伙伴将他们特定于cms的修订历史存储在PDX包目录中，而不会相互干扰。
如果需要CMS特定的修订信息，那么应该为PDX包中的每个文件提供一个单独的ABLOCK。通过这种方式，过程合作伙伴可以独立地更新内部修订信息。与公共修订历史一样，流程合作伙伴必须保留ADMIN-DATA。

9.3.2.4使用UPD属性进行配置管理

在将文件导出到PDX包的过程中，容器创建者必须设置在PDX包目录中包含文件的ABLOCK的UPD属性。为了确定文件的正确更新状态，容器创建者将该文件的当前修订与与流程合作伙伴交换的最后一个修订进行比较。修订信息本身可以从文件的ABLOCK中删除，如果它不需要用于其他目的(例如，修订历史)。
在增量数据交换过程中，属性值未更改、未使用、重用和删除意味着在此ABLOCK中列出的文件不需要导出到PDX包，因为文件的当前修订是在以前的数据交换期间转移的。容器创建者可以包括这些文件作为PDX包的接收者的引用。
PDX包的接收者可以使用ABLOCK的UPD成员作为提示如何导入ABLOCK中的文件(例如，导入到CMS)。这是有用的，如果PDX包目录没有提供其他修订信息。
如果PDX包的接收方自上次数据交换后更改了该文件，那么文件的导入可能会导致版本冲突。这样的冲突必须由流程合作伙伴手动解决。