CN112543129B - 队列深度的确认方法、系统及报文模拟器 - Google Patents

Abstract

本发明实施例提供队列深度的确认方法、系统及报文模拟器，以对不同预设场景下网关控制器在目标网段的实际队列深度进行确认，报文模拟器与整车网络中的各个网段相连接。该方法包括：根据目标场景初始化整车网络报文传输场景；在测试阶段，报文模拟器根据目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；网关控制器在测试阶段对接收到的报文进行路由，周期性统计目标网段的实际队列深度并发送至总线上；在测试阶段结束后，报文模拟器将统计得到的报文数量和实际队列深度的最大值输出至测试结果。

Description

队列深度的确认方法、系统及报文模拟器

技术领域

本发明涉及汽车电子领域，特别涉及队列深度的确认方法、系统及报文模拟器。

背景技术

汽车内部会安装多个控制器，不同控制器之间通过总线连接建立整车网络。而网关控制器(Gateway，GW)将整车网络划分为多个网段(例如整车信息总线、动力总线、底盘总线、舒适总线等)，每个网段包括不定数量的ECU(也可称为实车节点)，且网段间相互物理隔绝，使用路由功能将一条报文从一个网段路由到另一个网段，以实现信息互联互通。

GW采用发送队列缓存路由报文直到GW有能力发送至目标网段，是避免高负载环境下丢帧、避免漏转TP(Transport Protocol Layer)协议报文导致路由刷写失败的一种有效手段。

然而，发送队列深度(支持缓存的报文数量)过大会占用MCU中较多的RAM空间，从而使功能扩展受限。但发送队列深度配置过小又不足以应对高负载的场景，进而可能导致关键报文丢失(当缓存报文数量达到发送队列深度，后续报文丢弃处理)。因此，目前需要能够准确地确定发送队列深度的技术方案。

发明内容

有鉴于此，本发明实施例提供发送队列深度的确认方法、系统及报文模拟器，以准确确定发送队列深度。

为实现上述目的，本发明实施例提供如下技术方案：

一种发送队列深度的确认方法，用于基于报文模拟器对不同预设场景下网关控制器在目标网段的实际队列深度进行确认，所述报文模拟器与整车网络中的各个网段相连接；所述方法包括：

根据目标场景初始化整车网络报文传输场景；所述目标场景是多个不同的预设场景中的一个；

在测试阶段，所述报文模拟器根据所述目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述网关控制器在所述测试阶段对接收到的报文进行路由，周期性统计所述目标网段的实际队列深度并发送至总线上；所述收发两端的报文数量用于判断在所述测试阶段是否出现丢帧；

在所述测试阶段结束后，所述报文模拟器将统计得到的测试过程中收发两端的报文数量输出至测试结果；

所述报文模拟器将统计所述网关控制器所发送的实际队列深度的最大值，并将所述最大值输出至测试结果。

一种发送队列深度的确定系统，包括报文模拟器和网关控制器：

所述网关控制器至少用于：根据目标场景初始化整车网络报文传输场景；所述目标场景是多个不同的预设场景中的一个；

在所述测试阶段对接收到的报文进行路由，周期性统计所述目标网段的实际队列深度并发送至总线上；

所述报文模拟器用于：

在测试阶段，根据所述目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述收发两端的报文数量用于判断在所述测试阶段是否出现丢帧；

在所述测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，所述网关控制器所发送的实际队列深度的最大值输出至测试结果。

一种报文模拟器，用于对不同预设场景下网关控制器在目标网段的实际队列深度进行确认，包括：

模拟单元，用于在测试阶段，根据目标场景模拟实体设备进行报文发送；所述目标场景是多个不同的预设场景中的一个；

统计单元，用于在测试阶段，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述网关控制器至少用于：在所述测试阶段对接收到的报文进行路由，周期性统计所述目标网段的实际队列深度并发送至总线上；

测试结果生成单元，用于在所述测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，所述网关控制器所发送的实际队列深度的最大值输出至测试结果。

在本发明实施例中，会先根据不同的目标场景初始化整车网络报文的传输场景，然后在正式的测试阶段，由报文模拟器根据不同的目标场景模拟实体设备进行报文发送，这样，可模拟不同场景下实际的报文发送情况，在测试阶段，网关控制器会持续路由报文，周期性统计所述目标网段的实际队列深度并发送至总线上。在测试阶段，报文模拟器还统计收发两端的报文数量，在总线上获取网关控制器发送的实际队列深度。在测试阶段结束后，将统计得到的实际队列深度的最大值及收发两端的报文数量，输出至测试结果。后续可比对收发两端报文数量，以确保目标网段的实际队列深度是未丢帧情况下的有效统计结果，进而实现实际队列深度的获取。由于模拟的是真实的报文传输场景，所获取的实际队列深度可为发送队列深度设计参数提供参考，便于更准确地设置发送队列深度。

附图说明

图1a为本发明实施例提供的网段示意图；

图1b为本发明实施例提供的VN/CaseXL与网段相连接示意图；

图1c为本发明实施例提供的确认系统的示例性结构；

图2为本发明实施例提供的VN与网段连接的示意图；

图3为本发明实施例提供的多网段集中并发需路由至目标网段的示意图；

图4为本发明实施例提供的确认方法的一种示例性交互流程；

图5为本发明实施例提供的路由刷写过程中传输数据块的交互流程；

图6为本发明实施例提供的确认方法的另一种示例性交互流程；

图7为本发明实施例提供的确认方法的又一种示例性交互流程；

图8为本发明实施例提供的网关控制器在源网段快速接收报文，在目标网段低速发送报文的示意图；

图9为本发明实施例提供的确认方法的又一种示例性交互流程；

图10为本发明实施例提供的报文模拟器的一种示例性结构。

具体实施方式

汽车内部会安装多个控制器，不同控制器之间通过总线(CAN表示总线)连接建立整车网络。请参见图1a，网关控制器将整车网络划分为CAN1-CAN5等多个网段，网段间相互物理隔绝。使用路由功能将一条报文从一个网段路由到另一个网段，以实现不同控制器间的数据交互。

车辆中大部分的报文都是由事件触发的，例如，因车辆使用人员操作触发发送节点发送报文，而后经由网关转发至目标接收节点，目标接收节点收到报文之后执行操作，或者进行某些信息的响应。

GW采用发送队列缓存路由报文直到GW有能力发送至目标网段，是避免高负载环境下丢帧、避免漏转TP层(Transport Protocol Layer)协议报文导致路由刷写失败的一种有效手段。因此，目前需要能够准确地确定发送队列深度的技术方案。

有鉴于此，本发明实施例提供发送队列深度的确认方法、确认系统及报文模拟器，以准确确定发送队列深度。

请参见图1c，上述确认系统包括报文模拟器及网关控制器，其核心是基于报文模拟器对不同预设场景下网关控制器在目标网段的实际队列深度进行确认。

为了实现这一目的，报文模拟器与整车网络中的各个网段相连接。

在一个示例中，报文模拟器可包括上位机和至少一个VN/CaseXL(CAN收发设备)。其中，上位机上安装有CANoe软件，每一VN/CaseXL与一个网段相连接，举例来讲，请参见图1b，假定有5个网段，可有5个VN(VN1-5)，每个VN都具有收发功能。

具体的，每一VN/CaseXL的通道与GW之间通过连接器连接，以实现VN/CaseXL与网段相连接。每一VN/CaseXL可有多个通道。

CANoe是一款总线开发环境，全称叫CAN open environment，主要用于汽车总线的开发而设计的。是网络和ECU开发、测试和分析的专业工具，支持从需求分析到系统实现的整个系统的开发过程。

在工作时，上位机中的指令可通过VN/CaseXL转化为CAN报文。VN/CaseXL也可将接收的报文转化为可被上位机识别的信息，传输给上位机。

如无特殊声明，本文后续的上位机即为部署了CANoe的上位机。

图2示出了由上述报文模拟器、网关控制器所执行的发送队列深度的确认方法的一种示例性交互流程，包括：

S1：根据目标场景初始化整车网络报文传输场景。

目标场景是多个不同的预设场景中的一个。本文后续将具体介绍不同的场景。

上述初始化整车网络报文传输场景至少可包括：网关控制器将目标网段的队列深度配置为预置深度，例如，可事先将每个网段的队列深度设置为300帧。

更具体的，可在网关控制器中添加调试代码，调试代码包括将目标网段的队列深度配置为预置深度的逻辑操作。调试代码在测试完成后会进行删除。

此外，根据目标场景的不同，初始化整车网络报文传输场景还可包括一些其他操作，本文后续将结合不同的目标场景进行详细介绍。

S2：在测试阶段，报文模拟器根据目标场景模拟实体设备进行报文发送。

前述提及，报文模拟器的上位机中部署有CANoe。可使用CANoe可识别的编程语言(Capl编程语言)，依照目标场景和目的编写测试用例(脚本)，添加至CANoe以控制VN/CaseXL执行步骤S2。

可针对不同的场景、不同目标网段配置不同的脚本，在此不赘述。

S3：网关控制器在测试阶段对接收到的报文进行路由。

如何进行路由可参见现有方式，在此不作赘述。

S4：在测试阶段，报文模拟器统计测试过程中收发两端的报文数量。

收发两端的报文数量可用于判断在测试阶段是否出现丢帧，若收、发的报文数量相同，可判定未出现丢帧，否则，出现丢帧。

前已述及，报文模拟器的VN/CaseXL可与各网段连接，因此，其可获得各网段中的报文进而进行统计。

S5：在测试阶段，网关控制器周期性统计目标网段的实际队列深度并发送至总线上。

网关控制器可每隔一定时间统计目标网段的实际队列深度，时间长短可进行灵活设计，在此不作赘述。

实际应用时，网关控制器并不会将某网段的队列深度发到总线上，因此，可在网关控制器中添加调试代码，由调试代码周期性将统计的目标网段的实际发送队列深度发到总线上。

需要说明的是，步骤S3与S5为两独立的步骤，二者可并列执行。

S6：报文模拟器在总线上获取目标网段的实际队列深度。

具体的，可由前述的VN/CaseXL获取目标网段的实际队列深度。

需要说明的是，步骤S4与S6为两独立的步骤，二者可并列执行。

S7：在测试阶段结束后，报文模拟器将统计得到的测试过程中收发两端的报文数量和实际队列深度的最大值输出至测试结果。

在一个示例中，可由前述的VN/CaseXL将报文数量和最大值发送至上位机，再由上位机将报文数量输出于测试结果。

或者，也可由VN/CaseXL生成测试结果，再将测试结果上传至上位机。

或者，VN/CaseXL也可将在总线上获得的每一实际队列深度都上传至上位机，由上位机将最大值输出至测试结果。

可见，在本发明实施例中，会先根据不同的目标场景初始化整车网络报文的传输场景，然后在正式的测试阶段，由报文模拟器根据不同的目标场景模拟实体设备进行报文发送，这样，可模拟不同场景下实际的报文发送情况，在测试阶段，网关控制器会持续路由报文，周期性统计所述目标网段的实际队列深度并发送至总线上。在测试阶段，报文模拟器还统计收发两端的报文数量，在总线上获取网关控制器发送的实际队列深度。在测试阶段结束后，将统计得到的实际队列深度的最大值及收发两端的报文数量，输出至测试结果。后续可比对收发两端报文数量，以确保目标网段的实际队列深度是未丢帧情况下的有效统计结果，进而实现实际队列深度的获取。由于模拟的是真实的报文传输场景，所获取的实际队列深度可为发送队列深度设计参数提供参考，便于更准确地设置发送队列深度。

考虑到初始化时预置的预置深度可能不够大，会出现丢帧现象，在本发明其他实施例中，请参见图2，还可包括如下步骤：

S8：在测试阶段结束后，根据测试结果中收发两端的报文数量，判断在测试阶段是否出现丢帧。

可由人工或脚本判断是否出现丢帧。

S9：若判定出现丢帧，增大预置深度。返回S1。

可人工增大调试代码中的预置深度。

这样，可在判定丢帧的情况下，增大预置深度，以期获得更为准确的发送队列深度。

在现有方案中，可通过如下方式设置队列深度：

方式一，假设总线负载持续100％的高峰值时间为50ms，且GW(也即网关控制器)在此期间无法将接收报文转发到目标网段，需要将50ms内在源网段接收到并需要转发到目标网段的报文全部缓存到队列中，则队列深度应至少大于等于：10ms报文数量*5+20ms报文数量*3+30ms报文数量*2+40ms报文数量*2+50ms报文数量*2(公式一)。

上述公式是是理论估算公式。公式中的10ms/20ms/30ms/40ms/50ms指的是其他发送节点的报文的发送周期，公式中的系数5、3、2、2、2指的是在50ms时间内所能接收到的最多次数。

方式二，诊断仪只能连接诊断总线，当需要对非诊断总线的控制器进行诊断时，诊断仪通过诊断总线发送诊断请求，网关控制器将诊断请求路由到非诊断总线，非诊断总线上的控制器进行响应，通过网关将响应报文路由到诊断总线，此种场景涉及报文的集中发送，丢帧的可能性较大。

以诊断仪功能寻址排放相关控制器(简称排放控制器)为例，诊断仪通过诊断总线发送诊断请求后，排放控制器经由诊断总线响应17字节的VIN码(VIN码表示车架号)，每个排放相关控制器需要发送3帧，则理论上需要缓存3*N(公式三)的诊断报文。N表示非诊断总线的控制器数量。

方式三，路由刷写。

一般来说，出于安全考虑实车仅将诊断总线连接到OBD口，如果装车后其他处于非诊断总线的控制器需要升级应用程序，则需要网关控制器由诊断总线路由诊断请求到其他总线，再由其他总线路由诊断响应至诊断总线，实现刷写流程。

刷写过程中，会停止整车各控制器的应用报文通信。因为诊断报文的优先级较低，如果保持应用报文通信，可能会干扰刷写过程中的诊断报文交互，导致刷写失败。

因此，在刷写场景下仅缓存诊断报文即可。

刷写的交互过程为：

1、刷写设备首先发送首帧请求下载；

2、待刷写控制器回复流控帧告知刷写设备刷写过程中的STmin和BlockSize；

STmin表示连续帧的最小间隔时间，BlockSize表示两帧流控帧之间最多的连续帧数量。

其中，当STmin设置为0时，表示对刷写设备发送的包含下载数据的连续帧之间的间隔时间不作要求，刷写设备可以自身极限速度进行发送。当BlockSize设置为0时表示仅此一帧流控帧。

相比较于将STmin设置为其他数值，将STmin设置为0的条件最为严苛。

举例来讲，假如将BlockSize设置为8，表示待刷写控制器回复流控帧后，刷写设备可发送8帧连续帧，而后需要等待待刷写控制器回复下一帧流控帧后，才继续发送连续帧。相当于刷写设备需要等待待刷写控制器将8帧连续帧处理完成后才能继续发送后续连续帧。

而当BlockSize设置为0时，刷写设备接收到待刷写控制器返回的第一帧流控帧后，持续发送连续帧直到本次请求下载的数据传输完成，中间不会主动等待待刷写控制器处理完成，这种情况下是最容易发生丢帧的。

为此，可将BlockSize和STmin设置为0，在此情况下实测队列深度配置为50(报文数量)可行。

对于诊断总线，设置的队列深度需要同时满足上述方式一至三得到的队列深度，对于非诊断总线，设置的队列深度需要同时满足方式一和方式三得到的队列深度。

上述方式存在以下缺陷：

以方式一为例，在总线高负载期间，低优先级发送报文难以抢占总线，但高优先级报文，仍有机率成功发送，并非无法发送。

若高负载持续时间较长(例如持续1s)，按照单个网段有10条10ms周期发送报文计算，则在1s需要缓存1000条报文，占用18KB左右RAM空间。

对于多通道通信的GW则需要在此基础上乘以通道的倍数。然而，通常来说RAM空间也仅有数十KB，因此采用方式一计算队列深度不适用长时高负载情景，按照极限情况考虑会导致估算出的队列深度过大，失去参考价值；

方式一和二仅通过理论估算，结果不够准确，冗余量大；

对于方式二和三，个别控制器不支持UDS诊断功能，无法停止通信，实车条件相对更加严苛，从而导致估算出的队列深度不够准确。

为解决现有方式所存在的缺陷，本发明后续将结合容易导致网络高瞬时负载且经常出现的四种实车场景设计了队列深度确认方案，并借助调试代码实时获取GW在这些情况下的实际队列深度，以评估能够保证在这些场景下不丢帧的发送队列深度。

下面分别进行介绍。

场景一：多网段集中并发需路由至目标网段的报文。

举例来讲，事件型报文无固定周期而由特定事件触发，诸如，车辆EMS(发动机管理系统)与PEPS(无钥匙进入/启动系统)的防盗认证匹配过程、车辆碰撞后，ESC(电子稳定控制单元)发送给安全气囊控制器ACU的碰撞位置信号等。

事件型报文在关键或实时性要求高且需要不同控制器通信交互的功能中常用，其发送时机具有不确定性，因此，请参见图3，存在多个源网段(C1、C2、C3)集中并发事件型报文，要求GW路由至同一目标网段(C4)，导致目标网段瞬时负载较高的情况。

请参见图4，针对这一场景，由上述报文模拟器、网关控制器所执行的发送队列深度的确认方法的一种示例性交互流程，包括：

S41：网关控制器将目标网段的队列深度配置为预置深度。

具体细节请参见前述记载，在此不作赘述。

S42：报文模拟器模拟各网段的实车节点周期性地发送报文。

步骤S42也可称为开启各个网段的节点同步。

进一步的，在报文模拟器包含部署有CANoe的上位机的情况下，节点同步指CANoe中的Node Synchronization功能，直译为“节点同步”，可以通过CANoe上位机将实车节点的报文，按照通信矩阵中的描述周期性地发送到总线上，以模拟实车环境。

通信矩阵是对实车报文、信号属性定义的集合。示例性的，报文的发送节点、周期以及信号的位置，长度等属性在通信矩阵中都有描述。

S41和S42均属于初始化操作。

S43：报文模拟器改变目标报文的发送属性。

其中，目标报文可包括：在目的地址为目标网段的报文中，具有特定特征的报文。在本实施例中，特定特征示例性得可为：ID大或优先级低。这是因为：ID大的报文其优先级比ID小的报文低。源网段因正常负载率，拥有相对充足的总线空闲时间，使得低优先级报文得以以极限速率发送，而低优先级报文在目标网段总线仲裁时不容易抢占到总线执行发送，从而不得不缓存在队列中等待有限的总线空闲时机再尝试发送，发送速率低，其丢帧的概率更高，使得需要更多的发送队列深度才能保证低优先级在这种情况下不发生丢帧现象。考虑到极限情况下也应尽可能保证不丢帧，因此选择ID大的报文。

而发送属性包括：发送周期和发送数量中的至少一种。

例如，目标报文原有发送周期为50ms，可将其改变为10ms、20ms等。

前述提及了，可依照目标场景和目的编写测试用例，步骤S43和其后的S44的执行逻辑可编写在测试用例中，由上位机通过执行对应的测试用例而实现。

S44：在各网段中采用改变后的发送属性模拟实车节点发送目标报文，令目标网段的负载达到预设值并持续预设时长。

预设值和持续的预设时长可根据目的而灵活设定。例如，可设定令目标网段负载率达到90％并持续1s。

更具体的，上位机可通过CANX.Busload(一个数据)获取当前网段负载，X表示为当前网段对应的CANoe通道。

步骤S43和S44为前述步骤S2的细化操作。

S45：网关控制器在测试阶段对接收到的报文进行路由。

如何进行路由可参见现有方式，在此不作赘述。

S46：报文模拟器统计测试过程中收发两端目标报文的报文数量。

具体的，当负载率达到预期值时，上位机中运行的脚本/测试用例可将测试开启标志置1。在On message*函数(该函数由接收报文事件触发调用，发送报文计数和接收报文计数均在该函数下执行，*表示接收到任意ID报文均满足条件)中开始累加记录发送目标报文和接收目标报文的数量。测试到时(沿用步骤S43的举例，是持续1S之后)，将测试开启标志清零进行结果清算。

当然，可在On message*函数添加判定条件，满足判定条件的报文才会统计。

在一个示例中，为保证计数准确，在负载达到90％时，可为目标报文添加特殊标记，例如将目标报文数据场的第一字节(例如Byte0)赋值为0x11，第二字节(Byte1)赋值为0x22。测试完成后将Byte0赋值为0x00，Byte1赋值为0x00。

0x11和0x22不常用，将其作为特殊标记，是为了让测试开启标志置1后的目标报文具有与其他报文不同的唯一属性，便于识别(因为测试期间，总线上还存在节点同步发送的其他周期报文)。这样做的目的是减少On message*函数中进行报文计数时的判定条件，只需判定标记和报文的所在网段(通过this.can获取即可)，因为高负载场景中报文以us级时间发送，硬件处理能力有限时，过多的判定条件会导致报文计数不准确。

而若不添加特殊标记，可通过报文的所在网段、报文ID，报文的发送/接收方向来判断某条报文是否为目标报文，相对判定条件更多。

S47：在测试阶段，网关控制器周期性统计目标网段的实际队列深度并发送至总线上。

在实现时，网关控制器会将所有网段的实际队列深度发送至总线。后续由上位机根据其测试场景自行选取并记录目标网段的实际队列深度。

更具体的，以目标网段为例，网关控制器通过执行前述的调试代码，记录目标网段的队列缓存报文的数量(也即当前值)，并与上一周期(例如，以100ms为一周期)时记录的队列缓存报文的数量(可称为上次值)进行比较，若当前值大于上次值，则将该值保存，并在当前值连续10次(连续N次)小于所保存的值时，将保存值由非路由报文发送到总线(例如在CAN2上发)。

S48：报文模拟器在总线上获取目标网段的实际队列深度。

具体的，可由前述的VN/CaseXL在CAN2上获取目标网段的实际队列深度并上传至上位机。

上位机(中的测试用例/脚本)识别到VN/CaseXL收到包含发送队列深度的报文后，在报文数据的特定位置提取出实际队列深度。

S49：在测试阶段结束后，报文模拟器将统计得到的测试过程中收发两端目标报文的报文数量和实际队列深度的最大值输出至测试结果。

具体的，步骤S49可由上位机中的测试用例或脚本执行。

具体介绍请参见前述记载。此外，上位机可将测试结果发布到Write面板呈现给使用者。

S410：在测试阶段结束后，比对携带特殊标记的目标报文的收发数量，确定是否发生丢帧。

S411：若判定出现丢帧，增大预置深度。返回S41。

场景二：在路由刷写过程中，诊断仪或刷写上位机发送诊断报文至目标网段的场景。

路由刷写过程中转发的是TP层协议报文，期间发生丢帧会导致整个刷写过程失败，如果通过电检设备执行路由刷写失败，更是存在整车厂产线停线的风险，因此保障路由刷写不丢帧十分必要。

Tp层协议主要描述了多帧传输的过程。因为一帧标准CAN报文的数据场仅8个字节，当需要传输的字节长度较多时，需要采用多帧传输的方式。

多帧传输的过程主要包含三种类型的报文：首帧、流控帧和连续帧。

其中，首帧(First Frame)：首帧即发送端发送的第一帧，包含需要传输数据的字总节长度信息和部分数据；

流控帧(Flowcontrol Frame)：由接收端返回给发送端，包含每两帧连续帧的最小间隔时(STmin)，以及每两帧流控帧间发送端最多发送的连续帧数量(BlockSize)等信息；

连续帧(Consecutive Frame)：发送端在接收到接收端返回的流控帧后，发送给接收端的帧，包含需要传输的数据。

路由刷写过程中传输数据块的交互流程请参见图5。

依据TP协议，多个连续帧最大传输的数据字节长度为0xFFF，即4095字节，在BlockSize为0，STmin为0的极限情况下，诊断仪或刷写上位机通过36服务发送首帧请求传输数据，收到待刷写控制器返回的流控帧后，会以极限速度连续发送585帧。

但由于控制器的RAM空间有限，不能一次接收传输的全部数据，所以在传输时，刷写设备会根据待刷写控制器提供的MaxNumberofBlockLength参数(即支持接收的最大数据块长度)将585帧待传输数据分割成多个数据块逐个传输。

并且，一个数据块传输成功后，刷写设备会等待，直到待刷写ECU返回肯定响应表示成功接收了当前数据块，才会继续发送下一个数据块内容，在接收到肯定响应(PositiveResponse)前，诊断仪或刷写上位机不会继续传输下一个数据块。

因此网关只需确保一个数据块传输过程中不发生丢帧，后续的刷写过程也可以顺利执行不丢帧。

基于上述情况，图6示出了由上述报文模拟器、网关控制器所执行的发送队列深度的确认方法的另一种示例性交互流程，包括：

S61与前述的S41相类似，在此不作赘述。

S62：报文模拟器模拟目标网段的实车节点周期性地发送报文。

可人工或自动选择一个目标网段，开启该网段的节点同步。

S62与前述的S42相类似，在此不作赘述。

需要说明的是，虽然刷写过程中，诊断仪或刷写上位机一般会通过28服务停止应用报文的通讯，但仍有部分控制器因为不具备UDS诊断功能不会停止发送应用报文，为模拟极限情况，在本实施例目标网段中的所有控制器均不停止应用报文发送。

而GW作为关键通讯控制器，是要求支持28服务，此时不会路由其他总线报文至目标网段，因此无需开启其他网段的节点同步。

S63：在预设时长内，报文模拟器在诊断总线上模拟诊断仪或刷写上位机以预设发送速度发送目标报文。

在本实施例中，目标报文包括：目的地址为目标网段的诊断报文。

这里的预设发送速度即前述的极限速度，约1ms发送4帧。具体实现时，可设置定时器，总1ms发4帧诊断报文。

至于预设时长，前述提及了，收到待刷写控制器返回的流控帧后，会以极限速度连续发送585帧，按照每帧报文传输时间为241us(填充位最多的情况)，发送完585帧的时长为141ms左右。

因此，可设计预设时长大于141ms，例如150ms。需要说明的是，150ms是对极限速率下传输一个数据块的时间141向上取整得到的。实际上，时长越长越容易丢帧，因此按照150ms持续时间测试得到的发送队列深度能够满足更严苛情况下不丢帧的要求。

前述提及了，可依照目标场景和目的编写测试用例，步骤S63的执行逻辑可编写在测试用例中，由上位机通过执行对应的测试用例而实现。

S64：网关控制器在测试阶段对接收到的报文进行路由。

如何进行路由可参见现有方式，在此不作赘述。

S65：报文模拟器统计测试过程中收发两端目标报文的报文数量。

具体的，在第一次发送目标报文时，将测试开启标志置1，在On message*函数中累加记录发送目标报文和接收目标报文的数量。达到预设时长后，将测试开启标志清零进行结果清算。

在一个示例中，为保证计数准确，可为目标报文添加特殊标记，具体细节请参见前述S46的记载，在此不作赘述。

S66-S610与前述的S47-S411相类似，在此不作赘述。

场景三：在路由刷写过程中，多网段集中并发需路由至诊断总线的响应报文的场景。

本场景与前述方式二中介绍的场景相同。诊断仪通过诊断总线发送诊断请求，网关控制器将诊断请求路由到非诊断总线，非诊断总线上的控制器进行响应。

场景三与场景二的区别在于，场景二中，诊断网段为源网段，目标网段为诊断网段之外某一指定网段。

而场景三中，源网段是非诊断网段，目标网段为诊断网段。

请参见图7，针对这一场景，由上述报文模拟器、网关控制器所执行的发送队列深度的确认方法的一种示例性交互流程，包括：

S71：网关控制器将诊断网段的队列深度配置为预置深度，进入测试阶段。

具体细节请参见前述记载，在此不作赘述。

S72：报文模拟器向诊断总线发送功能寻址报文。

在本步骤中，报文模拟器模拟的是诊断仪。

S73：报文模拟器在非诊断总线模拟各实车节点连续发送N帧响应报文。

在本实施例中，前述的目标报文包括：针对功能寻址报文的响应报文。

在一个示例中，为保证计数准确，可为响应报文添加特殊标记，具体细节请参见前述S46的记载，在此不作赘述。

N一般可取值为3。因为实际的刷写过程中，实车节点返回的响应报文为3帧。

此外，需要说明的是，在实际的刷写过程中，存在流控帧的交互，为简化测试过程，本实施例省略了流控帧的交互，相对实际刷写过程，因为不存在首帧报文与流控帧间的等待时间，而是直接连续发送多帧响应报文，本实施例模拟的报文发送环境更为严苛。

前述提及了，可依照目标场景和目的编写测试用例，步骤S73和S74的执行逻辑可编写在测试用例中，由上位机通过执行对应的测试用例而实现。该测试用例通过按键触发，例如按下“k”键后，向诊断总线发送功能寻址报文。

而测试用例识别到非诊断总线收到该功能寻址报文后，(测试用例可以判断接收报文所在网段，在VN与网关控制器的硬件连接确定后，是可以知道哪个网段是非诊断总线的)，模拟每个实体节点连续发送3帧诊断响应报文。

S74：网关控制器在测试阶段对接收到的报文进行路由。

网关收到功能寻址报文，会将其路由至各非诊断总线，也会将其他非诊断总线的响应报文路由至诊断总线。

S75：报文模拟器统计测试过程中收发两端响应报文的报文数量。

具体的，在第一次发送响应报文时，将测试开启标志置1，在On message*函数中累加记录发送目标报文和接收目标报文的数量。达到预设时长后，将测试开启标志清零进行结果清算。

S76-S710与前述的S47-S411相类似，在此不作赘述。

场景四：网关控制器在源网段快速接收报文，在目标网段低速发送报文。

当路由关系的目标网段为动力总线或底盘总线等正常工作负载较高且关键报文(网络设计时分配高优先级ID)数量多的网段，源网段(Source Network)为信息总线等正常工作负载较低的网段，事件型路由报文集中发送时，鉴于CAN总线载波侦听、冲突退避的机制，就会出现GW在源网段快速接收报文，在目标网段(Target Network)低速发送报文，导致待发送报文在队列中堆积的情况，示意如图8。

请参见图9，针对这一场景，由上述报文模拟器、网关控制器所执行的发送队列深度的确认方法的一种示例性交互流程，包括：

S91-S92与S41-S42相类似，在此不作赘述。

S93：在预设源网段以预设速度模拟实车节点发送目标报文。

其中，目标报文包括：在目的地址为目标网段的报文中，具有特定特征的报文。

举例来讲，预设源网段可包括：信息总线等正常工作负载较低的网段。

目标网段可包括：动力总线或底盘总线等正常工作负载较高且关键报文数量多的网段。

上述预设速度可为极限速度。

前述提及了，可依照目标场景和目的编写测试用例，步骤S93和其后的S94的执行逻辑可编写在测试用例中，由上位机通过执行对应的测试用例而实现。

S94：在目标网段发送高优先级报文以干扰目标网段的总线负载率，令目标网段的负载达到预设值并持续预设时长。

具体的，可在目标网段以一个比较小的周期发关高优先级报文(例如ID为0x1、0x2的报文。

预设值和持续的预设时长可根据目的而灵活设定。例如，可设定令目标网段负载率达到90％并持续1s。

更具体的，上位机可通过CANX.Busload(一个数据)获取当前网段负载，X表示为当前网段对应的CANoe通道。

步骤S93和S94为前述步骤S2的细化操作。

S95-S911与前述的S46-S411相类似，在此不作赘述。

本发明实施例还要求保护一种发送队列深度的确定系统，请参见图1c，该系统包括报文模拟器和网关控制器，其中，

报文模拟器用于：在测试阶段，根据目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；其中，收发两端的报文数量用于判断在测试阶段是否出现丢帧；

在测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，网关控制器所发送的实际队列深度的最大值输出至测试结果。

当然，在一些实施例中，报文模拟器还可用于初始化整车网络报文传输场景。

网关控制器至少用于：根据目标场景初始化整车网络报文传输场景；目标场景是多个不同的预设场景中的一个；

在测试阶段对接收到的报文进行路由，周期性统计目标网段的实际队列深度并发送至总线上。

在本发明其他实施例中，上述系统还可包括判定单元，用于：

在测试阶段结束后，根据测试结果中收发两端的报文数量，判断在测试阶段是否出现丢帧；

若判定出现丢帧，增大预置深度；返回重新执行根据目标场景初始化整车网络报文传输场景的操作。

当然，也可由人工判定，以及通过操作上位机而重新执行初始化及后续操作。

具体介绍请参见前述介绍，在此不作赘述。

图10示出了上述报文模拟器的一种示例性结构包括：

初始化单元101，用于根据目标场景初始化整车网络报文传输场景；

模拟单元102，用于在测试阶段，报文模拟器根据目标场景模拟实体设备进行报文发送；

统计单元103，用于在测试阶段，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；

测试结果生成单元104，用于在测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，网关控制器所发送的实际队列深度的最大值输出至测试结果。

在本发明其他实施例中，目标场景包括：多网段集中并发需路由至目标网段的报文。

在初始化整车网络报文传输场景的方面，初始化单元101具体用于：模拟各网段的实车节点周期性地发送报文。

相应的，在根据目标场景模拟实体设备进行报文发送的方面，上述模拟单元102具体用于：

改变目标报文的发送属性；

在各网段中采用改变后的发送属性模拟实车节点发送目标报文，令目标网段的负载达到预设值并持续预设时长。

其中，目标报文包括：在目的地址为目标网段的报文中，具有特定特征的报文；

发送属性包括：发送周期和发送数量中的至少一种；

具体介绍请参见前述介绍，在此不作赘述。

在本发明其他实施例中，上述目标场景可包括：在路由刷写过程中，诊断仪或刷写上位机发送诊断报文至目标网段的场景。

在初始化整车网络报文传输场景的方面，初始化单元101具体用于：模拟目标网段中的实车节点周期性地发送报文。

在根据目标场景模拟实体设备进行报文发送的方面，上述模拟单元102具体用于：

在预设时长内，在诊断总线上模拟诊断仪或刷写上位机以预设发送速度发送目标报文；目标报文包括：目的地址为目标网段的诊断报文。

具体介绍请参见前述介绍，在此不作赘述。

在本发明其他实施例中，上述目标场景可包括：网关控制器在源网段快速接收报文，在目标网段低速发送报文。

在初始化整车网络报文传输场景的方面，初始化单元101具体用于：模拟各网段的实车节点周期性地发送报文。

在根据目标场景模拟实体设备进行报文发送的方面，上述模拟单元102具体用于：

在预设源网段以预设速度模拟实车节点发送目标报文。

目标报文包括：在目的地址为目标网段的报文中，具有特定特征的报文；在目标网段发送高优先级报文以干扰目标网段的总线负载率，令目标网段的负载达到预设值并持续预设时长。

具体介绍请参见前述介绍，在此不作赘述。

在本发明其他实施例中，目标网段为诊断总线；上述目标场景包括：在路由刷写过程中，多网段集中并发需路由至诊断总线的响应报文的场景。

在根据目标场景模拟实体设备进行报文发送的方面，上述模拟单元102具体用于：

向诊断总线发送功能寻址报文；在非诊断总线模拟各实车节点连续发送N帧目标报文。

目标报文包括：针对功能寻址报文的响应报文。

具体介绍请参见前述介绍，在此不作赘述。

在本发明其他实施例中，在目标网段的负载达到预设值后，报文模拟器所发送的目标报文携带特殊标记；或者，针对功能寻址报文的响应报文携带特殊标记。

相应的，在根据测试结果中收发两端的报文数量，判断在测试阶段是否出现丢帧的方面，统计单元103具体用于：比对携带特殊标记的目标报文的收发数量，确定是否发生丢帧。

具体介绍请参见前述介绍，在此不作赘述。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及模型步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或模型的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、WD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (9)

1.一种发送队列深度的确认方法，其特征在于，用于基于报文模拟器对不同预设场景下网关控制器在目标网段的实际队列深度进行确认，所述报文模拟器与整车网络中的各个网段相连接；所述方法包括：

根据目标场景初始化整车网络报文传输场景；所述目标场景是多个不同的预设场景中的一个；

在测试阶段，所述报文模拟器根据所述目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述网关控制器在所述测试阶段对接收到的报文进行路由，周期性统计所述目标网段的实际队列深度并发送至总线上；所述收发两端的报文数量用于判断在所述测试阶段是否出现丢帧；

在所述测试阶段结束后，所述报文模拟器将统计得到的测试过程中收发两端的报文数量输出至测试结果；

所述报文模拟器将统计所述网关控制器所发送的实际队列深度的最大值，并将所述最大值输出至测试结果。

2.如权利要求1所述的方法，其特征在于，

所述初始化整车网络报文传输场景至少包括：所述网关控制器将所述目标网段的队列深度配置为预置深度；

所述方法还包括：

在所述测试阶段结束后，根据所述测试结果中收发两端的报文数量，判断在所述测试阶段是否出现丢帧；

若判定出现丢帧，增大所述预置深度；

返回重新执行所述根据目标场景初始化整车网络报文传输场景的步骤及后续步骤。

3.如权利要求2所述的方法，其特征在于，

所述目标场景包括：多网段集中并发需路由至所述目标网段的报文；

所述初始化整车网络报文传输场景还包括：

所述报文模拟器模拟各网段的实车节点周期性地发送报文；

所述报文模拟器根据所述目标场景模拟实体设备进行报文发送包括：

改变目标报文的发送属性；所述目标报文包括：在目的地址为所述目标网段的报文中，具有特定特征的报文；所述发送属性包括：发送周期和发送数量中的至少一种；

在各网段中采用改变后的发送属性模拟实车节点发送所述目标报文，令所述目标网段的负载达到预设值并持续预设时长。

4.如权利要求2所述的方法，其特征在于，

所述目标场景包括：在路由刷写过程中，诊断仪或刷写上位机发送诊断报文至目标网段；

所述初始化整车网络报文传输场景还包括：

所述报文模拟器模拟所述目标网段中的实车节点周期性地发送报文；

所述报文模拟器根据所述目标场景模拟实体设备进行报文发送包括：

在预设时长内，在诊断总线上模拟诊断仪或刷写上位机以预设发送速度发送目标报文；所述目标报文包括：目的地址为所述目标网段的诊断报文。

5.如权利要求2所述的方法，其特征在于，

所述目标场景包括：网关控制器在源网段快速接收报文，在所述目标网段低速发送报文；

所述初始化整车网络报文传输场景还包括：

所述报文模拟器模拟各网段的实车节点周期性地发送报文；

所述报文模拟器根据所述目标场景模拟实体设备进行报文发送包括：

在预设源网段以预设速度模拟实车节点发送目标报文；所述目标报文包括：在目的地址为所述目标网段的报文中，具有特定特征的报文；

在所述目标网段发送高优先级报文以干扰所述目标网段的总线负载率，令所述目标网段的负载达到预设值并持续预设时长。

6.如权利要求2所述的方法，其特征在于，

所述目标网段为诊断总线；

所述目标场景包括：在路由刷写过程中，多网段集中并发需路由至诊断总线的响应报文；

所述报文模拟器根据所述目标场景模拟实体设备进行报文发送包括：

向所述诊断总线发送功能寻址报文；

在非诊断总线模拟各实车节点连续发送N帧目标报文，所述目标报文包括：针对所述功能寻址报文的响应报文。

7.如权利要求6所述的方法，其特征在于，

在所述目标网段的负载达到预设值后，所述报文模拟器所发送的目标报文携带特殊标记；

或者，针对所述功能寻址报文的响应报文携带特殊标记；

所述根据所述测试结果中收发两端的报文数量，判断在所述测试阶段是否出现丢帧包括：

比对携带特殊标记的目标报文的收发数量，确定是否发生丢帧。

8.一种发送队列深度的确定系统，其特征在于，包括报文模拟器和网关控制器：所述报文模拟器与整车网络中的各个网段相连接；

所述网关控制器至少用于：根据目标场景初始化整车网络报文传输场景；所述目标场景是多个不同的预设场景中的一个；

在测试阶段对接收到的报文进行路由，周期性统计目标网段的实际队列深度并发送至总线上；

所述报文模拟器用于：

在测试阶段，根据所述目标场景模拟实体设备进行报文发送，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述收发两端的报文数量用于判断在所述测试阶段是否出现丢帧；

在所述测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，所述网关控制器所发送的实际队列深度的最大值输出至测试结果。

9.一种报文模拟器，其特征在于，用于对不同预设场景下网关控制器在目标网段的实际队列深度进行确认，所述报文模拟器与整车网络中的各个网段相连接；包括：

模拟单元，用于在测试阶段，根据目标场景模拟实体设备进行报文发送；所述目标场景是多个不同的预设场景中的一个；

统计单元，用于在测试阶段，统计测试过程中收发两端的报文数量，并在总线上获取目标网段的实际队列深度；所述网关控制器至少用于：在所述测试阶段对接收到的报文进行路由，周期性统计所述目标网段的实际队列深度并发送至总线上；所述收发两端的报文数量用于判断在所述测试阶段是否出现丢帧；

测试结果生成单元，用于在所述测试阶段结束后，将统计得到的测试过程中收发两端的报文数量，以及，所述网关控制器所发送的实际队列深度的最大值输出至测试结果。

Images