CN116016024A - can报文的封装系统 - Google Patents

Abstract

本发明涉及汽车电子领域，具体涉及can报文的封装系统，包括：车机、微控制单元；车机包括应用层和中间件；中间件用于接收来自于应用层的业务指令，并按照预先设置的报文格式封装为第一can报文，发送至微控制单元；还用于接收来自于微控制单元的第二can报文，将第二can报文解析成can数据，并发送至应用层；微控制单元用于接收并解析第一can报文，并将解析后得到的控制指令发送至电子控制单元；微控制单元还用于从电子控制单元获取状态信息并按照报文格式封装为第二can报文。本发明引入中间件收到控制指令后会根据报文格式将其封装成can报文，微控制单元收到can报文后解析得到控制指令透传至电子控制单元即可。采用本系统可大大缩短can报文解析的周期，有效提高can报文解析的效率。

Description

can报文的封装系统

技术领域

本发明涉及汽车电子领域，具体涉及can报文的封装系统。

背景技术

整车can(Controller Area Network，控制器局域网络)总线是汽车域间通信的重要数据通路，承担着汽车内部各种电子控制单元(Electronic Control Unit，ECU)的运作职责。通常在can总线上会有一个专门的单片机做路由，将各种can报文解析分发到对手端，比如座舱车辆接口单元(Vehicle interface unit，VIU)，车控VIU。车机内空调，车辆设置，场景模式等众多应用根据解析过的can报文获取到所需要的信息，或是将自身的信号包装成can报文下发，当然这些对can报文的复杂处理并不在应用内部进行，这时就需要一个专门的模块进行can报文的解析，组装，分发。而根据车型项目的不同，整车can报文矩阵也有不小的差异，在业务逻辑层对can报文的解析和分发往往需要耗费开发人员巨大的精力，而且代码不具有适配多种车型的能力。现有技术中can报文的封装系统逐帧读取can报文，对于单个或少量DBC(Database Can，CAN数据库)文件操作起来或许并不麻烦，但当大量can报文上传时处理起来较为繁琐，在周期性can报文中，还需要对特定信号清零处理，如果考虑周期上传，微控制单元(Microcontroller Unit，MCU)就需要维持一个庞大的数据表来存储can信号值，这对于低频，内存有限的MCU来说容易过载。

发明内容

鉴于以上所述现有技术的缺点，本发明提供can报文的封装系统，引入通信中间件并根据报文格式将指令封装成can报文，MCU只需要根据报文格式对can报文进行解析，简化MCU功能，以解决上述技术问题。

本发明提供的can报文的封装系统，包括：车机、微控制单元；所述车机包括应用层和中间件；

所述应用层用于向所述中间件发送业务指令；

所述中间件用于接收来自于所述应用层的业务指令，并将所述业务指令按照预先设置的报文格式封装为第一can报文，并发送至所述微控制单元；还用于接收来自于所述微控制单元的第二can报文，将第二can报文解析成can数据，并发送至所述应用层；

所述应用层还用于接收所述can数据；

所述微控制单元用于接收并解析所述第一can报文，并将解析后得到的控制指令发送至电子控制单元；

所述微控制单元还用于从所述电子控制单元获取状态信息并按照所述报文格式封装为第二can报文发送至所述中间件。

于本发明的一实施例中，当所述中间件接收到所述业务指令时，将所述业务指令的can标识和报文内容按照所述报文格式封装为所述第一can报文。

于本发明的一实施例中，所述中间件根据所述can标识获取对应的清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔，并将所述can标识、所述报文内容、所述清零的起始位、所述清零的数据长度、所述清零前要发送的帧数和所述清零前发送的帧间隔按照所述报文格式封装为所述第一can报文。

于本发明的一实施例中，所述中间件按照如下步骤进行第一can报文封装：

将所述业务指令中的can标识填入第一can报文的字节0至字节1；

将所述业务指令中的报文内容填入第一can报文的字节2至字节9。

于本发明的一实施例中，所述中间件按照如下步骤进行第一can报文封装：

将所述业务指令中的can标识填入第一can报文的字节0至字节1；

将所述业务指令中的报文内容填入第一can报文的字节2至字节9；

将所述业务指令中要清零的起始位填入第一can报文的字节10至字节11；

将所述业务指令中要清零的数据长度填入第一can报文的字节12至字节13；

将所述业务指令中清零前要发送的帧数填入第一can报文的字节14至字节15；

将所述业务指令中清零前发送的帧间隔填入第一can报文的字节16至字节17。

于本发明的一实施例中，所述微控制单元获取到所述状态信息后，将所述状态信息的can标识和报文内容按照所述报文格式封装为第二can报文。

于本发明的一实施例中，所述微控制单元按照如下步骤进行第二can报文封装：

将所述状态信息中的can标识填入第二can报文的字节0至字节1；

将所述状态信息中的报文内容填入第二can报文的字节2至字节9。

于本发明的一实施例中，所述应用层还用于向中间件发送获取状态指令；

所述中间件还用于按照所述报文格式将所述获取状态指令封装为获取状态can报文，并发送至所述微控制单元；

所述微控制单元还用于接收并解析所述获取状态can报文并根据解析后的获取状态内容向所述电子控制单元获取所述状态信息。

于本发明的一实施例中，所述中间件根据所述获取状态指令的can标识获取变化的起始位和变化的报文长度，并将所述can标识、所述变化的起始位和所述变化的报文长度按照所述报文格式封装为所述获取状态can报文。

于本发明的一实施例中，所述中间件按照如下步骤进行获取状态can报文封装：

将所述获取状态指令的can标识填入获取状态can报文的字节0至字节1；

将所述获取状态指令中变化的起始位填入获取状态can报文的字节2至字节3；

将所述获取状态指令中变化的报文长度填入获取状态can报文的字节4至字节5。

本发明的有益效果：本发明引入中间件将业务逻辑与封装格式相区分，上层APP不用关心底层can信号格式。中间件承接应用层的控制指令，收到指令后会根据不同的can标识将其原始数据和控制信息根据报文格式进行封装。MCU不再需要维护一个动态表，收到can报文后只需要根据报文格式解析得到控制指令透传至电子控制单元即可，简化了MCU功能。采用这一系统可大大缩短can报文解析的周期，有效提高can报文解析的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术者来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。在附图中：

图1是本发明的实施例所提供的can报文的封装系统的结构示意图；

图2是本发明的实施例所提供的can报文的封装系统的can报文封装格式示意图；

图3是本发明的实施例所提供的can报文的封装系统的can数据矩阵示意图；

图4是本发明的实施例所提供的can报文的封装系统的应用示意图；

图5是本发明的实施例所提供的can报文的封装系统的现有can报文示例图。

具体实施方式

以下将参照附图和优选实施例来说明本发明的实施方式，本领域技术人员可由本说明书中所揭露的内容轻易地了解本发明的其他优点与功效。本发明还可以通过另外不同的具体实施方式加以实施或应用，本说明书中的各项细节也可以基于不同观点与应用，在没有背离本发明的精神下进行各种修饰或改变。应当理解，优选实施例仅为了说明本发明，而不是为了限制本发明的保护范围。

需要说明的是，以下实施例中所提供的图示仅以示意方式说明本发明的基本构想，遂图式中仅显示与本发明中有关的组件而非按照实际实施时的组件数目、形状及尺寸绘制，其实际实施时各组件的型态、数量及比例可为一种随意的改变，且其组件布局型态也可能更为复杂。

在下文描述中，探讨了大量细节，以提供对本发明实施例的更透彻的解释，然而，对本领域技术人员来说，可以在没有这些具体细节的情况下实施本发明的实施例是显而易见的，在其他实施例中，以方框图的形式而不是以细节的形式来示出公知的结构和设备，以避免使本发明的实施例难以理解。

Can网是一种总线协议，其具有成本低、速度快、实时性好和可靠性高等特点，被广泛应用于车辆领域。车机的显示用户使用界面(Employ Display Consumer，EDC)接入整车can网，EDC域的各大业务板块包括，车身控制(Cabin)，空调(Heating,Ventilation andAir Conditioning，HVAC)，高级驾驶辅助系统(Advanced Driving Assistance System，Adas)，行车记录仪(Digital Video Recorder，Dvr)，全景影像(Earth VolumetricStudio，EVS)等，can网主要负责将EDC内各业务板块释放的信号转发到车身终端各ECU，以及将CAN网上收到的各ECU反馈状态转发到EDC的各业务板块。

图1是本发明的实施例所提供的can报文的封装系统的结构示意图。应理解的是，该系统也可以适用于其它的示例性实施环境，并由其它实施环境中的设备具体执行，本实施例不对该系统所适用的实施环境进行限制。

本发明实施例提供了can报文封装系统，所述系统包括车机、MCU；所述车机包括应用层和中间件。

具体地，参见图1所示，是本发明提供的can报文的封装系统的一个优选实施例的结构示意图，can报文的封装系统主要设置于智能座舱控制域中，主要由车机10、MCU20组成；所述车机10包括应用层11和中间件12；

所述应用层11用于向所述中间件12发送业务指令；

所述中间件12用于接收来自于所述应用层11的业务指令，并将所述业务指令按照预先设置的报文格式封装为第一can报文，并发送至所述MCU20；还用于接收来自于所述MCU20的第二can报文，将第二can报文解析成can数据，并发送至所述应用层11；

所述应用层11还用于接收所述can数据；

所述MCU20用于接收并解析所述第一can报文，并将解析后得到的控制指令发送至ECU；

所述MCU20还用于从所述ECU获取状态信息并按照所述报文格式封装为第二can报文发送至所述中间件12。

在一具体实施例中，当所述中间件12接收到所述业务指令时，将所述业务指令的can标识(Identification，ID)和报文内容按照所述报文格式封装为所述第一can报文。

在一具体实施例中，所述中间件12根据所述canID获取对应的清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔，并将所述canID、所述报文内容、所述清零的起始位、所述清零的数据长度、所述清零前要发送的帧数和所述清零前发送的帧间隔按照所述报文格式封装为所述第一can报文。

在一具体实施例中，所述MCU20获取到所述状态信息后，将所述状态信息的can ID和报文内容按照所述报文格式封装为第二can报文。

应用层11将携带控制指令的业务指令发送至中间件12；中间件12将业务指令中的can ID和报文内容按照报文格式进行封装，若业务指令为周期性数据，则中间件12根据canID获取对应的清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔，将canID、报文内容、清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔按照报文格式封装为第一can报文并发送至MCU20；MCU20根据报文格式对第一can报文解析得到控制指令，将控制指令发送至ECU实现控制目的。

MCU20将从所述ECU获取的状态信息中的canID和报文内容按照所述报文格式封装为第二can报文发送至中间件12；中间件12将第二can报文解析成can数据，并发送至所述应用层11；应用层11接收can数据。

MCU20从ECU获取的状态信息可以是ECU主动向车机10发送如附图3所示的can数据时发送，也可以是车机10需要使用图3中的can数据时，MCU20根据获取状态内容从ECU中获取。

在一具体实施例中，所述应用层11还用于向中间件12发送获取状态指令；

所述中间件11还用于按照所述报文格式将所述获取状态指令封装为获取状态can报文，并发送至所述MCU20；

所述MCU20还用于接收并解析所述获取状态can报文并根据解析后的获取状态内容向所述ECU获取所述状态信息。

在一具体实施例中，所述中间件12根据所述获取状态指令的can标识获取变化的起始位和变化的报文长度，并将所述can标识、所述变化的起始位和所述变化的报文长度按照所述报文格式封装为所述获取状态can报文。

结合附图3所示矩阵，应用层11需要获取图3中所示can数据时，将携带对应canID的获取状态指令发送给中间件12；中间件12根据获取状态指令中的canID获取对应的变化的起始位和变化的报文长度，将canID、对应的变化的起始位和变化的报文长度封装成获取状态can报文并发送至MCU20；MCU20根据报文格式对获取状态can报文解析得到获取状态内容，将获取状态内容发送至ECU以获取can数据。

本申请中应用层11从EDC获取应用的业务指令或获取状态指令；MCU20通过can总线将控制指令或获取状态内容发送至各个ECU，或通过can总线从各个ECU获取状态信息。中间件12处于本地服务层，对上通过JNI\HIDL方式与应用层11通信，对下通过串口与MCU20通信。

本发明引入的中间件12将业务逻辑与封装格式相区分，应用层11不用关心can报文的格式，只用知道自己的业务功能，需要什么信息或实现什么功能时就告诉中间件12。中间件12承接应用层11的控制指令，收到指令后会根据不同的canID将其原始数据和控制信息根据报文格式进行封装。MCU20收到can报文后只需要根据报文格式解析得到控制指令透传至电子控制单元即可，相较于传统做法中MCU20需要通过维护一个实时变化的动态数据表来存储can信号，简化了MCU20功能。采用这一系统可大大缩短can报文解析的周期，有效提高can报文解析的效率。

结合图2所示的本发明的实施例所提供的can报文的封装系统的can报文封装格式示意图进行报文的封装与解析。

在一具体实施例中，所述中间件12按照如下步骤进行第一can报文封装：将所述业务指令中的can标识填入第一can报文的字节0至字节1；将所述业务指令中的报文内容填入第一can报文的字节2至字节9。

在一具体实施例中，所述中间件12按照如下步骤进行第一can报文封装：将所述业务指令中的can标识填入第一can报文的字节0至字节1；将所述业务指令中的报文内容填入第一can报文的字节2至字节9；将所述业务指令中要清零的起始位填入第一can报文的字节10至字节11；将所述业务指令中要清零的数据长度填入第一can报文的字节12至字节13；将所述业务指令中清零前要发送的帧数填入第一can报文的字节14至字节15；将所述业务指令中清零前发送的帧间隔填入第一can报文的字节16至字节17。

中间件12根据业务指令判断指令的功能与类型，若业务指令为周期性，则根据业务指令的canID获取对应清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔，并将canID、报文内容对应清零的起始位、清零的数据长度、清零前要发送的帧数和清零前发送的帧间隔依次填入报文对应位置，其中清零的数据长度以比特为单位，清零前发送的帧间隔以毫秒为单位；将封装后的第一can报文发送至MCU20。

在一具体实施例中，所述MCU按照如下步骤进行第二can报文封装：将所述状态信息中的can标识填入第二can报文的字节0至字节1；将所述状态信息中的报文内容填入第二can报文的字节2至字节9。

MCU20根据状态信息，将其canID和报文内容填入对应字节以封装成第二can报文并发送至中间件12。

在一具体实施例中，所述中间件按照如下步骤进行获取状态can报文封装：将所述获取状态指令的can标识填入获取状态can报文的字节0至字节1；将所述获取状态指令中变化的起始位填入获取状态can报文的字节2至字节3；将所述获取状态指令中变化的报文长度填入获取状态can报文的字节4至字节5。

中间件12根据获取状态指令中的canID获取其对应的变化的起始位和变化的报文长度，并将can标识、变化的起始位和变化的报文长度依次填入获取状态can报文对应的字节，其中变化的报文长度以比特为单位，字节0为高字节；将封装后的获取状态can报文发送至MCU20。

图4是本发明的实施例所提供的can报文的封装系统的应用示意图。图5将本发明的具体实施例的系统与实施流程结合，更好地帮助理解本发明的实施过程。

在一具体实施例中，以空调控制为例，驾驶员通过语音控制或触摸车机显示屏面板发出业务指令，HVAC模块向下传递至应用层，应用层注册接口的回调，绑定注册终端之后将指令传递给中间件，该模块解耦can报文的业务逻辑与can报文格式，在该模块内部将操作系统的业务指令转换成经过特定格式封装的第一can报文包发送给MCU20，车机10与MCU20通过串口相连，MCU20只需采用静态代码就可根据图2的报文格式对不同can信号进行处理后发送至HVAC ECU。

用户通过语音控制或按压触摸屏调节温度；

HVAC生成原始数据，数据格式如下：

温度设置：0x01＝LO；(17.5)0x02-0x1E＝18～32℃；0x1F＝HI；(32.5)

温度读取：0x01＝LO；0x02-0x1E＝18～32℃；0x1F＝HI；

(此时数据为简单的业务数据。)

HVAC通过调用应用层11提供的jar(Java Archive，软件包文件格式)包，调用jar包的接口。

本例为：set Property(int prop，int num)；进行温度设置

参数prop为应用层11使用的接口ID，其定义如下：

public static final int ID_MIRROR_DEFROSTER_ON＝0x124f050c

通过十六进制四个字节的propertyID来唯一确定中间件12中can报文所携带的一个业务功能。(e.g.这个接口ID代表一个具体的业务功能----设置温度，这部分代码只用将业务功能定义为一个int型常量，极其相似，所以可以通过python自动生成。)

参数num为温度设置值，取值范围：

温度设置：0x01＝LO；(17.5)0x02-0x1E＝18～32℃；0x1F＝HI；(32.5)

温度读取：0x01＝LO；0x02-0x1E＝18～32℃；0x1F＝HI；

调用的jar包会转发到应用层11，此时透传的数据依旧只包括简单的业务数据，通过进程间通信方式调入中间件12，中间件12通过报文格式将业务数据组合到第一can报文中，再通过串口通信发送给MCU20，MCU20通过解析第一can报文将得到的控制指令上传到can总线，通过can总线发送至ECU以实现整车通信。

由于中间件12的存在，可以将业务逻辑和报文封装格式的功能逻辑解耦，上层应用不需要知道具体can报文的封装格式，并且由于引入了一层报文格式的封装，也简化了MCU20的处理工作。

下面展示中间件12对业务数据的封装：

PropertyID对应附图3中的一行，附图3中所有行公用一个ID(2d51)，说明它们都在一个can报文中,因此我们定义第一can报文格式为：

表Map<int，byte[]>map；

表用来存放各个can报文，其中的value为字节数组，用来存放一个can报文中的数据内容。

首先通过propertyID确定canID。

得到canID后结合控制信息和数据内容进行第一can报文封装，控制信息本例是set，代码如下：

根据附图3中signal start bit和signal length可以知道在字节数组种的起始位和长度，这里假设signal start bit为8，signal length为也为8，故这里在第二字节Byte(1+2)填入；

如上即可将数据封装到第一can报文的map中，调用comm_mcu(Map[can ID]，MOD_3)将封装后的第一can报文发送给MCU20，第二个参数MOD_3代表can报文下传。

MCU20根据附图2报文格式进行解析封装，共有三种控制方式：

<1>获取状态can报文：用来向MCU20获取车机10所需的can数据，MCU20根据

Byte[0]-Byte[1]：字节内容获得需要MCU20获取的canID；

Byte[2]-Byte[3]：字节内容获得变化的起始位；

Byte[4]-Byte[5]：字节内容获得变化的报文长度；

通过解析此条获取状态can报文，MCU20会在从can总线收到对应的can数据后传给车机10。

(变化上传和非变化上传皆可)

<2>第二can报文：MCU根据

Byte[0]-Byte[1]：字节内容获得报文的canID；

Byte[2]-Byte[9]：字节内容获得报文内容；

通过封装并发送此条第二can报文，车机10可接收MCU20返回的can数据。

<3>第一can报文：相当于设置指令

Byte[0]-Byte[1]：canID；

Byte[2]-Byte[9]：报文内容；

以下针对周期性数据：

Byte[10]-Byte[11]：要“清零”的起始位；

Byte[12]-Byte[13]：要“清零”的数据长度；

Byte[14]-Byte[15]：“清零”前要发送的帧数；

Byte[16]-Byte[17]：“清零”前发送的帧间隔；

MCU只需解析第一can报文的对应位数即可以构造一个统一的接口来处理车机10发送的第一can报文。

在本例中MCU20解析后会把Byte[0]-Byte[9]的数据取出，按照100ms周期发送3帧到can总线上，之后对Byte[4]数据清零，can总线再将控制指令传递至HVAC ECU。

MCU20在此流程中仅仅只用解析中间件12发送的第一can报文，而不用在内存中建立第一can报文的存储对象，从而使MCU20可以采用低成本的芯片实现。

图5是本发明的实施例所提供的can报文的封装系统的现有can报文示例图。

传统解析can报文主要用到帧ID和内容两部分，通过图4中的帧ID对应图3中的ID，再按照起始位(signal Start Bit)、数据长度(signal Length)和偏移量(Offset)获取到can报文中具体的业务信息；在周期性can报文中，还需要对特定信号清零处理，如果考虑周期上传，MCU就需要维持一个庞大的静态表来存储can信号值，这对于低频，内存有限的MCU来说容易过载。

附图中的流程图和框图，图示了按照本申请各种实施例的系统可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

上述实施例仅示例性说明本发明的原理及其功效，而非用于限制本发明。任何熟悉此技术的人士皆可在不违背本发明的精神及范畴下，对上述实施例进行修饰或改变。因此，但凡所属技术领域中具有通常知识者在未脱离本发明所揭示的精神与技术思想下所完成的一切等效修饰或改变，仍应由本发明的权利要求所涵盖。

Claims (10)

1.can报文的封装系统，其特征在于，包括：车机、微控制单元；所述车机包括应用层和中间件；

所述应用层用于向所述中间件发送业务指令；

所述中间件用于接收来自于所述应用层的业务指令，并将所述业务指令按照预先设置的报文格式封装为第一can报文，并发送至所述微控制单元；还用于接收来自于所述微控制单元的第二can报文，将第二can报文解析成can数据，并发送至所述应用层；

所述应用层还用于接收所述can数据；

所述微控制单元用于接收并解析所述第一can报文，并将解析后得到的控制指令发送至电子控制单元；

所述微控制单元还用于从所述电子控制单元获取状态信息并按照所述报文格式封装为第二can报文发送至所述中间件。

2.根据权利要求1所述的can报文的封装系统，其特征在于，当所述中间件接收到所述业务指令时，将所述业务指令的can标识和报文内容按照所述报文格式封装为所述第一can报文。

3.根据权利要求2所述的can报文的封装系统，其特征在于，所述中间件根据所述can标识获取对应的清零的起始位、清零的数据长度、清零前要发送的帧数、清零前发送的帧间隔，并将所述can标识、所述报文内容、所述清零的起始位、所述清零的数据长度、所述清零前要发送的帧数和所述清零前发送的帧间隔按照所述报文格式封装为所述第一can报文。

4.根据权利要求2所述的can报文的封装系统，其特征在于，所述中间件按照如下步骤进行第一can报文封装：

将所述业务指令中的can标识填入第一can报文的字节0至字节1；

将所述业务指令中的报文内容填入第一can报文的字节2至字节9。

5.根据权利要求3所述的can报文的封装系统，其特征在于，所述中间件按照如下步骤进行第一can报文封装：

将所述业务指令中的can标识填入第一can报文的字节0至字节1；

将所述业务指令中的报文内容填入第一can报文的字节2至字节9；

将所述业务指令中要清零的起始位填入第一can报文的字节10至字节11；

将所述业务指令中要清零的数据长度填入第一can报文的字节12至字节13；

将所述业务指令中清零前要发送的帧数填入第一can报文的字节14至字节15；

将所述业务指令中清零前发送的帧间隔填入第一can报文的字节16至字节17。

6.根据权利要求1所述的can报文的封装系统，其特征在于，所述微控制单元获取到所述状态信息后，将所述状态信息的can标识和报文内容按照所述报文格式封装为第二can报文。

7.根据权利要求6所述的can报文的封装系统，其特征在于，所述微控制单元按照如下步骤进行第二can报文封装：

将所述状态信息中的can标识填入第二can报文的字节0至字节1；

将所述状态信息中的报文内容填入第二can报文的字节2至字节9。

8.根据权利要求1所述的can报文的封装系统，其特征在于，所述应用层还用于向中间件发送获取状态指令；

所述中间件还用于按照所述报文格式将所述获取状态指令封装为获取状态can报文，并发送至所述微控制单元；

所述微控制单元还用于接收并解析所述获取状态can报文并根据解析后的获取状态内容向所述电子控制单元获取所述状态信息。

9.根据权利要求8所述的can报文的封装系统，其特征在于，所述中间件根据所述获取状态指令的can标识获取变化的起始位和变化的报文长度，并将所述can标识、所述变化的起始位和所述变化的报文长度按照所述报文格式封装为所述获取状态can报文。

10.根据权利要求1所述的can报文的封装系统，其特征在于，所述中间件按照如下步骤进行获取状态can报文封装：

将所述获取状态指令的can标识填入获取状态can报文的字节0至字节1；

将所述获取状态指令中变化的起始位填入获取状态can报文的字节2至字节3；

将所述获取状态指令中变化的报文长度填入获取状态can报文的字节4至字节5。

Images