历史
ODS是由ASAM开发的第一个标准之一，达到追溯到1990年初次。该标准的发起者和主要贡献者是宝马，戴姆勒和保时捷。宝马部署了首批用于风洞的ODS服务器安装之一，但其他早期版本的ODS并未获得广泛的市场认可。这改变与ODS 3.0的释放在90的端个。第一批商用设备可从独立供应商处获得。ODS开始被用作欧洲汽车工业试验台的测试数据管理系统。该标准迅速发展并在2003年通过5.0版本进行了多次扩展，例如面向对象的API，基于XML的数据交换格式（ATFX）以及用于NVH和测试床校准的应用程序特定数据模型。2013年版本5.3.0包含一个新的总线数据数据模型。在2017年的主要版本6.0中，ASAM使用超文本传输协议为客户端 - 服务器通信和Google协议缓冲区添加了现代Web服务API，用于数据序列化。新的API显着简化了通过互联网的通信，是实现大数据系统ODS的重要一步。
动机
汽车工业中的测试系统在调试和操作方面是昂贵的。此外，它们产生了大量数据。在早期的90 个测试自动化系统供应商提供他们自己的数据评估工具，作为自动化系统的一部分，在数据存储解决方案上运行 这些系统是专有的，并根据客户需求量身定制。因此，存在许多不同的系统，这些系统大多彼此不兼容。存储的数据通常只能由生成数据的人员访问和理解。具有数据模型，API和数据交换格式的各种工具使得重用测试结果变得非常困难。需要使用包装器API来链接不同的工具，从而导致工具链的不稳定性。数据转换器必须将数据转换为不同的格式，这可能会导致意外的修改，重新解释或丢失数据。
除了这些问题，最关键的问题是数据模糊。如果数据的命名，范围和语义没有很好地定义，那么用户就不能信任数据甚至误解数据。例如，在NVH应用区域中，响度水平（phon）的测量取决于声压级和频率的选择。响度水平测量可以遵循标准化轮廓以获得相等的响度，并且可以使用具有特定阈值参数的滤波器。在NVH专家可以正确解释响度测量数据之前，需要知道这样的元数据。此外，他们需要有关测试的附带数据，例如麦克风的位置和类型。测试数据的创建者通常使用测量通道的名称来描述这样的伴随数据。助记符，缩写和字母代码用于通过测量通道的名称传达元信息。如果这些代码没有明确和系统地记录，那么这些测试数据的消费者必须推测这些名称的含义。在很长一段时间内，这种名称编码方案引起了巴比伦维度的混乱。其他错误来源是使用不同的数据类型，物理单位或缩放公式，这进一步导致对测量值的误解。所有这些潜在的陷阱都可能导致代价高昂的重新测试，或者甚至更糟糕的回收已发布产品。在很长一段时间内，这种名称编码方案引起了巴比伦维度的混乱。其他错误来源是使用不同的数据类型，物理单位或缩放公式，这进一步导致对测量值的误解。所有这些潜在的陷阱都可能导致代价高昂的重新测试，或者甚至更糟糕的回收已发布产品。在很长一段时间内，这种名称编码方案引起了巴比伦维度的混乱。其他错误来源是使用不同的数据类型，物理单位或缩放公式，这进一步导致对测量值的误解。所有这些潜在的陷阱都可能导致代价高昂的重新测试，或者甚至更糟糕的回收已发布产品。
ODS通过具有明确定义的语义的数据模型的规范解决了数据解释的问题。这样可以避免对现有测试数据进行冗余测试和误解。此外，在一个数据模型中，相同的测试数据使用相同的标签，数据类型，单位和转换方法。几乎没有误解的余地。标准化的API和数据交换文件格式进一步避免了上述包装API和数据转换器，从而节省了开发成本和由于不稳定的工具链和降低的数据质量而导致的时间损失。
标准化测试数据库还有许多其他优点。如果测试床操作员和开发专家有足够的数据来停止进一步测试，他们可以更容易地确定。此外，由于原型越来越稀缺并且测试台被预订了几个月，测试台的用户可以提前测试数据，并在以后需要时轻松检索。数据可供跨职能团队使用，例如NVH和发动机任务组团队，他们必须联合调查生产车辆中意外高噪声水平的现场问题。ODS服务器通过跨部门边界提供数据来促进协作，并允许不同专业的专家对其进行明确的解释。
应用领域
ODS标准侧重于持久存储和检索数据。它广泛涵盖了测试领域的所有用例，主要与测试自动化系统结合使用。ODS服务器首先用于底盘测功机，动力总成测功机，NVH测试实验室和碰撞测试实验室。
该标准允许创建特定于应用程序的数据模型，从而可以涵盖广泛的测试应用程序。ODS服务器的典型应用领域是制动器，减震器，燃料喷射器，催化转换器和其他汽车部件的部件试验台。质量保证测试台使用ODS服务器存储原始数据和分类数据。此外，ODS服务器从气候室，风洞，压力和耐久性试验台，水力脉冲测试系统，试验地面车辆测试和公路上的车队测试中捕获测量数据。最近，ODS已被用于测试替代推进系统的部件，例如电动机，电池和电力电子设备的测试。ODS的另一个优势是能够将测试数据与UUT数据（被测单元）相结合，
大型OEM使用企业范围的ODS数据库，例如，一个ODS服务器系统用于整个引擎开发区域。可以独立于谁生成数据来检索数据。在某些地区，原始数据量太大，无法由人类查看和评估。自动客户端应用程序可以浏览数据模型，检索数据，评估结果，生成测试报告和归档数据，而无需人工干预。通用ODS客户端可以使用来自不同供应商的ODS服务器，而无需进行大量集成。
ODS还用于制造商/供应商关系中的测试数据交换。这通常需要通过文件交换数据。可以以符合XML的文件格式导出ODS数据库的内容或部分内容。格式包含ODS数据模型和测试数据。文件的接收者可以通过XML导入器导入数据，并且能够正确地理解和存储他们自己的数据处理工具或数据库中的数据。
技术内容
数据模型
ODS中的数据模型提供存储位置和数据含义。后者非常重要。如果已知以下信息，则只能正确理解和应用测试数据（→每个问题下面给出相应的基本模型元素）：
- 我的数据在哪里？
→AoMeasurement - 测试了什么？
→AoUnitUnderTest - 使用了什么测试设备？
→AoTestEquipment - 进行了哪项测试？
→AoTestSequence - 测试的目的是什么？
→AoAny - 哪个人参加了考试？
→AoUser - 测试是在什么时候进行的？
→AoMeasurement - measurement_start，measurement_end
从ODS服务器查询测试数据的用户能够获得这些问题的答案。此先决条件是一个有意义且定义明确的应用程序模型。虽然这种应用程序模型的定义是用户在设置ODS服务器时的责任，但ODS标准为此作业提供了几种帮助：
- 基础模型：应用程序模型的基础和参考。
- 预定义的应用程序模型：为客户特定的应用程序模型的定义提供一个起点。给出测试对象几何，NVH测试，测试台校准数据，总线数据，测试工作流程。
基础模型
基本模型可以视为测试数据的粗略数据分类。基本模型的元素在语法和语义方面是明确定义的。元素的语法定义确保所有ODS客户端都可以读取它们。元素的语义定义确保每个客户端以相同的方式理解它们。
这将通过一个例子来说明： AoMeasurementQuantity 是一个基本元素，它表示在测量矩阵中组织为一列的测量物理量的值。这是AoMeasurementQuantity的“含义”或“语义” ，允许客户正确解释和分类数据。AoMeasurementQuantity 还有其他属性，用于定义其数据的语法。例如，属性数据类型 描述测量值的位级存储格式（例如DT_BOOLEAN，DT_BYTE或DT_FLOAT等），属性 维度描述矩阵列中的值的数量。这是“格式”或“语法”，允许客户端正确读取和处理数据。
此外，基本模型描述了元素之间的关系。例如，AoMeasurementQuantity引用AoPhysicalDimension，它是表示有关数量类型（例如力或温度）的信息的基本元素。它还引用了 AoUnit，它是表示单元信息的基本元素，例如Newton或Kelvin。有了这些信息，客户现在可以很好地了解如何解释和处理从ODS服务器收到的数据。例如，客户端现在知道如何正确转换数据以使物理单位匹配（防止将摄氏度与开尔文进行比较）并对相同类型的数据进行分类（防止在同一图表中显示温度数据和强制数据）。
下表简要介绍了基本模型的元素。
| 元件 | 描述 |
|---|---|
| AoTest AoSubTest AoMeasurement |
用于组织测量和相应的输入/输出数据。 |
| AoSubmatrix AoLocalColumn |
是存储测试结果的基本元素。 |
| AoQuantity AoQuantityGroup |
用于保存可能与数据库中保留的任何或所有测试相关的物理量的信息。 |
| AoMeasurementQuantity | 表示测量中使用的数量。 |
| AoUnit AoUnitGroup AoPhysicalDimension |
用于保存结果值（普通数字）与相应单位之间关系的信息，从而允许正确的算术运算或关系运算。 |
| AoUnitUnderTest AoUnitUnderTestPart |
包含有关已测试内容的信息。 |
| AoTestEquipment AoTestEquipmentPart |
包含有关使用了哪些设备的信息。 |
| AoTestSequence AoTestSequencePart |
包含有关在测试期间处理了哪些步骤序列的信息。 |
| AoTestDevice | 包含有关使用哪个测试设备的信息。 |
| AoUser AoUserGroup |
是否用于处理安全方面的基本元素。 |
| AoLog | 用于记录目的。 |
| AoParameter AoParameterSet |
可以用于例如通过仅存储几个元素使用的信息来避免冗余。 |
| AoNameMap，AoAttributeMap | 保存应用程序元素的别名，例如，用于不同语言的名称。指定应用程序属性的别名。 |
| AoAny | 是一个不具有特定含义的基本元素，可用于存储不符合其他基本元素含义的信息。 |
实际上，基本模型不直接用作数据库的模型。对于此目的，它通常过于通用。但是，基本模型用作父项以派生特定的应用程序模型。应用程序模型的元素始终具有对基本模型元素的引用，从而赋予其基本模型元素的含义。
应用模型
应用模型涵盖特定应用领域，如NVH测试或发动机测试。它们来自基本模型并定义，哪些基本模型元素确实在数据库中使用。应用程序模型的每个元素引用定义良好的基本模型的元素，从而为数据添加含义。
因此，在ODS中构建应用程序模型意味着将特定于应用程序的元素映射到基本模型的元素。例如，“发动机”试验台测试具有“进气歧管”，“活塞”和“发动机缸体”部件的发动机。我们将“引擎”映射到基本模型元素 AoUnitUnderTest ，并将组件“进气歧管”，“活塞”和“引擎块”映射到 AoUnitUnderTestPart。此外，我们希望测量每个组件的温度并将数据存储在ODS数据库中。因此，我们将元素“进气歧管”，“活塞”和“发动机缸体”链接到“测量”（它映射到基本模型元素： AoMeasurement）。“ ）。“TemperatureInstantaneous”应引用“Kelvin”（基本模型元素： AoUnit），其引用“温度”（映射到基本模型元素： AoPhysicalDimension）。
查询应用程序模型的客户端应用程序仍然可以通过与基本模型的关系来理解特定应用程序数据模型元素的含义。这允许符合ODS标准的数据库的用户为其特定的测试用例创建定制的应用程序数据模型，并且客户端应用程序仍然能够正确处理来自此类定制数据库的数据，因为所引用的基础具有明确定义的语法和语义模型元素。
除了那些基本关系之外，应用程序模型的设计者可以引入应用程序元素之间的新关系。他还可以添加特定于其测试用例的属性。因此，应用程序模型可以具有附加关系属性，这些属性在基础模型中不存在。对于客户来说，它们仍然是可以理解的，因为它们存在于元素的上下文中，元素始终与基本模型有关。
继续上面的示例，我们想要记录被测引擎所属的客户。因此，我们添加对“Engine”的引用，该引用指向元素“Customer”（映射到基本模型元素： AoUser）。基本模型中不存在此关系。我们可以进一步向我们的应用模型元素“进气歧管”添加属性“重量”和“材料”，并对其他组件“活塞”和“发动机缸体”执行相同的操作。这允许将重量和材料信息存储到被测单元。
ODS标准包含五个针对特定应用领域的预先指定的应用模型：
- 测试对象几何
- NVH测试
- 试验台校准数据
- 公交数据
- 测试工作流程
ISO 22240规定了第六个型号，其名称为“车辆安全信息模型”（VSIM），它标准化了车辆安全测试的数据存储。该型号符合ODS标准，但由ISO拥有，因此不包含在ASAM ODS标准中。
使用这样的应用程序模型保证客户端以相同的方式以相同的数据格式存储相同的信息，因此存储的信息的含义通常可以由不同的客户端理解。预先指定的应用程序模型是随时可用的，但是，用户可以通过添加特定于公司的项目来定制它们以满足其需求。
应用程序模型仅提供有关要存储和检索的数据结构的元信息。它们需要在ODS服务器上实例化为数据库。这允许存储和检索实际数据，即客户端应用程序然后可以创建应用程序模型元素的特定实例并开始在其属性中存储值。此外，客户端甚至可以在实例化数据模型中的两个实例之间创建新的实例属性和新关系，这些实例在底层应用程序模型中不存在。
物理数据库模型
ODS标准规定了如何最初构建数据库以便以兼容的方式物理存储数据。该标准侧重于关系数据库，因为这是业界最常用的数据库技术。
使用关系数据库存储信息需要指定数据库中必须有哪些表，需要具有哪些列，哪些表条目必须是唯一的（因为它们用作键）等等。符合ODS标准的数据库清楚地区分了有关应用程序模型的元信息和另一方的实际值。它们存储在不同的表中。
有关应用程序模型的元信息存储在三个静态表中。
| 表 | 内容 |
|---|---|
| SVCENT：应用程序模型元素表 | 为每个元素保留唯一ID，名称，对基本模型元素的引用以及存储应用程序元素实例的表的名称。 |
| SVCATTR：应用程序模型属性表 | 包含所有应用程序元素的应用程序属性列表以及所有单向[1，n]应用程序关系。对于属性，该表允许按名称标识属性，它们属于哪个应用程序模型元素，以及（如果可用）它们属于哪个基本模型元素。对于关系，该表包含目标元素的ID。此外，该表包含属性值的数据类型和存储属性值的列名。 |
| SVCREF：应用程序关系表 | 包含所有双向[n，m]应用程序关系。 |
应用程序模型实例的值存储在实例表中。
| 表 | 内容 |
|---|---|
| 包含实例属性的表 | 包含添加到实例的属性和关系，因此在应用程序模型中不存在。 |
| 包含双向[n，m]相关类型的实例关系的表 | 包含将元素实例相互关联的矩阵。 |
| 包含实例及其属性的表 | 由SVCENT和SVCATTR引用，并包含每个属性的实际值。 |
| 包含安全信息的表 | 包含用于限制对实例，元素和属性的访问以及提供访问控制模板的表。 |
been
该标准定义了三种不同的API来访问数据库。它们从服务器上的数据库的实际实现中抽象客户端访问。此外，API命令允许检索实际测试数据并访问关于应用程序模型的元信息。元信息允许客户端解释和理解应用程序模型，从而允许它使用不同的ASAM ODS数据模型。
历史上第一个ASAM ODS接口规范使用RPC（远程过程调用），而今天的一些实现仍然基于RPC-API。基于CORBA体系结构（公共对象请求代理体系结构）的面向对象的OO-API继承了RPC-API。出于兼容性原因，两个旧API仍包含在ASAM ODS中。
从版本6.0.0开始，ODS包含使用超文本传输协议的Web服务API。新的HTTP-API还使用Google Protocol Buffers规范来序列化应用程序数据。HTTP-API包括OO-API和RPC-API的大部分功能，并且能够在典型的通信场景中替换它。新的API显着简化了通过Internet进行的客户端 - 服务器通信，是实现大数据系统ODS的重要一步。访问ASAM ODS的推荐方法是使用HTTP-API。
HTTP-API的主要特征是：
- 基于REST架构风格
- 符合W3C HTTP 1.0标准
- 通过Google Protocol Buffers 3.0（proto3）进行二进制和JSON数据序列化
- 更改事件的W3C SSE通知
- 可用于反向代理
HTTP-API由30种方法组成，用于在客户端应用程序和ODS服务器之间建立基于Web服务的请求 - 响应类型的通信。大多数方法都使用POST命令，因为此命令自HTTP 1.0以来就已存在，甚至更老的网络基础结构也支持此命令。此外，POST命令允许以proto3格式有效传输方法参数。API的三种方法使用HTTP的DELETE和GET命令。
API方法的主体可以有两种替代内容类型，用于以序列化格式传输结构化数据：
- Proto3：推荐且最有效的数据序列化格式
- JSON：protobuf消息的JSON表示
客户端和服务器之间的每个通信会话通过连接标识符（conI）来识别，该连接标识符由服务器生成，作为对“POST {baseURI} / ods”命令的响应。所有后续命令都包含连接标识符。
HTTP-API方法具有基本结构“HTTP-Command”，“Path”和“Action”。Action包含ASAM ODS中指定的实际功能。API定义了常用功能的二十四种标准方法，例如打开和关闭与服务器的连接，读/写/修改实例数据（即元数据和测量数据），修改应用程序模型，客户端处理的功能交易和其他功能。事务由一系列动作组成，这些动作就像它们只是一个动作一样，从而确保数据的一致性。如果一个事务的操作没有完全完成，则可以回滚服务器，确保在事务开始之前的原始条件。下表列出了所有标准方法，并提供了Action的简要说明。
| HTTP命令 | 路径 | 行动 | 描述 |
|---|---|---|---|
| POST | 基本URI {} / | ODS | 请求连接ID以在客户端和服务器之间建立通信会话。 |
| 删除 | 基本URI {} / | ODS / CONI {} | 关闭会话。 |
| POST | 基本URI {} / ODS / CONI {} / | 背景阅读 | 检索全部或部分上下文变量（指定服务器设置的名称 - 值对）。 |
| POST | 基本URI {} / ODS / CONI {} / | 上下文更新 | 设置一个或多个上下文变量的值。 |
| POST | 基本URI {} / ODS / CONI {} / | 数据读取 | 通过本地列的“值”，“标志”和“generation_parameters”读取实例数据，例如属性值，关系和测量数据。 |
| POST | 基本URI {} / ODS / CONI {} / | valuematrix阅读 | 读取完整测量或其子集的质量数据。 |
| POST | 基本URI {} / ODS / CONI {} / | 数据创建 | 创建新实例，设置属性值和关系。 |
| POST | 基本URI {} / ODS / CONI {} / | 数据更新 | 修改新实例，设置属性值和关系，写入海量数据。 |
| POST | 基本URI {} / ODS / CONI {} / | 数据拷贝 | 复制实例。 |
| POST | 基本URI {} / ODS / CONI {} / | 数据删除 | 删除一个或多个实例。 |
| POST | 基本URI {} / ODS / CONI {} / | NM-关系读 | 通过n：m关系获取与给定实例相关的所有实例的列表。 |
| POST | 基本URI {} / ODS / CONI {} / | NM-关系写 | 设置，添加或删除实例与其他实例的n：m关系。 |
| POST | 基本URI {} / ODS / CONI {} / | 交易创建 | 此方法启动事务。 |
| POST | 基本URI {} / ODS / CONI {} / | 交易提交 | 此方法用于向ODS服务器发出信号，表明当前事务中的所有活动都已提交，并且客户端希望服务器在ODS数据存储中使所有结果更改持久化。 |
| POST | 基本URI {} / ODS / CONI {} / | 交易中止 | 如果客户希望回滚当前事务中的所有活动，则可以由客户端调用此方法。 |
| POST | 基本URI {} / ODS / CONI {} / | 模型读 | 此方法检索当前存储在ODS服务器上的应用程序模型。 |
| POST | 基本URI {} / ODS / CONI {} / | 模型删除 | 此方法允许完全删除应用程序元素或从应用程序元素或两个应用程序元素之间的应用程序关系中删除应用程 |
| POST | 基本URI {} / ODS / CONI {} / | 模型更新 | 此方法允许在ODS服务器上创建新的并修改现有应用程序模型及其部件。 |
| POST | 基本URI {} / ODS / CONI {} / | 模型检查 | 此方法允许确定当前在ODS服务器上保存的应用程序模型是否符合ASAM ODS的规则。 |
| POST | 基本URI {} / ODS / CONI {} / | basemodel阅读 | 此方法允许从ODS服务器检索ASAM ODS基本模型。 |
| POST | 基本URI {} / ODS / CONI {} / | Asampth创建 | 该方法可用于确定应用程序元素的特定实例的ASAM路径。 |
| POST | 基本URI {} / ODS / CONI {} / | Asampth排解 | 如果只知道其ASAM路径，则此方法允许检索应用程序元素的实例。 |
| POST | 基本URI {} / ODS / CONI {} / | 文件访问 | 此方法可用于检索用于访问文件，blob和字节流的URI。 |
| POST | 基本URI {} / ODS / CONI {} / | 文件控制 | 此方法可用于控制文件或将其从ODS服务器的控制中删除。 |
该标准还定义了六种特殊方法来注册客户端以从服务器接收事件通知和安全管理。如果出现以下情况，服
- 已插入新的应用程序元素实例（新）
- 已修改应用程序元素的现有实例（修改）
- 已删除应用程序元素的现有实例（DELETE）
- 应用程序模型已被修改（MODEL）
- 修改了消耗臭氧层物质安全的任何设置（安全）
服务器可以通过客户端生成的唯一接收者标识符{recI}来标识特定客户端。下表列出了所有特殊方法，并提供了Action的简要说明。
| HTTP命令 | 路径 | 行动 | 描述 |
|---|---|---|---|
| POST | 基本URI {} / ODS / CONI {} / | 安全读 | 该方法允许将关于ACL条目（访问控制列表）的信息检索到应用程序元素，或者检索应用程序元素的一个或多个属性或关系或应用程序元素的一个或多个实例。 |
| POST | 基本URI {} / ODS / CONI {} / | 安全更新 | 此方法允许将ACL条目附加到应用程序元素，或应用程序元素的一个或多个属性或关系或应用程序元素的一个或多个实例，或修改或删除现有的ACL条目。 |
| POST | 基本URI {} / ODS / CONI {} / | 初始权利 | 此方法允许设置，删除或修改一组特定于会话的ACL模板。 |
| POST | 基本URI {} / | 事件/ {} RECI | 此方法允许客户端向ODS服务器注册一组事件。 |
| 删除 | 基本URI {} / | 事件/ {} RECI | 此方法允许客户端从ODS服务器取消注册。 |
| 得到 | 基本URI {} / | 事件/ {} RECI | 此方法允许POOL模式客户端从ODS服务器检索一组事件。一旦客户端注册为ODS服务器上的事件接收器，该服务器就会收集所有匹配的事件并将它们存储在特定于接收器的持久事件池中。每次客户端调用此方法并通过唯一{recI}引用接收器时，ODS服务器将检索当前在该接收器的事件池中的所有事件，并在响应主体中返回它们。 |
ODS提供了更多功能，使客户端 - 服务器访问高效安全：
- 混合模式服务器：ODS使用ASAM MDF二进制文件格式等外部文件来存储海量数据。不是将这些数据导入数据库，而是在那里引用外部文件。通过API完全抽象对数据的访问，即客户端访问外部文件中的数据的方式与访问数据库内部存储的数据的方式完全相同。这使得存储大量数据对客户端透明，并且对服务器非常有效。
- 查询：客户端请求可以通过一组关系（'>'，'<'，'='等）和逻辑（'AND'，'OR'，'NOT'等）运算符缩小，从而简化访问大量数据。
文件描述格式
该标准定义了ATF格式（ASAM传输格式），这是一种基于文本的描述格式，用于工具之间基于文件的数据交换。ATF允许传输完整的应用程序模型以及具有其属性，关系和值的实例。
该规范允许将信息拆分为一组通过包含机制链接在一起的单个文件。此外，文件格式允许以二进制格式传输海量数据，例如通过ASAM MDF。否则这些数据将出现在AoLocalColumn中。该标准不是将大量数据作为文本存储在ATF中，而是非常有效，而是允许在ATF中描述数据的结构，然后包含对MDF文件的引用。因此，ATF和二进制文件（如MDF / MD4）可用于在不同的ODS应用程序之间非常有效地传输大量数据。
ATF描述格式有两种变体。经典的ATF / CLA格式是一种非基于XML的描述格式，由于遗留原因仍然保留在标准中，但预计在未来的标准修订版中不会更新。相同的信息也可以通过较新的ATF / XML描述格式传输，该格式最好用于新工具，并将在未来的ODS标准修订版中进一步开发。
ATF / CLA使用纯ASCII文本，并且仍然受到市场上大多数可用的ODS工具的支持。它有一个简单的五层结构：
- 版本：提供有关ATF / CLA版本的信息。
- 文件（可选）：提供一起构建完整ATF / CLA文件的物理文件列表。
- Applelem：是应用程序模型元素的描述，可以为将要由此ATF / CLA文件传输的每个元素重复。
- Instelem（可选）：是应用程序模型元素实例的描述，可以对此ATF / CLA文件传输的每个实例重复。
- Endfile：标记ATF文件的结尾。
ATF / XML使用UTF8字符集。与ATF / CLA相比，XML允许更详细地自动验证文件内容。此外，市场上有大量用于查看，编辑和处理XML文件的XML工具。此外，ATF / XML由五个顶级元素组成：
- 文档：包含有关文件来源和一些描述文本的一般信息。
- BaseModelVersion：提供此文件中用于应用程序模型的基本模型的ODS版本号。
- 文件：包含二进制数据的外部文件列表。
- ApplicationModel：包含特定于应用程序的数据模型的描述，包括元素及其相互之间的关系。
- InstanceData：包含应用程序模型的实际值。也可能包含对包含值的外部二进制文件的引用。
优点和优势
消耗臭氧层物质标准的主要好处是摆脱数据库，API和描述格式可能具有的多样性，并将这些变化的最佳行业实践与一种标准相结合。ODS的主要优点之一是所有用户都能安全地理解测量数据。这是通过语义定义良好的数据模型实现的。测量数据通过元数据进行修改，这些元数据包括其来源，传感器，传感器位置，测量方法，环境条件以及数据采集环境的其他描述性数据。此数据可以与UUT的详细信息相关联，例如版本和配置。即使数据的用户可能在测试期间不存在，这可能发生在半年前，并且UUT不再存在，测试数据仍然可以理解并且可以使用。测试不必重复，项目可以继续进行而不会延迟。
对数据的访问完全从其来源中抽象出来，例如，它独立于设计和执行测试的人员，独立于用于生成测量值的设备，独立于ODS服务器供应商并且独立于服务器和客户端之间的IT和通信基础设施。ODS建立了一个真正的，企业化的数据存储和检索基础设施。
另一个重要方面是根据法律要求对数据进行长期存档的能力。ASAM ODS通过标准化技术确保长期稳定性。这通常被OEM，认证机构或法律机构接受为证明。
此外，长期归档可能变得非常昂贵。例如，现代发动机试验台每天能够产生数TB的数据。但是，并非所有数据都在以后使用。ODS允许跟踪数据是否实际访问过以及访问过谁。这允许仅将数据移动到相关人员或开发工具实际使用的长期存档。
行业采用
如今，ODS通常是企业级存储和检索测试相关数据的综合系统的一部分。该标准被德国原始设备制造商广泛使用，包括启动该标准的宝马，戴姆勒和保时捷。奥迪于1999年开始实施基于ASAM ODS的“测量数据管理”项目，并在2008年之前将系统软件的主要部分移至开源项目。截至2012年，有30家公司参与该项目。
自OS 3.0以来，一些ODS服务器供应商已经发展并提供COTS产品。存在工程服务提供商和系统集成商来建立全面的数据库解决方案，这些解决方案可以独立工作，也可以与其中一个ODS服务器供应商建立战略联盟。一些服务提供商专门针对特定应用领域，例如NVH。标准和可用的工具可以被认为是成熟和稳定的。
欧洲和北美的消耗臭氧层物质的采用率不断增加。自2011年以来，ASAM支持美国的一个区域项目组，该项目组正在开发一种用于对ODS服务器进行Web访问的标准。这项工作将进一步利用消耗臭氧层物质在北美的地位。
可交付成果清单
该标准包括以下可交付成果：
- 标准文件
- XML模式文件
- EXPRESS模式文件
- Google Protocol Buffers定义文件
- IDL接口定义文件
- ONC RPC接口定义文件
- C ++，C＃，Java和Python中的HTTP-API示例代码
- ATF和ATFX示例文件
下载
| Example_ATF_CLA.atf | 经典非XML格式的ATF文件示例。 |
| Example_ATF_XML.atfx | XML格式的ATF文件示例。 |
| Example_Geometry.atfx | XML格式的ATF文件示例，包含来自测试对象几何应用程序模型的数据。 |
进一步阅读
- 基于Petri网并由ASAM ODS存储的汽车测试数据分析工作流程; 雷纳巴茨; IEEE / ICIT; 2009年; ISBN：9781424435074
- 对汽车测试和数据分析中基于工作流程的信息管理的贡献; 雷纳巴茨; IEEE / ICIT; 2010; ISBN：9781424456963
外部链接
- ASAM ODS 5.3 基本模型的描述。
- 开源测量数据管理项目 OpenMDM。
转自：https://www.asam.net/standards/detail/ods/wiki/
参考：https://www.highqsoft.com/asam-ods-solutions/
工具下载:https://www.highqsoft.de/highqsoft.serveftp.net/download/downloads.html
*ASAM ODS 5.3 JAVA 类库
https://pan.baidu.com/s/1J3CwzAJvUdAxtFIQwz4yQw