标签: autosar

随着整车功能的不断演进，车上各类用电设备（控制器、执行机构、感知设备等）的用电功耗越来越大，为了降低整车能耗，国内外很多OEM及Tire1都在考虑相关的机制及方案，其中PN局部网络管理机制，以其简单、灵活的特点获得众多落地应用。 基于AUTOSAR方案的局部网络管理机制，通常简称为AUTOSAR PN（Partial Network），局部网络管理本质上是要实现只让需要支撑功能实现的控制器工作，其他控制器保持在低功耗状态。AUTOSAR PN是通过NM报文（NMPDU）的方式来达到此目标，NMPDU的典型格式如下表所示。 PN开发流程 当前OEM的车型平台大多为迭代开发，依托现有平台增加PN通常是较快速的方案。所以相较于复杂、全面的AUTOSAR正向PN开发方法论，OEM更多采用逆向的开发方式。逆向的PN开发流程通过分析当前现状来完成PN的开发，选取整车改动较小的方案推进，整体方案具备轻量化的优势，开发周期短，过程交互简单。 本文重点介绍下逆向开发的关键步骤： · 第一步：PN场景设计及梳理 结合整车的功能列表、用车人典型的用车场景及OEM考虑的其他场景，确定车型需开发的场景范围，比如全部唤醒、防盗、远控、充电等。场景开发应考虑场景触发的频率、给用车客户带来的收益以及OEM本身的收益。 · 第二步：PN开发基础原则确定 结合当前量产车型的EE架构，确定一个基础的PN开发规则，比如开发全局PN还是部分PN以及基础的功能链路，形成本次开发的基础原则文件，输出到后续步骤。 · 第三步：PN场景功能链路梳理及分析 根据确定的功能场景及PN开发基础原则及整车所有的子系统功能规范输入，梳理场景触发后的完整功能链路，这其中要切实考虑链路中涉及到的ECU、关键信号值的变化、功能执行前提条件、存储值/实时值需求、以太网接口调用需求、供电需求、网段需求等关键信息，通过细致的方案设计来避免场景上的链路缺失和场景间的关联；另外还需要考虑休眠释放条件，防止场景的休眠异常。 · 第四步：网络线的所有工作 在功能线开发的同时，网络线可同步开发相关的PN需求规范及休眠唤醒策略；在制定好PN场景后，可以开始NMPDU的制定、车型网络相关方案的制定；PN的通信设计和诊断设计应结合PN开发的基础原则及网络需求规范开展，比如通信设计是否要考虑应用报文与场景的关联、诊断设计是否要考虑全工况下的DTC记录等。 · 第五步：功能及网络的测试验证 结合上述开发的输入，开展测试工作以验证符合性。 以上的每个步骤都需要形成相关的输入输出来保证整个方案体系的一致性，如相关模板、PN开发基础原则、场景功能链路方案、控制器PN方案、网络需求规范、休眠唤醒条件、测试规范/用例、测试脚本等等。此外，控制器的实现如基于AUTOSAR CP协议栈，需要同步考虑功能需求与BSW的Mapping关系，保证功能需求的落地可行性。 下图即为同一个网段下不同控制器的唤醒示意。当某PN场景触发后，控制器置位相关的PN信息，其他控制器根据置位的PN信息来决定是否与自身相关，如相关则唤醒以支撑功能实现，如不相关则维持在低功耗状态。 注：本文集中在CAN总线的局部网络管理。 · 硬件支持 实现PN的控制器应结合实际方案决定是否需要在硬件层面支持报文过滤功能，常见的支持硬件过滤功能的CAN收发器为NXP TJA1145，其在硬件层面设计了符合ISO 11898-2中Selective Wake-up的特性，可过滤自身关心的报文。通过使用此类收发器，可以达成控制器的功耗控制，否则无法实现功耗上的按需控制。 · 软件支持 PN功能的实现，使用AUTOSAR CP协议栈是非常方便的，与常规的NM相比，PN软件模块主要集中在BSW的ComM和CanNM中，ComM负责PNC状态机的监控及跳转，CanNM配合ComM负责NMPDU和CAN通道的维持和释放，基于AUTOSAR软件配置工具可以快速切换为支持PN。如使用手写代码，鉴于PN状态机的规则相对简单易懂，也可以方便的实现此类功能。 经纬恒润 依托自身丰富的技术积淀，结合架构开发、总线开发、嵌入式开发等综合经验，对整车功能进行分析与梳理，形成了一套逻辑严密、场景适应性强的从场景-功能-控制器-自动化测试系统的综合解决方案框架。该方案包含了对市场需求的深刻理解，已应用于多家OEM的实际车型开发中。 基于此综合解决方案，针对OEM不同车型的独特性、现有功能配置及软硬件实际情况，细心规划并执行定制化实施方案，赢得了合作伙伴的广泛信赖与深度认可。 了解更多 请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

Vehicle OS软件平台的价值演变 在智能汽车快速迭代的趋势之下，广义操作系统Vehicle OS应运而生，针对应用软件开发周期缩短和底层硬件迭代速度加快的背景，Vehicle OS将应用软件开发和底层硬件迭代解耦。它降低了迭代工作量并节约成本，用标准化的接口来助力软件定义汽车时代下的敏捷开发。 通过标准化统一车辆的接口，减少车内软件的变量，助力工作量继承和协作研发。Vehicle OS的变量和版本管理可降低维护复杂性，实现软件生命周期和车辆生命周期的分离。让软件在跨车型平台内可持续运行，Vehicle OS中间件的兼容性可以帮助您实现规模经济。同时，Vehicle OS简化了基础软件的开发工作，例如通讯矩阵变更调整时可以借助工具链自动生成符合AUTOSAR规范的基础软件，从而加速完成迭代。 经纬恒润 Vehicle OS软件平台解决方案 经纬恒润作为Vehicle OS软件平台解决方案提供商，为软件定义汽车时代下的敏捷开发提出了INTEWORK-EAS（ECU AUTOSAR Software，以下简称EAS）解决方案。INTEWORK-EAS是由经纬恒润自主研发，符合AUTOSAR标准以及各主流OEM定制化标准的软件产品。解决方案涵盖了嵌入式标准软件、AUTOSAR工具链、集成服务和实用培训等各个方面的内容，旨在为国内及国际的OEM和供应商提供稳定可靠、便捷易用的AUTOSAR平台。 INTEWORK-EAS针对MCU端和MPU端不同场景分为AUTOSAR CP和AP平台解决方案。经纬恒润按照AUTOSAR标准开发了EAS.CP和EAS.AP产品，具备多项资质认证。同时随着OEM提出的车端信息安全需求，经纬恒润提供多层次的信息安全解决方案。支持安全启动、安全访问、安全升级、安全存储等不同安全应用场景方案的同时提供硬件层如HSM固件开发等业务。 Vehicle OS 工具链 经纬恒润 从 2008 年开始国产化软件自研工作，逐步积累了 AUTOSAR/ISO/ASAM/SAE 等汽车电子国际相关行业标准的实现，并开发了嵌入式、总线监控仿真、诊断、刷写和测试平台。具备丰富的嵌入式及应用软件开发经验，产品稳定可靠，易于扩展和升级，如图所示为相关产品架构图： 经纬恒润 AUTOSAR 解决方案包含的工具链分为AP及CP两部分。CP工具链包含 CP.SWCDesigner 及 CP.Configurator，AP工具链包含AP.Assistor。工具链整体支持 CICD 流程，能够加快软件开发、集成及交付速度，提高代码质量，并通过自动化测试和部署实现更快的问题修复和更短的反馈循环，满足客户对快速、稳定的产品开发迭代需求。结合其他经纬恒润自研的INTEWORK工具，可以形成一套完整展现 AUTOSAR 方法论的工具链，可以提供方便、高效的应用层 SWC 设计和底层 BSW 配置，从而提高开发效率、代码复用性和软件可靠性。 给客户带来的价值 助力软件安全、可靠、高效的开发： 从架构到ECU开发统一开发流程和交互语言，加速车型开发，缩短整车开发周期 安全可靠软件平台提高产品可靠性，降低代码缺陷率和开发风险 统一软件平台降低软件系统开发和维护的复杂性，进而降低架构集中化带来的系统复杂性 了解更多：请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

随着汽车智能化、网联化以及汽车电子电气架构发展，汽车功能需求越发复杂，越来越多的零部件及 OEM 采用性能更高的硬件平台以及多元化的软件架构。尤其是对于高级自动驾驶，智能座舱、高性能（异构）计算平台来说，仅依靠AUTOSAR CP软件架构已经无法满足需求。 2017年，AUTOSAR推出了Adaptive Platform（以下简称“AP”）来应对这一变化。AUTOSAR AP定义了标准的MPU域中间件软件架构及方法论，更好支撑高性能域控制器的应用功能实现，满足域控制器对 MPU域以太网通讯、诊断、存储、健康管理、安装更新、功能安全和信息安全等需求。 面向 MPU 端的 AUTOSAR 产品——EAS.AP 经纬恒润自主研发的Adaptive AUTOSAR平台产品（以下简称EAS.AP）， 遵循AUTOSAR Adaptive R19-11和R22-11规范， 使用C++11、C++17语言开发。可通过极易上手的自研工具配置，实现AUTOSAR AP协议栈代码快速生成。 在标准功能基础上，拓展实现了DoIP Client和UDS Router等功能。 · 软件组件 图1 经纬恒润AP软件架构 · 工具链 除软件组件外，EAS.AP解决方案包含完整的AP工具链，运行于PC机上，实现AUTOSAR组件软件的设计、配置与生成功能。工具链示意图如图2所示： 图2 EAS.AP工具链方案示意图 AP.Assistor 是一套配合经纬恒润 AUTOSAR 平台产品EAP.AP使用的工具产品，实现AUTOSAR AP软件的设计、配置及生成功能。通过AP.Assistor工具可对服务接口、进程、软件集群、以太网通道等信息进行快速设计部署，指导从0创建工程。 · 无缝兼容上下游工具，兼容主流架构设计、数据库编辑和模型开发工具，形成工具链闭环 · 兼容多种数据库：支持ARXML、ODX/PDX等标准数据库文件，向下兼容R19-03对应ARXML文件 · 根据配置生成代码与核心库交叉编译，具备良好的报错及提醒功能 · 根据配置生成manifest文件，用于APP程序及核心程序在运行时读取，可实现动态部署 · 集成C++编译环境，支持从配置到编译一站式服务，无需切换工具 经纬恒润EAS.AP生态适配及应用 EAS.AP已适配Linux、Android、QNX等多个主流车载 POSIX 操作系统。成功搭载入智驾、座舱、中央、车身、动力底盘域控及TBOX内的SOC平台，和多家国内外主流厂商完成量产适配，助力多家OEM车型项目开发及量产。 产品特色和增值服务 · 产品特色 » 功能扩展：DDS，IPC，Diag-Client，Diag-Router等拓展功能 » 应用开发框架：除标准模块外，提供 APP Demo，指导用户快速上手开发 » IP自主可控：核心技术完全自研（SOME/IP、DDS等） » 定制&联合开发：根据项目需求提供定制开发 » 丰富灵活的License模式：满足OEM、供应商等不同客户的不同需求 · 服务支持 » 本土化研发团队提供集成交付服务及全生命周期的技术支持，响应快 » 可根据不同用户的协议规范进行需求匹配 » 提供客户指定POSIX操作系统及SOC硬件平台的集成服务 » 提供用户现场基础软件与应用软件的集成服务及接口使用培训 · 培训课程 » 提供Adaptive AUTOSAR 应用场景及方法论培训 » 提供Adaptive AUTOSAR 标准组件的功能原理培训及工具使用培训 » 提供基于Adaptive AUTOSAR的应用开发简介及实践 了解更多：请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

伴随着电动化、智能化、网联化等技术发展的时代背景，各行各业电子电气架构都在发生深度变革。新型架构逐渐取代传统架构，比如汽车、工程机械、储能、船舶等领域，电子电气架构从传统分布式向域集中式，甚至向着中央集中式发展，控制器功能呈现集中化、复杂化的特点。为了提升开发效率、提高软件的稳定性以及便于平台移植，基于 AutoSar 架构开发复杂软件已成为行业共识。 另外，行业内竞争愈发激烈，开发周期大大压缩，加之软件复杂度的提升，在快速迭代的情况下确保软件质量是一个重要课题。加之 ASPICE、ISO26262 等过程体系和法规标准的要求，如何开发符合 AutoSar 架构的应用软件、评估软件质量和性能、优化软件结构、验证压力场景下的 ECU 稳定性成为各厂商面临的新挑战。 本文重点介绍符合 AutoSar 架构的应用软件开发、MBD 开发模式下的软件质量评估与优化方案、复杂场景下的 ECU 性能压力测试方案。 符合 AutoSar 架构的应用软件开发介绍 对于 AutoSar 软件架构，分为经典平台 AutoSar CP 和自适应平台 AutoSar AP，二者应用场景存在一定差别：AutoSar CP 具有高安全、高实时性，其通常部署在微控制器 MCU 类型芯片或多核异构芯片 M 核；AutoSar AP 具有动态性和可扩展性，适用于大数据并行处理和高性能计算等应用场景，通常部署在 MPU 或多核异构芯片 A 核。目前从行业内来看，无论是域控制器还是中央 + 区域控制器，通常都是多核的，甚至是多核异构的，不同核根据实际使用需求部署 AutoSar CP 或 AP，基础软件通常采用标准的 BSW 协议栈。下图所示是 AutoSar 软件架构示例： AutoSar 软件架构 那对于应用层软件来说，如果要开发符合 AutoSar 架构的软件，需要考虑以下两个重要问题： · 采用何种开发工具链 · 采用何种开发模式 对于应用软件开发工具链，通常涉及 SWC 软件架构设计工具和软件编程实现工具。SWC 软件架构设计工具主要对应用层软件架构进行实现，定义 SWC、配置 SWC 的交互接口、配置 Runnable、导出 ARXML 文件等，一般不同品牌的协议栈都有对应的 SWC 软件架构设计工具，经纬恒润自研 AutoSar 协议栈提供工具链方案为 EAS-SWCDesigner。 EAS-SWCDesigner 界面 而软件编程实现可基于图形化编程自动生成代码或手写代码的方式，AutoSar CP 和 AP 架构应用层软件开发实现方法略有差别，CP 架构应用层更多采用基于模型设计方法开发，工具链通常采用 Matlab/Simulink，其对 CP 架构应用层开发的支持比较完善且成熟，但是由于其对 AP 架构应用软件开发支持还存在不完善的点，故 AP 架构应用层软件开发目前更多还是基于手写 C++ 代码的方式，工具链基于一些代码编辑工具比如 Vscode。 对于应用软件开发模式，分为自上而下开发、自下而上开发和双向开发模式。自上而下开发比较适用于正向开发流程，在有 EE 架构输入的情况下采用该模式，这种模式的好处是可以继承 EE 架构的工作产品，但是缺点是工作链路会比较长，应用层和底层软件开发都需要依耐 SWC 架构设计导出的 ARXML 文件作为输入，影响开发迭代效率；自下而上开发是直接在软件编程工具实现软件，然后配置 AutoSar 接口，再导出 ARXML，然后对 ARXML 文件进行合并，这种方式比较适用于没有 EE 架构输入的情况，应用软件开发工程师独立配置 AutoSar 接口，这种模式的好处是不依耐 AutoSar 工具链，比较灵活，但是缺点是对每个应用软件开发人员 AutoSar 知识要求高些；双向开发模式就是结合自上而下和自下而上开发模式的优点，针对第一版软件采用自上而下开发模式，后续版本软件更新迭代采用自下而上开发模式。 应用软件开发模式 MBD 开发模式下的软件质量评估与优化方案 MBD 全称是 Model Based Design（基于模型设计），是一种以可视化模型开发为主的开发方式，区别于传统的以文本编码为媒介的代码开发。采用模型化的方式来描述控制算法设计，无论是可读性、可维护性、可移植性、测试验证的便利性等方面，相比于从前手工 C 代码都有长足的进步。基于以上基于模型开发的特点基于 Simulink 的模型化 + 自动代码生成的开发方式在汽车电子行业正在逐渐演变成开发的标准配置。接踵而来如何保证 MBD 开发方式下软件质量问题也成为现阶段人们热议的话题。 针对软件质量直接有效的手段便是开展完备的测试或在软件开发过程中优化软件结构减少问题的引入。 如何开展完备的模型测试？ 模型验证方法可以分为静态验证和动态验证，模型静态验证，是一种通过 MAAB 和 dSPACE 等建模公司提供的建模规则指南来验证模型设计是否符合规则的测试方法。此外，还有一种模型度量元指标检查方法，可以分析模型的复杂程度，以此评判模型在可维护性、可移植性、可重用性等不同维度的质量特性。综上所述，在模型静态验证部分，可以看出有两种方法：建模规范规则检查和模型度量元指标检查。与模型静态验证不同，模型动态验证可以通过比较在执行实际模型时的输出值来进行验证。通过根据用户输入预期结果值对比实际模型结果值来动态验证模型。通过检查模型的覆盖率，可以提高测试用例针对需求的覆盖率以及测试用例的充分性。此外借助 ASPICE 过程管理的思维，在整个测试过程中加入过程管理思维，确保测试过程、测试环境、测试策略的可靠性以及测试用例的充分性、一致性、追溯性，以此确保模型质量。 如何优化软件结构？ 现阶段我们模型生成的代码是否会存在以下问题： · 生成代码一个函数可能会上万行代码 · 看不懂 matlab 生成代码后的变量的定义及过程转化 · 要不要针对模型生成的代码做修改 优化软件的前提是已经开展静态测试优化完毕模型结构。确保模型结构的规范性。针对每一个软件设计单元生成独立函数、每一个软件组件生成与之相对应的 C 文件可以确保模型生成代码的结构清晰。同时不对模型生成的代码做任何的修改是 MBD 开发过程中的软件维护准则。 综上让我们一起来期待恒润针对 MBD 开发模式下的软件质量评估与优化的解决方案。 复杂场景下的 ECU 性能压力测试方案 随着控制器数量的激增和模块交互复杂度的提升，只针对软件基础功能验证的效果存在一定的缺陷，越来越多的项目实践表明，软件的偶发性故障需要从软件性能指标、压力场景来进行补充验证，以确保软件产品的质量。 性能测试针对 ECU 电控软件的内存（堆栈、RAM/ROM/FLASH）、CPU 负载进行最差工况的分析，保证资源占用的合理性；压力测试构建通信、IO 驱动、诊断、网络管理等模块的异常注入、总线故障、高频触发等场景，保证软件功能在压力场景下不存在致命风险。 基于 AbsInt 的静态性能分析 ◾ 客户收益 · 评估资源使用率，指导芯片选型和工程优化 · 保证软件的任务、中断预留堆栈空间和分配周期合理性 · 保证芯片内存占用率和 CPU 负载在阈值范围内 · 开展符合功能安全和 ASPICE 流程要求的测试 ◾ 测试内容 · 内存：自动化分析最差工况的堆栈用量、RAM/ROM/Flash 占用率 · WCET：分析最差工况下的执行时间，测试周期稳定性和任务实时性 · 调度仿真：模拟任务调度，建模仿真 CPU 负载率和任务占比 ◾ 方案特点 · 借助 AbsInt 工具，针对工程二进制可执行文件进行自动化分析，无需依赖源码 · 支持 PPC、V850、Tricore、ARM 等多种架构芯片的堆栈、时间分析 · 分析遍历工况，结果涵盖程序的各个入口 · 图形化展示最差工况下的执行路径和占比用量，指导性能优化 · 不依赖测试用例，执行效率高，项目周期短 · AbsInt 工具满足 ASIL D 等级功能安全标准 基于 AbsInt 的测试流程 函数调用关系及用量显示 数据化表格用量展示 基于 RVS 的动态性能测试 ◾ 客户收益 · 在 PIL、HIL、车载环境下进行时序分析，确保软件行为安全 · 可视化监测任务调度和 CPU 负载，为系统升级提供优化参考 · 保证多任务和多核运行的合理性，规避优先级反转、死锁等时序问题 · 开展符合功能安全和 ASPICE 流程要求的测试 ◾ 测试内容 · WCET：分析任务 / 中断的最差工况执行时间，测试周期稳定性和响应实时性 · 任务调度：评估 WCRT，监测任务时序特征，图形化显示多核、多任务调度关系 · 负载率：基于实际工况对 CPU 负载率进行实时统计和分析，评估极限负载下的 CPU 负载率占用情况 ◾ 方案特点 · 借助 RVS 分析套件进行实时数据采集和分析，还原实际环境下的执行工况 · 支持全量数据采集和长时间监测运行，追踪定位软硬件交互情况 · 自定义程度高，项目复用性强，可针对任意函数、模块或代码段进行时序分析 · 支持集成多种处理器 + 编译器环境，实现 PIL/HIL/ 车载环境下分析 · RVS 工具可以支持产品功能安全认证等级 ASIL D 基于 RVS 的测试流程 时序调度分析 基于自动化测试框架的压力测试 ◾ 客户收益 · 保证通信、诊断、操作系统、IO 驱动、网络管理等模块在压力场景下不存在致命风险 · 作为功能验证的补充，发现软件质量潜在问题，确保软件鲁棒性、稳定性 · 构建标准化的压力测试用例模板，有助于形成符合功能安全要求的测试流程 · 测试用例搭载自动化测试框架进行测试执行、用例管理、问题追溯 ◾ 测试内容 · 针对 NVM、IO 驱动、CAN、LIN、ETH、COM 等模块进行压力场景构建 · 分析系统不同组件间的时延特性，验证模块运行时间稳定性 · 验证在异常注入、高频触发、总线故障等因素影响下的功能稳定性 · 验证极限工况下的核心功能有效性及软件后续响应的合理性 ◾ 方案特点 · 借助自动化测试框架执行测试用例，测试周期短、测试效率高、测试复用性强 · 支持软硬件交互，可监测底层函数、上层报文、外部信号等 · 支持在 PIL/HIL 环境下开展测试，可同步注入多种激励进行测试验证 测试流程示意 测试框架示意 了解更多 请致电 010-64840808转6117或发邮件至market_dept@hirain.com（联系时请说明来自面包房社区）

什么是A TS ATS（Acceptance Test Specification）是由AUTOSAR释放的针对AUTOSAR不同软件组件的标准测试规范。根据软件类型的不同，ATS分为了应用测试（Application level）和总线测试（Bus level）： 应用测试 包括了例如RTE，BSW服务等组件的测试 总线测试 包括了CAN，LIN，FlexRay，Ethernet等总线的测试，也包括了更高层级协议的测试，比如网络管理，诊断通信等协议的测试 为什么需要A TS 我们知道AUTOSAR的通信协议栈（Communication Stack）是高度可配置的。对于同一协议栈，不同的用户会根据其具体项目中的应用需求来进行针对性的配置。 站在测试的角度，如果我们对这些不同配置的软件都进行单独的测试，这无疑存在很多重复性的工作，因为软件模块的基础都是相同的，只是因为配置的不同才产生了多种不同的变体。 于是我们把这些基础的和共性的需求梳理出来，并开发测试规范进行覆盖，这样在不同的项目中就不必再重复的执行这些测试了，而这些测试就是ATS定义的内容。 这样做的益处是显而易见的。 站在OEM的角度，他们不需要自己去开发和维护这些测试规范，甚至都不需要执行这些测试，只需审核供应商提交的报告 站在供应商的角度，针对同一软件组件的“标准接受性”测试只需要执行一次（针对同一硬件平台和编译环境） 站在测试服务商的角度，测试脚本只需开发一次，来自不同供应商的软件可以复用同一测试脚本主体。 所以不管站在谁的角度，这都极大的降低了测试的成本和工作量。 ATS 在整个测试活动中的位置与作用 图1： AUTOSAR 软件组件 完整 测试 活动 示意 一般来说，AUTOSAR软件组件一般经过如下几个阶段的测试： Unit Tests 单元级别的白盒测试。 Standard Acceptance Tests ATS定义的测试内容，可由第三方的测试服务商（Test House）完成，OEM可要求供应商来提交ATS的测试报告，作为“准入条件”。该要求由OEM制定，AUTOSAR并没有强制要求。 OEM Specific Qualification Tests 由OEM根据自己的企业标准或需求定制的测试，作为“认证”测试。只有经过“认证”的软件才可以在具体的项目中使用。和ATS类似，这个阶段也不包含配置相关的验证，所以测试方法可以参考ATS，也可在ATS的基础上进行扩展。 Project Specific Tests 与具体项目有关的配置测试。 因为ATS只覆盖了非常基础的和共性的需求，项目相关的或配置相关的需求都不在范围之内，覆盖度是非常有限的，所以ATS只能作为初步的验收测试，不能取代其他测试。就这一点来说，TC8也是类似的。 A TS 中 针对车载 以太网 的 相关 测试 ATS中涵盖了TCP/IP的IPv4，UDP，TCP三个部分，分别定义在AUTOSAR_ATS_IPv4, AUTOSAR_ATS_UDP，AUTOSAR_ATS_TCP三份规范中。 相信不少人有这样的疑问：为什么ATS中没有ARP，ICMP，DHCP等等这些内容？ 经过上面几个部分的介绍，答案应该显而易见，那就是ATS中只覆盖基础的和共性的需求，而ARP，ICMP，DHCP等部分目前不属于这个范围，如果OEM有相关的需求，需要自行开发测试规范。 关于更多AUTOSAR架构下的TCP/IP特点分析，以及AUTOSAR架构下TCP/IP是如何优化配置使其更加适用于车内网络的话题，请持续关注北汇信息公众号后续的分享。 ATS规范体系中有一篇要特别介绍一下，那就是 AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives 。 这篇文档中定义了一种测试桩（Test Stub）协议，用来支持车载以太网的测试，也就是我们常说的Upper Tester。我们在做TC8 TCP/IP测试时用到的Upper Tester，一般也是按照这份规范去开发的。更多关于Upper Tester的内容，可参考之前的文章 车载以太网-TC8 TCP/IP协议一致性测试实践-面包板社区 (eet-china.com) 中的介绍。 ATS与T C8 因为ATS本身属于AUTOSAR体系，所以ATS一般只适用于AUTOSAR节点。而TC8并没有对测试对象做要求，不论是AUTOSAR节点还是非AUTOSAR节点，都可以依照TC8进行测试。 但是有一点需要注意，有些商用AUTOSAR协议栈自带的Upper Tester（也称ETM）一般只能满足ATS中定义的测试，也就是只包含IPv4，UDP，TCP三个部分，如果需要完整的执行TC8的ARP，ICMP，DHCP等测试，需要进行额外的开发。 在TCP/IP的测试环境和测试方法方面，ATS与TC8并无本质的区别，可参考之前的文章 车载以太网-TC8 TCP/IP协议一致性测试实践-面包板社区 (eet-china.com) 进行了解。 在覆盖度方面，二者即有交集又有区别，我们做了一个简单的对比统计可供参考。 图2： AUTOSAR ATS 与 O PEN T C8 的 覆盖度 对比 大家可能有这样的疑问，针对ATS与TC8重叠的部分，所对应的测试脚本是否可以复用呢？答案是否定的，因为测试用例虽覆盖了相同的需求，但测试用例的设计方法不尽相同，所以测试脚本是不能完全复用的。 A TS 测试实践 下图展示了 A UTOSAR ATS TCP 部分 的 测试报告。 图3： A UTOSAR ATS TCP 的 测试报告 示意 可以看到TCP部分共有44条测试用例，其中有如下2条失败的条目。 IUT sends an ACK after receiving a data segment in FIN-WAIT-1 state IUT sends an ACK after receiving a data segment in FIN-WAIT-2 state 我们来分析一下失败的原因。 这两条测试用例分别验证了DUT作为TCP客户端时在FIN-WAIT-1和FIN-WAIT-2状态下接收数据的能力。 当客户端准备关闭连接时，会立即发送FIN，ACK来通知服务端，之后立即进入FIN-WAIT-1状态，当服务端应答之后，客户端会进入FIN-WAIT-2状态。 理论上，当TCP客户端发送FIN，ACK之后，就意味着客户端已经没有数据要发送了，但是此时还应具备接收数据的能力，也就是连接处于“半双工”（half-duplex）的状态，若此时收到服务端发送的数据，客户端应能够正确应答。 但是实际上被测设备并没有应答，而是发送了RST以通知服务端数据发生了丢失，这就导致了测试不通过。 关于连接半关的需求，最初源于RFC793，但是在RFC1122中重新进行了讨论，因为很多协议栈都由于操作系统的限制，不支持这个机制，在这些操作系统中，如果应用发起TCP关闭请求（比如调用close()）之后，就不再具备发送或者接收数据的能力。 而我们可以在AUTOSAR_SWS_TcpIp的 这条需求中看到，AUTOSAR中其实并没有要求节点实现连接半关，这是测试用例的属性标记为“MAY“的原因。 图 4 ： AUTOSAR_SWS_TcpIp 节选 如果协议栈不支持这个机制，就意味着在客户端发起连接关闭请求之后，如果服务端继续发送数据，这部分数据会被客户端丢掉，这在设计业务流程时要格外注意。 参考文档： AUTOSAR_EXP_AcceptanceTestsOverview.pdf AUTOSAR_ATS_IPv4.pdf AUTOSAR_ATS_UDP.pdf AUTOSAR_ATS_TCP.pdf AUTOSAR_SWS_TcpIp.pdf