标签: 诊断测试

1.前言 我们在以往的分享中介绍了网络安全的相关技术在车载通信中的一些内容，包括E2E和SecOC等，但这些技术通常更多地是做数据校验，数据本身还是以明文进行传输。而随着网络安全级别的提高以及以太网在车载中更大规模的使用，我们迫切地需要数据加密的手段来防止数据被监听。同时由于车载通信对延迟性能的要求和部署的特点，MACsec可能是一个更容易被选择的方案。 2.什么是MACsec MACsec全称为Media Access Control Security，基于协议802.1AE和802.1X，主要功能是用于数据加密，同时还有认证、校验的功能。其保护的数据是以太网中二层以上的数据，即包括ARP在内的数据，都会被加密进而无法通过网络监听获取。 同时相比于其他加密手段，如TLS，MACsec由于可以基于硬件实现，因此可以做到更低的延时和更高的性能。并且对于上层应用来说，MACsec是在二层进行加密，因此对于上层来说是无感的，这意味着上层不需要做任何改动就可以进行加密的部署。这对于当前无加密系统切换加密系统来说有着很大的优势。 3. MACsec工作流程 MACsec使用对称加密，其密钥生成分发过程为EAPOL-MKA（EAP是Extensible Authentication Protocol，EAPOL即EAP over LANs，MKA即MACsec Key Agreement protocol ，见IEEE Std 802.1X)，标准的MACsec的EAPOL-MKA流程会先进行密钥服务器的选举，但在车载网络中，更可能的情况是预先定义好密钥服务器，因此本文就不赘述密钥服务器选举流程（可以参考IEEE 802.1X），直接看一下密钥服务器如何生成和分发密钥。 首先所有的MACsec设备中会预先配置好一个密钥，称为CAK（Secure Connectivity Association Key），由于其是预先定义的密钥，因此也叫做Pre-Shared-Key。需要注意的是，CAK并不是能直接参与数据加密的密钥，实际用于数据加解密的密钥是SAK（Secure Association Key），SAK是通过CAK进行派生，SAK的生成过程如下所示： 1）预配置密钥：除了预先配置CAK外，还需要配置密钥标识CKN（Connectivity Association Key Name）。CKN就是额外的一个数据参数，CAK+CKN共同用于密钥派生函数KDF（Key Derivation Function）。 2）密钥派生：CAK通过不同的派生函数（派生函数参考AUTOSAR AUTOSAR_SWS_MACsecKeyAgreement、IEEE 802.1X、NIST 800-108）和参数生成3个密钥：ICK（Integrity Check Value Key，即校验的密钥）、KEK（Key Encryption Key，即加密SAK的密钥）、SAK（Secure Association Key，即实际加密数据的密钥）。其中ICK和KEY是通过CAK+CKN生成固定的密钥，可以认为MACsec设备均已预先得知。ICK用于流程校验，KEK用于SAK的加密。SAK是由CAK+RNG（Random Number Generator，即随机数生成）生成的随机密钥，用于实际数据的加密。 3）加密SAK：使用KEK加密SAK（加密算法参考rfc3394中AES Key Wrap algorithm），将加密SAK传输到以太网总线中 4）获取解密后的SAK：伙伴节点使用相同的KEK解密后获取SAK，将SAK用于实际数据的加解密 在SAK成功分发到MACsec节点后，MACsec中的二层以太网报文就都可以用加密的方式进行数据的交互 4. MACsec报文格式 MACsec的报文格式如下图所示： 其中DMAC即目标MAC，SMAC即源MAC，CRC即帧校验，这部分都是以太网帧中原有的内容。802.1Q+payload即原有以太网中携带的数据（包含以太网帧类型），这部分数据会以GCM-AES-128（也允许支持GCM-AES-256）的加密算法进行加密（密钥为上一章节中分发的SAK）。ICV（Intergrity Check Value）为校验码。SecTAG为加密头，用于识别MACsec相关信息，其结构如下： MACsec EtherType为固定值0x88E5，表示MACsec报文； TCI（TAG Control Informatin）为控制信息； AN（Association Number）为关联号； SL（Short Length）为短数据长度（小于48字节才会使用，见IEEE 802.1AE）； PN（Packet Number）为包的序号，用来防止重放攻击； SCI（Secure Channel Identifier）中还包含PI（Port Identifier），即通道和端口的标识，对简单网络来说应该是固定值。 SecTAG的解析见如下示例： 另外对于GCM-ASE算法来说，有3个参数：nonce（即加密向量IV）、add（附加消息）、tag（消息认证码）和MACsec中字段有映射关系。Nonce对应SCI+PN，add对应DMAC+SMAC+SecTAG，tag对应ICV（参考IEEE 802.1AE）。 5. CANoe MACsec示例 在CANoe中我们建立多个节点：ChatClient1和ChatClient2以TCP的连接与ChatServer建立会话关系，他们的通信不需要关注MACsec。实际在总线的数据由Switch_1的Port1与Switch_2的Port2进行以太网数据的发送接收，拓扑关系如下所示： 环境启动后，Port1和Port2就进行MACsec的SAK分发过程，分发完成后，Port1和Port2就可以正常以MACsec进行加密通信，如下所示： 当我们在ChatClient1发送会话数据“Polelink”，ChatClient2响应会话“YES”时，对于ChatClient1和ChatClient2来说数据的收发是原封不动的明文，如下所示： 而对于实际以太网数据而言，Port1和Port2的收发数据就全是密文数据，如下所示： 6.总结 北汇信息专注于汽车电子测试、与众多OEM合作，在总线网络诊断测试开发相关领域积累了丰富的经验。本次为大家简单介绍了MACsec，但很多细节还有待商榷，后续我们也会带来更多关于网络安全的测试开发内容，也欢迎大家共同探讨。 注：文中图片来源于AUTOSAR、Vector CANoe、IEEE 802.AE 参考文献 AUTOSAR_RS_MACsec AUTOSAR_SWS_MACsecKeyAgreement IEEE 802.1X IEEE 802.1AE https://info.support.huawei.com/info-finder/encyclopedia/en/MACsec.html https://community.cisco.com/t5/networking-knowledge-base/mka-macsec-key-agreement-exchange-on-the-wire/ta-p/4436083

一、背景介绍 在车载诊断中常用的诊断协议有ISO 14229等，在协议中主要定义了诊断请求、诊断响应的报文格式及ECU该如何处理诊断请求的应用。其中ISO 14229系列标准协议定义了用于行业内诊断通信的需求规范，也就是UDS。UDS主要应用于OSI七层模型的第七层——应用层，它支持的汽车总线包括：CAN、LIN、FlexRay、Ethernet及K-LINE。UDS中的服务根据其功能分为6大类，共26种。其中包含的0x19服务（ReadDTCInformation）则是UDS中的重中之重。那么我们今天就一起进入到19服务中，感受其中的奥秘。 服务介绍 19服务（ReadDTCInformation）用于读取ECU的DTC故障信息，此服务允许客户端从服务器读取诊断故障代码（DTC）的相关信息。此服务包含28个子服务(Subfunction)，常用的5种子服务如下： 0x01 reportNumberOfDTCByStatusMask（读取客户端定义状态掩码匹配的DTC数量） 0x02 reportDTCByStatusMask（读取客户端定义状态掩码匹配的DTC） 0x04 reportDTCSnapshotRecordByDTCNumber（检索客户端定义DTC掩码的快照数据） 0x06 reportDTCExtDataRecordByDTCNumber（读取某个DTC及其相关的扩展数据，扩展数据包括DTC状态，优先级，发生次数，时间戳，里程等。） 0x0A reportSupportedDTC（读取ECU支持的所有DTC的状态，包含支持的各个DTC编号以及相关状态） 今天主要解析19服务中的04子服务，也就是检索客户端定义DTC的快照号对应的快照记录数据，在AUTOSAR中也叫冻结帧。 04子服务介绍 1、快照数据概念介绍 前面讲19服务常用子服务的时候，提到了Subfunction为04的子服务，使用04子服务对服务端进行请求，可以获取DTC发生时记录的快照数据。那04子服务是如何获取快照数据的呢？首先我们需要理解什么是快照数据。从ISO 14229-1协议可知，快照数据为发生某一故障时记录的DTC的电压、发动机转速、时间戳等，从而使工程师在ECU出现故障时能及时了解车辆的历史和实时故障信息。 2、报文格式介绍 接下来通过介绍19 04子服务请求和响应的报文格式，分析报文中各个字节的相关定义。 请求格式 图 1 从图1中可知，19 04的请求报文包括四个部分，其中服务ID和Subfunction就不用过多解释了。DTCMaskRecord表示某个故障的DTC，当系统检测到一个故障发生时，则会存储其对应的故障数值，这个故障数值就是DTC。通过读取DTC可知一个故障发生时的具体位置以及原因和类型。通常UDS中DTC占3个字节，OBDⅡ占2个字节，在ISO 15031-6中定义的DTC由两个字节根基和一个字节的故障类型组成。我们通常用到的DTC格式都是由ISO 15031-6中定义的。图2是ISO 15031-6中定义的DTC的两个字节根基，图中很详细地解释了每一个Bit的含义。 图2 SnapshotRecordNumber需要提前定义，可以有多个。如SnapshotRecordNumber设置为FF，则表示读取所有的快照数据组。 响应格式 图3 图3为响应报文格式，当使用19 04对ECU进行请求时，ECU给出的肯定响应的报文格式由七部分组成。此时的DTCAndStatusRecord由三个字节的DTC和一个字节的StatusOfDTC组成，StatusOfDTC表示DTC的状态。假设现在的DTC状态为0x09，则Bit0和Bit3置1。如某个DTC一直存在并且确认，则在ECU响应的报文中的StatusOfDTC为0x09。如图4 图4 SnapshotRecordNumber这个字节表示DTC快照记录的组号；DTCSnapshotRecordNumberOfldentifiers表示快照DID的个数，占一个字节；Dataldentifier这部分由两个字节组成，表示快照数据对应的DID，DTCSnapshotRecord表示快照DID对应的具体数据。 3、实例分析 前面介绍了19 04子服务请求和响应的报文格式。掌握了理论知识，那么现在我们就到实例中去具体分析，从而加深对19 04子服务如何读取快照数据的过程的理解。 客户端对服务端发起一个读取DTC快照的请求。当前DTC为 0x123456 ，可以假设这是一个转向灯的故障码， 0x02 为快照记录组号。请求报文如图5所示。 图 5 服务端端对客户端回复了一个肯定响应。从图6中可知，当前的DTC状态掩码为 0x24 ， 0x01 表示只有一个快照DID，当然也可以包含多个快照DID，可以分别表示车速、电压等。如果有两个快照DID，此时DTCSnapshotRecordNumberOfldentifiers这个字节为0x02。快照DID为 0x4711 ，如果此时记录的是转向灯故障时当前车速的数据，那么这个 0x4711 则表示此时快照数据的名称——车速。DTCSnapshotRecord为具体的快照数据 0xA666075020 ，以16进制数值表示，通过数据类型解析后就可以得到具体的车速等信息。 图 6 在CANdelaStudio中如何设置 接下来我们看看在CANdelaStudio中如何设置19 04服务的请求及响应参数，步骤如下： ①配置DTC信息 在这个界面如图7，可以进行“DTC Code”的新增与删减，点击现有的信息可进行编辑改动； 图 7 ②设置服务 在左侧目录切换到“Base Variant”下的“Supported Diagnostic Classes”，点击“Fault Memory”； 图 8 点击图9上面标签页中的“DTCs”，然后会跳转到图9所示界面，将我们前面配置的DTC信息更新到这里来，如图9所示，当前DTC为0x123456。 图 9 点击图10上面标签页中的“Snapshot Records”，然后会跳转到图10所示界面，在这里设置快照记录组号。 图 10 ③设置肯定响应参数 首先根据客户的需求设置ECU支持的DTC状态位DTCStatus，如图11； 图 11 然后在“DTCs”页面选中名为0x123456的DTC，在“Individual for DTC P123456”下设置快照数据。例如图12中现在定义的快照DID为4711，具体的快照数据是当前车辆的Wheel Speed FR等。快照DID可以在“DIDs”中提前定义。到这里，在CANdelaStudio中关于19 04服务的请求及响应参数就设置完成了。（软件界面截图来源于CANdelaStudio 16.0版本） 图 12 总结 19 04服务的目的是读取对应DTC的快照数据，从而使工程师在进行诊断时更加快速了解故障发生时的车辆状况信息。除此之外，19服务还有其他4个常用的Subfunction，大家可以根据ISO 14229-1中的相关解释和实例进行知识扩展。 北汇信息专注于汽车电子网络通信、诊断刷写、逻辑功能测试开发服务，期待进一步沟通交流、共享合作的机会。 参考文档：ISO 14229-1（2020）

CAN FD概述 在汽车领域，随着人们对数据传输带宽要求的增加，传统的CAN总线由于带宽的限制难以满足这种需求。 CAN FD作为CAN总线的升级版本，继承了传统CAN总线主要特性，如使用改动较小的物理层，双线串行通讯协议，基于非破坏性仲裁技术，分布式实时控制，可靠的错误处理和检测机制等，而且CAN FD弥补了CAN总 线带宽和数据长度不足的问题。 CAN FD与CAN异同 由于CAN FD在传输数据方面的优势，CAN FD受到主机厂的广泛关注，相关测试也随之产生。在诊断测试方面，CAN FD主要分为诊断服务测试和传输协议测试。 诊断服务测试依据UDS等相关规范，与CAN诊断服务测试无明显差异。在传输协议测试方面，虽然ISO-15765-2标准（2016版）同时定义了CAN、CAN FD诊断传输协议的需求，但是两者协议控制信息有明显差别，故现有的CAN诊断传输协议测试规范、脚本并不能完全兼容CAN FD。 协议控制信息字节汇总 依据总线协议，CAN帧最多可传输8字节的数据，CAN FD帧最多可传输64字节数据，即CAN单帧、首帧、流控帧、续帧数据长度最多可达8字节，而CAN FD单帧、首帧、续帧数据长度最多可达64字节。除此之外， CAN单帧的SF_DL参数固定在Byte#1的低四位，而CAN FD单帧的SF_DL参数可位于Byte#1的低四位或Byte#2。 CAN FD诊断报文示例 CAN诊断报文示例 相对于CAN诊断传输协议测试，CAN FD诊断传输协议测试更加注重对单帧、首帧、流控帧、续帧的数据长度测试。 作为德国Vector公司的合作伙伴，北汇信息将提供CAN FD诊断测试的相关解决方案。 CAN FD诊断传输层测试规范开发 北汇信息依据行业标准（ISO-15765-2）开发测试规范、定义测试方式和测试重点，包含正向和逆向的测试内容，以满足测试深度和覆盖度的需求。 同时，针对不同客户的特殊需求可定制测试规范。 CAN FD诊断传输层测试脚本开发 CAN FD诊断传输层测试脚本基于Vector公司总线测试工具链，由CANoe+CAPL实现。 CAN FD诊断服务测试 CAN FD诊断测试脚本基于Vector公司总线测试工具链，由CANoe+DiVa+CANdelaStudio实现。 相关软件介绍 CANoe是Vector公司针对汽车电子行业开发的总线分析工具，能对系统进行仿真，半物理仿真以及测试。 对CAN总线报文及信号的符号化访问与显示 通过Statistics，Trace，Data，Graphic和Bus Statistics窗口中分析CAN总线 创建显示和控制面板 可显示、发送、过滤、记录并回放CAN报文 数据记录支持信号触发模式 支持统计功能 支持离线分析 通过CAPL语言实现用户自定义功能 DiVa是Vector公司的诊断集成及验证工具，可以基于诊断数据库（CDD或者ODX文件），为CANoe自动生成全面而详细的诊断测试用例，并分析测试报告。 CANdelaStudio是Vector公司的诊断数据库文件（CDD文件）的生成工具，为相关测试工具提供诊断数据的输入。 应用 北汇信息基于多年来在总线诊断服务测试和传输协议测试的技术经验积累，结合Vector的CANoe、DiVa、CANdelaStudio等工具的支持，我们目前已成功为国内主机厂实现CAN FD诊断传输协议需求规范评审、测试规范开发、测试脚本开发，成功帮助客户更快更好地完成相关的测试工作。

1 . 前言 上回系列文章《基于ODX诊断测试开发( 1 ): ODX数据库剖析 基于ODX诊断测试开发（1）：ODX数据库剖析-面包板社区 (eet-china.com) 》简单介绍了ODX文件类型及各个文件层级结构，本期我们来详细介绍下ODX数据库如何解析。 在展开正文之前，先说明一下，此文介绍的解析ODX数据库的目的所在。针对涉及诊断功能类（如DTC等）测试的项目，实现过程大致为两步：先通过CANoe-CAPL完成通用的诊断功能测试脚本的开发；当针对具体ECU实施测试时，依据该ECU的诊断数据表，完成上述通用脚本的参数配置，可以手动配置（效率较低）或通过解析诊断数据表完成自动配置。过往项目中，诊断数据表既有Excel表格也有ODX格式。为此，北汇开发了诊断数据表的解析模块（支持Excel和ODX格式），实现对测试脚本参数的自动配置，从而提高效率。 2. ODX实现方式 ODX使用统一建模语言UML类图来描述的，ODX数据又是通过XML文件格式来储存的。我们知道类包含属性和方法，同时具有封装、继承、多态等特点。那么如何将UML映射为XML呢？ISO 22901 - 1 规范做出如下规定： 将UML类映射为XML的元素； 如果UML中类的属性有《attr》标记，则将该属性映射为XML元素的属性；如果UML中类的属性无《attr》标记，则映射为XML元素的子元素。如果UML属性有《content》标记，则映射为XML元素的内容； 如果类B通过Aggregation和composition和类A建立联系，则类B映射为XML 类A元素的子元素； 如果类B通过association和类A产生关联，则在XML中通常以引用的方式实现，如《snref》，《snpathref》或《odxlink》； UML类图中的继承关系，在XML中以的方式实现； 注：Aggregation、composition和association为UML类图之间的关系，在这里不做详细介绍。 图1和图2就是根据以上规则，将UML转化为XML的例子。 图1 图2 3. ODX继承-值继承 值继承属于ODX中的核心概念，面向对象继承的概念用于诊断数据模型具有如下优点： （1）多个ECU变体对诊断数据的复用； （2）对于ECU应用于多个项目的情况，可以提取公共数据，ECU变体中只保留不同的数据，从而减少数据冗余； （3）提供了数据安全和可集成性。 在上一期我们简单介绍了下ODX继承，为了避免数据的重复冗余，ODX将诊断层分为了5个层级。如图3所示，其中，Protocol具有一般性，ECU Variant具有特殊性，ECU Shared Data 类似一个library，可以为其他层提供数据和服务。 图3 我们知道，ODX中的继承关系，在XML中以的方式实现的，如果继承的数据中有部分数据不适用，可以通过 去除不适用的数据。从图4的例子中可以看出，该ECU不支持level 3 和level 4 解锁等级。 图4 4. ODX解析思路简介 当我们拿到一份ODX或者PDX（PDX是将一系列ODX文件打包）时，如何开展解析工作呢？ （1）首先找到ECU的Base Variant 文件。 （2）在Base Variant 中查找继承关系。 （3）在Base Variant 文件中查找对应的ECU变体即ECU Variant。 （ 4 ）在ECU Variant 文件中查找对应的诊断服务和数据。 图5 5. ODX解析实践 根据章节 3 的ODX解析思路，获得的解析结果见图6、7和8。其中ECU Shared Data 作为library，提供了通用的诊断服务，见图6；而ECU变体BCM 88890251 A除了继承Base Variant的通用诊断服务，还增加了多个DID、RID、IO Control，同时去除了1 9 15 、2 7 05 和2 7 06 这些不适用的服务。图8展示了ODX中包含的多种数据类型，这里不再详细介绍。 图6 图7 图8 6. 总结 相较于传统的Excel格式的诊断数据交换的不便性，ODX统一了诊断文件的格式，在研发、测试、生产和售后等部门传递交换时，不需要进行格式转换，因此，很多OEM开始使用ODX。目前，北汇已经开发基于ODX的诊断自动化测试方案，感兴趣的小伙伴可以一起交流。 参考文献 ISO 22901-1

前言 对 于 汽车电子测试工程师来说 ， 实车级网络 及 诊断测试 是项 繁琐 却 又必 要 的工作 。 风吹日晒，寒来暑往，固然挡不住测试人奋斗的脚步。但是手提示波器 、 身背测试仪 、 一个个，一路 路 地 去 手动 测试 车辆 上几十个甚至上百个E CU ，是不是太繁琐了？能不能更加自动化、高效化呢？ 北汇信息 在与国内多家O EM 进行 实车级网络 及诊断 测试 的 合作 过程中 ，始终在思考这个问题。 基于对 实车 级网络 及诊断 测试需求的准确把握、 V ector 测试工具链的 丰富 应用经验 ， 北汇信息 开发了一套 使用方便、测试可靠、运行稳定的 实车级网络 及诊断自动化测试系统，下面就让我们一睹为快吧 ！ 图1：测试系统实物 背景 实车级网络 及诊断测试的必要性 从 完整的 车辆开发角度而言 ， 实车级网络 及诊断 测试是 真正的“大考” ， 其重要性 和必要性 不言而喻 。 首先， 保证控制器的通信稳定是实车功能正常的前提基础。但 在有限的整车空间内集成大量传感器 、 控制器 、 大功率 执行器 ， 实车电气 环境 复杂且使用场景组合 比较复杂， 这可能会 对控制器间的通信行为带来 一定 影响 ； 部分测试场景需要在实 车 环境 下测试更为有意义 ， 如整车电源模式 变化 对 E CU 通信 诊断的影响 ； 在实车上会 偶发 一些 问题 ， 如车辆启动后丢帧的情况 ， 通过手动或者 传统 单节点自动化测试脚本难以测试或分析出问题 。 传统 实车级网络 及诊断 测试方法 及缺点 通过手动方式对整车上所有 E CU 进行 逐个测试 ，记录及分析结果，时间长且效率低 ； 测试系统 供电 来自实车 ， 采集到的整车电流等信息有误 ， 对实车数据分析结果带来偏差 。 北汇信息 的创新 针对 实车网络 及诊断 测试必要性以及 传统 测试方法 不足 ， 北汇信息 基于 Vector 的 V N89 00 (具备Standalone功能 ) 、 C ANoe 、 Pico S cope 以及电池 模块 、 自 研 设备路由 板卡 D RB 实现 实车级网络 及诊断 自动化测试， 并对采集的实 车数据 进行 分析， 定位实车可能的问题 点 。 测试方案 测试系统框图 图 2 ：测试 方案 设备 功能简介 锂电池 ： 测试系统 供电 ，可支持系统独立运行 ； V N89 00 ： 测试脚本独立运行设备 ， 需要 结合 CANoe /CANalyzer Standalone basic/extended License 使用 ； 图 3： V N89 00 的实物图 V N8972 ：C AN/CANFD/LIN总线报文收发设备 ， 安装在 V N89 00 中 ； I O Piggy8642 ： 用于 实车电压采集 ， 安装在 V N89 00 中 ； Pico S cope ：C AN/CANFD/LIN 物理电平 信息 采集 设备 ， 包含协议解析功能 ； 图 4： Pico Scope 实物图 自 研 设备路由 板卡 D RB ： 实现多网段 总线自动化测试 ； 上位机P C ： 编辑和 下载 测试脚本 、 导出测试报告和数据 、 运行 部分 测试脚本 ； 显示屏 ： 显示当前系统电池输出电压和电量 。 测试范畴 的示例 物理层测试： 包括 输出电压、共模电压、上升/ 下降 沿时间 测试 等 ； 通信测试： 包括 报文周期、 总线负载等； 网络管理测试：验证实车上E CU 的休眠、唤醒模式是否符合设计要求 ； 网关测试： 如 所有网段间路由报文的路由时间 等 ； 诊断测试：读取不同场景下所有E CU 的诊断故障码，并判断是否错误记录了D TC 。 测试 过程 使用 上位机 P C 将测试工程下载到 V N8900中 ； 图5 ：V N8900工程配置 将实车OBD等接口与测试系统连接 ； 使能 V N8900的 Start， 运行测试工程 ； 测试完成后， 将上位机 P C 和 V N8900连接 ， 导出测试报告和数据 ； 图 6 ： 导出测试报告和数据 将采集 的 实 车数据 进行 分析 ，定位车辆可能存在的问题 。 内容如 下 ： DTC的分析统计（DTC统计，DTC关联，DTC恢复等） 刷写的分析统计（刷写流程分析， Hex文件还原） 通讯的分析统计 -协议层（周期，丢帧，超警戒负载，信号范围，转发延时，异常数据，校验及安全机制） 网络逻辑分析（ 上下电过程 ，休眠过程，网络状态） 功能逻辑分析（互斥信号，备份信号，无效信号，默认信号，其他逻辑类） 对于实车上出现的问题 ， 在网络及诊断测试系统上 进一步 复现问题并排查原因 。 自动化 测试报告 示例 网络测试报告 图 7 ：网络测试报告 物理层 测试报告 图 8 ：物理层测试报告 诊断 D TC 测试报告 图 9 ：诊断D TC测试报告 总结 对整车开发而言 ， 实 车 阶段 的 网络 及诊断 测试是必经之路 。 虽 O EM的 E CU部件级 和系统级 测试 规范 中包含丰富的测试用例 ， 但复杂 的 实 车环境 带来 影响以及车 辆偶发问题 的 困扰 ， 使 实车级 网络 及诊断 测试 越来越受重视 。 传统 实车级网络 及诊断 测试 方法强依赖于人工 ， 随着车型开发周期逐渐缩短 ， 测试效率和准确性均受到严重的挑战 。 北汇信息 专注于测试 ， 着眼于 客户 需求 ， 开发出 实车级网络 及诊断 自动化测试系统 方案 。 对于实车测试问题，还需要在 网络 及 诊断 测试系统 上 进一步 复现问题并排查原因。 北汇信息 提供相应成熟的技术解决方案， 欢迎各位 行业 同仁 垂询 和指导 ！ 参考文献 VN8900_Manual_EN .pdf S cope _Manual_EN .pdf