CN115643124A - 一种pc机模拟汽车can总线通信系统 - Google Patents

Abstract

本发明公开了一种PC机模拟汽车CAN总线通信系统，该PC机模拟汽车CAN总线通信系统包括：主线程：用于系统启动，设备管理，通讯设置，子线程的创建，线程间通讯设置；收包线程：用于接收CAN接口的数据，放入到buffer池中缓存起来，报文先进先出；发包线程：用于接收其他线程的发包请求进行发包，暂时不设优先级，报文先进先出；本发明是针对软件系统开发过程中的陪试设备不到位的情况下影响项目开发与测试进度，提出了一种PC机上模拟CAN总线ECU通信的方法，提高开发与测试的质量和进度。

Description

一种PC机模拟汽车CAN总线通信系统

技术领域

本发明涉及通信技术领域，具体是一种PC机模拟汽车CAN总线通信系统。

背景技术

CAN总线与一般的串行通信总线相比，它的数据通信具有可靠性高，实时性高，灵活性强等优点，不仅广泛应用于汽车行业，而且扩展到了机械工业、机器人、数控机床等诸多领域。尤其在大量数据通信处理中，高可靠性及实时响应的场合发挥巨大作用。

现有的CANTest软件是周立功can卡的官方测试调试工具，也是USBCAN-I/II智能CAN 接口卡配套驱动程序，能够接收、发送、查看、分析和记录CAN报文，为开发人员和测试人员提供了一个简单的模拟环境。我们提供的方案除了包含CANTest功能外，还能编辑信号响应逻辑，模拟ECU模块工作状态，代替ECU模块进行开发与测试。

发明内容

本发明的目的在于提供一种PC机模拟汽车CAN总线通信系统，以解决上述背景技术中提出的问题。

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

一种PC机模拟汽车CAN总线通信系统，

该PC机模拟汽车CAN总线通信系统包括：

主线程：用于系统启动，设备管理，通讯设置，子线程的创建，线程间通讯设置；

收包线程：用于接收CAN接口的数据，放入到buffer池中缓存起来，报文先进先出；

发包线程：用于接收其他线程的发包请求进行发包，暂时不设优先级，报文先进先出；

报文解析线程：用于对报文进行解析和流量统计，显示在报文界面和流量统计界面，解析的报文包含收包线程接收的报文和从文件中读取的报文，报文有过滤时，只解析符合条件的报文进行显示；

模拟器线程：用于模拟器的创建和运行管理；

模块线程：用于根据实车情况，配置不同的模拟器进行模拟汽车运行环境，协助测试。

作为本发明的进一步技术方案：所述PC机模拟汽车CAN总线通信系统与被测试设备之间通过CAN设备连接，设置USB转CAN所使用的硬件。

作为本发明的进一步技术方案：所述模拟器中设置协议的应答，一组模拟至少有请求和应答两个报文组成，可以根据设置的条件，完成模拟交互，对实时性要求比较高的模拟器需要创建单独的线程运行，保证报文的准时发送，提高报文的优先级。

作为本发明的进一步技术方案：所述模拟器的不同功能状态通过状态机转换实现。

作为本发明的进一步技术方案：所述交互通过状态机的方式实现，根据收发包内容进行状态的转换。由于状态机机制需要占用资源，不是每个发包都需要启动状态机，只有需要进行交互的情况才需要创建模拟器的方式进行报文管理。

作为本发明的进一步技术方案：所述状态机需要单独配置，配置内容包含状态个数、每个状态的转换条件、转换的下一个状态、启动、关闭。默认记录交互状态，再次重启动软件系统后，自动恢复原来的交互状态。

作为本发明的进一步技术方案：所述报文格式采用xml、CSV、数据库方式保存。

与现有技术相比，本发明的有益效果是：

本发明是针对软件系统开发过程中的陪试设备不到位的情况下影响项目开发与测试进度，提出了一种PC机上模拟CAN总线ECU通信的方法，提高开发与测试的质量和进度。

附图说明

图1是本发明的线程示意图。

图2是本发明状态机创建流程示意图。

图3是本发明状态机运行流程示意图。

图4是本发明发包线程工作示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

实施例1：

请参照图1,一种PC机模拟汽车CAN总线通信系统，系统主要分成CAN通讯、接口管理、报文处理、模块管理、模拟器管理、虚拟汽车管理、日志管理几个模块组成，下文进行详细描述。

线程划分：

主线程：负责系统启动，设备管理，通讯设置，子线程的创建，线程间通讯设置；

收包线程：负责接收CAN接口的数据，放入到buffer池中缓存起来，报文先进先出；

发包线程：接收其他线程的发包请求进行发包，暂时不设优先级，报文先进先出；

报文解析线程：负责对报文进行解析和流量统计，显示在报文界面和流量统计界面。解析的报文包含收包线程接收的报文和从文件中读取的报文。报文有过滤时，只解析符合条件的报文进行显示。

模拟器线程：模拟器的创建和运行管理。

模块线程：根据实车情况，配置不同的模拟器进行模拟汽车运行环境，协助测试。

实施例2，在实施例1的基础上，

1.主线程：

主线程负责系统启动，设备管理，通讯设置，子线程的创建，线程间通讯设置等。

1.1.设备管理：

软件系统和被测试设备之间通过CAN设备连接，设置USB转CAN所使用的硬件，目前现场使用的都是周立功的产品，型号有USBCAN-II、USBCAN-II+、USBCANFD 2000等不同型号。

设置参数包含设备号、通道号、波特率、数据域波特率、终端电阻、协议类型

每个连接到电脑的CAN接口，在界面显示为一个CAN接口。每个接口单独设置通讯参数，挂载被测试的模块。

后期会存在多个厂家的CAN设备，此处要做好扩展接口。系统统一接口，对应不同厂家时，可以分别设置，但是对系统来说是一台接口。

目前可以在周立功接口上再封装一次。

设备能自动检测到，添加到设备管理列表中，每个设备自动识别出所有的接口，模块管理、收发包等是以接口为基本单位。

选择CAN设备的CAN接口后，可以进行波特率、通道号、模式、自定义波特率等通讯设置。

1.2.界面管理；

主线程负责界面，系统的所有信息都在主线程中显示。

1.3.线程管理；

根据界面上用户的操作和保存的配置，创建和启动不同的线程。设置线程间的通讯机制。当线程不需要时，杀死线程。

1.4.自动模块更新；

模拟工具可以读取服务器上支持的模块功能列表，如果存在自己不支持的功能，可以下载配置文件或者更新自己的程序，进行自动升级。

1.5.初始化流程：

1、开启主线程；

2、读取配置文件；

3、扫描电脑连接的设备，根据配置进行通讯设置；

4、增加模块管理，并将模块和CAN接口绑定；

5、根据模块配置启动模拟器线程；

6、启动报文解析线程；

7、启动收包线程，开始接收CAN接口上面的报文；

8、启动发包线程；

9、启动模块线程，读取配置，将相关模拟器设置为背景，将参数传递给相应的模拟器；

10、主线程设置车辆启动，模块通知模拟器进行发包。

注：如果没有配置，不会有发包行为，收包默认开启接收报文。

2.收包线程：

负责接收CAN接口的数据，放入到buffer池中缓存起来，报文先进先出。

报文接收放置在一个单独的线程中，采用消费者和生产者模式进行报文管理。缓存的报文采用先进先出的队列方式，当有报文接收进来，直接分配内存缓存数据，将数据挂接到队列尾部，完成报文接收，其他线程过来获取报文时，从队列头部读取报文。

2.1.队列缓存：

从CAN接口接收的报文放置在buffer中，队列先进先出，不进行任何解析，收包线程会统计收包个数。报文解析线程读取后，报文从buffer中删除。

如果已经启动保存功能，启动临时线程，不断将数据写入到保存的文件中。

Buffer长度固定，循环覆盖写数据。如果有设置保存到文件和报文解析线程显示，两个都完成后即删除节点，如果都没有按默认方式进行数据覆盖。

2.2.收包操作管理：

收包默认开启，当主程序设置停止时，不再接收报文，同时清空buffer；

3.报文解析线程：

负责对报文进行解析和流量统计，显示在报文界面和流量统计界面。解析的报文包含收包线程接收的报文和从文件中读取的报文。报文有过滤时，只解析符合条件的报文进行显示。

3.1.报文过滤：

报文过滤采用表达式方式，多个过滤表达式可以通过连接符号进行叠加，格式如下：

<字段+过滤符号+过滤值>[表达式连接符<字段+过滤符号+过滤值>]…；

字段：系统支持的报文字段；

过滤符号：支持＝＝、！＝；

过滤值：以字符串方式定义；

表达式连接符：&&、||；

3.2.报文解析流程：

报文解析分阶段解析，按CAN协议报文的段逐次进行，仲裁域、控制域、数据域。主线程中定义报文的格式，在需要时才显示、分析，报文解析流程要缓存所有支持的报文格式，解析后的报文可以在界面显示，可以写入到缓存文件中。

界面显示可以选择只显示发送或接收方向、报文字段过滤等。

3.3.报文保存：

报文格式采用xml、CSV(excel)、数据库方式保存，方便修改和定义。

保存的协议报文文件采用zip压缩并加密方式，扩展名为pcan，不能进行文本模式的发送，可以进行转换成报文发送的文本格式。

文本发送报文格式：

发送报文文件采用文本文件方式，文件扩展名can，报文格式：

|帧间隔时间|帧类型|帧格式|帧ID|帧数据|

帧间隔时间：单位毫秒

帧类型：0标准帧，1扩展帧

帧格式：0数据帧，1远程帧

帧ID：

帧数据：默认8字节

报文增加过滤后，保存的内容可以为过滤后的数据为准，默认为全部数据。

报文显示界面显示文件中的数据时，自动终止从收包线程读取报文，同时通知收包线程停止接收报文。

4.模拟器线程：

模拟器线程管理模拟器的状态，没有界面显示，状态显示在模块线程中。

4.1.模拟器管理：

模拟器中设置协议的应答，一组模拟至少有请求和应答两个报文组成，可以根据设置的条件，完成模拟交互。

对实时性要求比较高的模拟器需要创建单独的线程运行，保证报文的准时发送，提高报文的优先级。

4.2.状态机：

模拟器的不同功能状态通过状态机转换实现。

交互通过状态机的方式实现，根据收发包内容进行状态的转换。由于状态机机制需要占用资源，不是每个发包都需要启动状态机，只有需要进行交互的情况才需要创建模拟器的方式进行报文管理。

状态机需要单独配置，配置内容包含状态个数、每个状态的转换条件、转换的下一个状态、启动、关闭。默认记录交互状态，再次重启动软件系统后，自动恢复原来的交互状态。

4.3.模拟器通信：

模拟器是挂接在模块上面的，通过模拟器的不同状态，组织不同的报文内容到发包线程排队发送。模拟器是否开启，发送什么数据都是模块控制，状态变化后，随时更新模块的状态。

模块线程通过配置的模块，读取模块的状态，呈现给用户。

5.发包线程：

发包线程专门管理报文的发送，模拟器线程组织好报文后，发送给发包线程排队发送。报文区分优先级，高级别的报文先发送，发送完成后再发送低级别的报文，因为报文是区分服务质量QoS的。

如图4，报文先发送队列1的报文1，队列1报文发送完成后发送队列2的报文1和报文2，最后再发送队列3的报文，如果队列3的报文还没有发送完成，队列1又增加了一个报文，则在队列3的当前报文发送完成后，立即转到队列1进行报文发送。

发送完成的报文会标记为已发送，并通知到报文解析线程，报文解析线程接收完毕后通知发包线程，报文从发包线程队列中删除，完成资源的释放。

6.模块线程：

模块线程可以根据情况拆分，当前先支持一个线程，将所有模块的运行状态都加载在该线程中，后续可以考虑扩展。

6.1.模块管理：

根据模块确定报文的定义，同时模块也进行层级的分类。如空调、雷达等大类，里面还会细分不同的小类，小类里面还有可能再次细分，最后到具体的属性节点，属性节点中定义不同的参数，每个参数定义不同的固定值、连续值、单个值等。

模块节点关系需要进行组织和显示，模块属性需要进行设置和显示。

属性节点：

属性节点定义模块的属性信息，属性节点从属于下面定义的层级根节点中类别。层级根节点和其子节点都可以添加属性节点。

属性节点包含：属性名称，取值范围，枚举值，默认值，报警阈值；

属性节点确定报文的数据格式，根据取值确定数据域的值，需要提供默认的发包方式。

模块节点：

模块节点定义模块之间的关联关系，没有父节点的模块节点是根节点，有父节点和子节点的模块节点是中间节点，模块节点子节点可以是模块节点，也可以是属性节点。模块层级是中间节点，模块属性是最小的模块单元，模块属性中有不同的参数，参数可以设置不同类型的值，这些都需要通过规则方式进行规划，进行灵活配置。

模块节点跟CAN接口关联后，从指定的CAN接口收发报文。

6.2.协议报文定义：

定义CAN报文的格式，每种报文除CAN协议定义的标准字段不需要别名外，自定义数据都可以定义别名，每个字段采用TLV格式，分别定义每个字段的类型，长度(按bit) 和默认值。

报文本身可以定义别名和标识，标识方便查询，别名在报文解析时使用。

报文跟模块节点关联，发送方式和顺序由模拟器设定。

6.3.虚拟汽车：

虚拟汽车配置一些整车的信息，如车型ID，汽车电源状态等。

虚拟汽车上进行当前测试使用的环境模块和测试模块的配置，系统只支持一个实例。

虚拟汽车作为一个实体来配置；

模块线程可以虚拟汽车类型，根据车型ID，可以支持车型对应的模块功能。

6.4.背景设置：

模拟工具需要模拟真实的环境，有些报文交互是一直存在的，如发动机启动、车速、转速等周期或事件报文，不同的车型会存在差异，需要进行区分配置。

背景设置时，从前面配置好的模块中进行选择，设置运行方式即可，不需要特殊管理。

6.5.仿真模拟：

界面上选中整车时，显示背景模块的实时状态，选中某个模块时，显示被选中模块的实时状态和模拟图形。能交互的图形按键，点击之后可以正常模拟实车上实体按键的报文发送。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (7)

1.一种PC机模拟汽车CAN总线通信系统，其特征在于，

该PC机模拟汽车CAN总线通信系统包括：

主线程：用于系统启动，设备管理，通讯设置，子线程的创建，线程间通讯设置；

收包线程：用于接收CAN接口的数据，放入到buffer池中缓存起来，报文先进先出；

发包线程：用于接收其他线程的发包请求进行发包，暂时不设优先级，报文先进先出；

报文解析线程：用于对报文进行解析和流量统计，显示在报文界面和流量统计界面，解析的报文包含收包线程接收的报文和从文件中读取的报文，报文有过滤时，只解析符合条件的报文进行显示；

模拟器线程：用于模拟器的创建和运行管理；

模块线程：用于根据实车情况，配置不同的模拟器进行模拟汽车运行环境，协助测试。

2.根据权利要求1所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述PC机模拟汽车CAN总线通信系统与被测试设备之间通过CAN设备连接，设置USB转CAN所使用的硬件。

3.根据权利要求2所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述模拟器中设置协议的应答，一组模拟至少有请求和应答两个报文组成，根据设置的条件，完成模拟交互，对实时性要求比较高的模拟器需要创建单独的线程运行，保证报文的准时发送，提高报文的优先级。

4.根据权利要求3所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述模拟器的不同功能状态通过状态机转换实现。

5.根据权利要求4所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述交互通过状态机的方式实现，根据收发包内容进行状态的转换。由于状态机机制需要占用资源，不是每个发包都需要启动状态机，只有需要进行交互的情况才需要创建模拟器的方式进行报文管理。

6.根据权利要求3所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述状态机需要单独配置，配置内容包含状态个数、每个状态的转换条件、转换的下一个状态、启动、关闭。默认记录交互状态，再次重启动软件系统后，自动恢复原来的交互状态。

7.根据权利要求1所述的一种PC机模拟汽车CAN总线通信系统，其特征在于，所述报文的格式采用xml、CSV、数据库方式保存。

Images