郭健忠 ,胡文龙 ,谢斌 ,闵锐 ,杜新宝 ,王迅
(1.武汉科技大学汽车与交通工程学院,湖北 武汉 430065;2.武汉保华显示科技有限公司,湖北 武汉 430082)
随着汽车智能化的到来,汽车功能不断丰富,车上控制器的数量也随之增多。作为汽车控制器之间的主要通讯网络,CAN(Controller Area Network)总线上的信息交互愈加频繁,需要解析处理的CAN 报文信息也越来越多[1-4]。面对逐渐增多的CAN 报文信息,采用单报文逐一解析的传统解析方式出现了一系列的问题,例如,由于CAN 报文数据增多而导致的解析代码量大、解析框架复杂、可移植性差、稳定性不高等一系列缺点[5-6],直接增加了汽车仪表的开发周期,并降低了汽车仪表数据显示的准确性,可能导致最终开发产品的质量不达标。因此,传统CAN 报文信息解析的方式逐渐满足不了当前的产品开发需求,有必要设计出一种针对大量CAN 报文信息的解析方式。
在对CAN 报文信息进行解析时,通常是对数据帧中所包含的数据段进行解析。数据帧具有两种格式,即标准帧格式和扩展帧格式。两种数据帧格式主要区别在于标识符的长度不同,标准帧标识符为11 位,扩展帧标识符为29 位,因此,与标准帧相比,扩展帧可以扩展更多的CAN 节点,更好地支持上层协议[7-8]。在数据解析方面,两种帧格式并无较大差别。由于商用车ECU 所需传输信息较多,CAN 报文多用扩展帧,乘用车多用标准帧。
传统CAN 报文解析采用单个报文依次解析的方式。其解析过程主要包括报文名称定义、报文接收邮箱配置、报文丢失信息处理和报文信息解析四个步骤[9-11]。汽车仪表,作为主要的CAN 数据收发设备,其CAN 报文解析的具体流程如图1 所示。
图1 CAN 单报文解析流程图
在新款汽车的研发过程中,ECU 的品牌往往具有多个选择。因此,为提升汽车仪表对不同ECU 品牌间数据传递的兼容性,通常需对多种品牌ECU 的CAN 报文进行解析,所以在报文名称定义时,需考虑多个ECU 品牌,并分品牌进行定义。在配置接收邮箱时,由于接收邮箱数目有限,会添加标识符过滤处理,即通过相应掩码操作将不同报文信息同时存入同一邮箱中[12-14]。报文丢失信息处理是当ECU故障未发送报文或报文丢帧过多而造成的信息丢失时所做出的应急处理。报文信息解析即对报文数据中包含的ECU 工况信息进行相应代码编写。
在传统CAN 报文解析过程中,通常按照图1 所示流程进行单个报文逐一解析,解析工作量大,所需解析的时间成本较高。若接收邮箱数目不足,涉及过滤处理时,解析代码结构框架将变得复杂,解析过程易出错,整体项目工程的稳定性和可移植性将会降低。因此,传统CAN 报文解析方式逐渐满足不了当前汽车仪表的开发需求。
基于相似性原理对报文的解析代码进行分析,将其解析代码中的相似逻辑结构、相似报文ID 定义等相似结构提取出来[15],按照开发者的解析要求进行代码框架的自动生成,所生成的解析代码框架可直接导入整体软件的开发工程中使用。根据CAN单报文解析流程可知,进行单报文解析时,以下三步解析操作相似度较高:
①在参照功能规范编写解析代码之前,需要在接收邮箱结构体中添加该报文ID(若接收邮箱已存满报文信息,则需要进行掩码操作)。
②在参照功能规范编写解析代码之前,还需在报文丢失处理的枚举结构中添加枚举定义。
③在参照功能规范编写解析代码时,为实时接收来自接收邮箱中的报文信息,进行报文解析,需先构建相应报文的接收代码框架,即接收条件语句(若包含掩码操作,则需在接收条件语句中进一步判断)。
以某商用车仪表开发中不同型号发动机CAN报文解析为例,相似接收邮箱结构体代码框架如下。在接收邮箱结构体代码框架中,结构体的名称可自定义。所接收的报文信息存储在相应的结构体数组中,数组成员具体包括邮箱序号、报文帧类别、所存储报文的ID 和过滤处理,其中邮箱序号前缀信息和报文帧类别均可自定义,结构体数组最多不超过32 个。
相似枚举结构如下所示。在报文丢失处理枚举结构中,枚举名称可按报文对应的ECU 名称进行自定义,枚举成员在能体现报文对应ID 的前提下也可进行自定义。
相似CAN 报文解析代码框架如下所示。在CAN 报文解析时,对接收邮箱仅存单一报文的解析代码框架,仅需通过一个接收条件语句即可达到实时接收报文效果,之后在条件语句中参照功能规范内容进行报文信息解析。若有掩码操作,则先处理接收邮箱整体报文的接收条件语句,再进一步对内部条件语句进行逐一处理[16]。参照功能规范所做的功能解析在内部条件语句中进行。在带有掩码处理的两帧报文解析代码框架中,含有掩码操作的报文解析框架可根据掩码需要,进行多个子报文接收条件语句的解析操作。
根据以上分析可知,可利用相似性原理,对CAN 报文解析代码中的枚举结构、接收邮箱结构体以及相似的代码解析框架进行同时解析,相比传统的CAN 报文解析策略,基于相似性原理的报文解析具有解析时间成本低、代码结构可视性更高、解析出错率更低的优点。为实现该解析策略,设计了一种CAN 报文解析辅助软件,用于提高开发者的报文解析效率。
根据CAN 报文解析相似逻辑结构分析可知,该辅助软件需要设计获取CAN 报文基本信息以及掩码信息的输入模块,其中CAN 报文基本信息包括CAN 报文类型、ID、功能备注等;掩码信息包括掩码报文类型、主ID、子ID 等。还需设计生成相似解析代码文件的输出模块,生成文件中包括枚举结构文件、接收邮箱文件和代码解析文件。为检测所获取CAN 报文基本信息的准确性,并使得软件使用者对所获取信息有整体认知,需设计基本信息显示模块。为方便软件使用者对生成代码框架,以及生成文件格式的自定义,还需设计用户自定义配置模块。辅助软件总体设计框架如图2 所示。
图2 软件总体设计框架图
在对一款功能性软件的开发过程中,往往需要通过对其功能需求进行分析,选择恰当的开发语言及编译环境,利用开发语言及其编译环境的优点,来简化开发过程,提高软件的开发效率。通过对软件的设计思路分析可知,在获取CAN 报文基本信息时,涉及相应信息的分类存储及输出,以及需设计用户可自定义配置的UI 界面。
C#语言是一种面向对象的编程语言,可按开发者意愿,对不同对象信息进行类定义,并可按类定义进行数据的存储,其编译环境Visual Studio 中强大的Windows 窗体应用(.NET Framework)工作台,可进行可视化的图形交互界面开发,诸多窗体类型以及公共控件为软件的UI 界面设计提供了操作上的便捷[17-18]。因此,为了满足所需的功能,本文采用C#语言在Visual Studio 中的Windows 窗体应用工作台上进行辅助软件的开发。
在获取CAN 报文基本信息以及掩码信息时,为便于所需信息的提取,需制定相应的信息填写规范。CAN 报文基本信息填写规范如表1 所示,其中包含生成相似代码所需的CAN 报文ID、周期和报文类型三点必须信息,以及报文信息备注选填信息。掩码信息填写规范如表2 所示,其中包含生成掩码所需的报文类型以及软件使用者指定的主ID 和子ID。考虑到所提取信息量较大,为降低解析信息文件工作难度,故输入文件均采用Excel 表格中以逗号进行信息分割的.CSV 文件格式。
表1 CAN 报文基本信息填写规范
表2 接收邮箱掩码添加规范
对于输入文件中的信息提取过程设计,Visual Studio 中的Windows 窗体应用工作台为开发者提供了可视化的开发环境。以CAN 报文基本信息的提取为例,可视化开发过程如图3 所示。点击“打开指定CSV 文件”的button 控件,即可触发打开指定CSV 文件的操作,并将其文件地址返回至textbox 控件进行地址显示。通过对CAN 报文基本信息的分析,构建相应类结构和列表结构,并将其信息分类存储在列表中,供其他功能模块调用,列表存储过程如图4 所示。
图3 文件信息提取可视化开发
图4 列表结构数据存储过程
在不同的项目开发中,开发者所使用的开发环境以及所需解析的CAN 报文类型也会有所不同,为提高辅助软件开发环境的兼容性,需在一定程度上实现软件使用者对生成解析文件的自定义。在生成解析代码框架方面,根据CAN 报文解析相似逻辑结构分析可知,可对其解析报文种类、接收邮箱结构体名称、邮箱数目、报文丢失处理枚举结构名称和解析条件判断语句五个方面进行自定义,同时解析过程中涉及到的状态变量名称也可进行自定义;在生成文件方面,可按开发者需求,对生成的文件格式进行自定义,以便导入不同的开发环境。其自定义界面初步设计如图5 所示。
图5 自定义配置界面
通过输入模块对掩码信息文件进行提取之后,软件使用者指定掩码操作的报文主ID 和子ID 已对应存入数据列表中,供生成掩码调用。在对CAN 报文主ID 和子ID 进行过滤生成掩码时,通常采用同或运算,其运算逻辑如表3 所示。
表3 同或运算真值表
在对掩码进行运算时,首先将数据列表中存储的每组报文十六进制的主ID 与子ID 进行遍历对比,得到数值不同的位。接着将这些不同位上的数值进行二进制转换,并分别进行同或逻辑运算,得到不同位的掩码值。最后将掩码值转换为十六进制,并添加上相同位的掩码值即可得到十六进制掩码。以某汽车仪表开发中发动机PTO 指示灯报文(ID:18FEF100) 和缓速器故障指示灯报文(ID:18FEF500)为例,掩码运算过程如图6 所示。
图6 掩码运算过程示意图
本文采用C#语言在Visual Studio 中的Windows窗体应用工作台上进行辅助软件的开发,开发过程中主要涉及两个界面,一是软件UI 设计界面,二是程序编辑界面,两个界面相互配合使用,实现了软件开发的可视化。其UI 设计界面的工具箱模块中包含了大量便捷的控件、组件等工具,使用时,仅需在工具箱中点击相应工具名称,之后可随意且多次地拖动到设计界面的任何位置,以满足界面的设计需求。双击设计界面上相应的图标即可索引到对应程序编辑界面中的指定功能函数位置,便于功能代码的编辑。以“生成文件”的button 按钮为例,其UI设计流程如图7 所示。
图7 button 组件UI 设计流程图
参照button 组件的设计方法,类似地可设计出其他相应功能的组件UI,最终,本文使用C#语言在Visual Studio 中的Windows 窗体应用工作台开发的辅助软件UI 界面效果如图8 所示。
图8 辅助软件UI 设计效果图
在完成CAN 报文解析辅助软件的设计之后,为验证其可在开发工程项目的使用中达到预期设计效果,本文以某商用车汽车仪表(如图9 所示)开发中CAN 报文解析模块为例。该商用车仪表预期设计可兼容六个品牌ECU,具体报文信息如表4 所示。在CAN 信号输入方面,项目采用Kvaser 测试仪与BUSMASTER 测试软件配合使用,对仪表进行CAN信号的模拟发送。
图9 商用车仪表实测图
由表4 可知,某商用车仪表兼容品牌YC 的ECU 共有32 条CAN 报文信息,项目开发指定邮箱数目为20。辅助软件功能测试以品牌YC 中发动机PTO 指示灯报文(ID:18FEF100)和缓速器故障指示灯报文(ID:18FEF500)解析为例(前者为主ID,后者为子ID)。按图10 所示流程进行解析。首先将Kvaser 测试仪与BUSMASTER 软件连接,搭建CAN报文模拟发送平台[19];接着导入辅助软件生成的YC 品牌报文解析代码文件,并按照功能规范进行代码解析;之后在BUSMASTER 软件中配置PTO 指示灯报文和缓速器故障指示灯报文显示信息;最后通过工程仿真验证所生成的解析框架能否接收到CAN 报文信息,仿真结果及仪表指示灯显示如图11、图12 所示。
表4 某商用车仪表所兼容ECU 品牌的报文信息
图10 辅助软件测试流程图
图11 报文接收工程仿真
图12 CAN 报文信息发送前后仪表状态对比
通过以上测试结果可以看出,使用CAN 报文辅助软件生成的含有掩码操作的解析文件可直接导入项目工程中进行使用,并且能够获得正确功能效果。
参照4.2 所示测试流程,对与该商用车仪表兼容的其他五个品牌的ECU 报文分别进行解析。若将解析邮箱结构体内的1 个数组、解析代码框架中的1 个条件语句和1 个变量处理语句均定义为1 个解析复杂度,则对该仪表开发解析6 个品牌ECU 报文信息,其传统解析策略与基于相似性原理的解析策略解析复杂度对比如表5 所示。其中,相似性原理解析复杂度仅需计算自定义模板的复杂度,其他解析内容按模板自动生成,即模板的复杂度为11;传统解析复杂度为:邮箱数目+报文数目*3+掩码邮箱数目。
经对比可知,使用基于相似性原理设计的CAN报文解析辅助软件解析报文,平均每个ECU 品牌报文解析的复杂度缩减为传统解析策略的8.8%,且省去掩码计算过程,极大地节省了解析报文所需的时间成本,并提升了整体解析代码框架的稳定性。
本文根据相似性原理,结合CAN 报文解析代码编写的结构相似特点,提出了基于相似性原理的CAN 报文解析策略,并设计了一种CAN 报文解析辅助软件。本文有以下创新点和特色:
(1)根据相似性原理设计的CAN 报文解析辅助软件具有解析代码生成效率高、生成代码框架清晰的特点。测试可知,其生成的解析文件导入项目工程的稳定性较高,且解析时间减少至传统解析方式的8.8%,极大地节省了大量CAN 报文解析所需的时间。
(2)在设计生成代码框架过程中,根据代码框架的主流结构,较大程度上实现了软件使用者结构的自定义,并结合不同文件格式的生成,所生成的解析文件具有一定的开发环境兼容性,为后续简化CAN 解析模块的开发提供了经验。