一种车载MCU模组与AP模组之间的通信方法及通信系统与流程

一种车载mcu模组与ap模组之间的通信方法及通信系统
技术领域
1.本发明涉及一种汽车的通信方法，尤其是一种车载mcu模组与ap模组之间的通信方法及通信系统。


背景技术：

2.当中国创新互联网企业将车联网从过去基于传感器的车载式技术路线，转变成了将车载娱乐这类不需要传感器的系统先行布局到汽车里，然后再整合车辆上一些不影响车辆安全的传感系统到车机里的技术路线后，语音识别、导航、各类娱乐影音以及基于场景化服务的app等功能实现热销，从而也让娱乐先行的车机方案在行业内推行了起来。
3.车载操作系统已经成为了智能网联汽车的标准配件。车联网的操作系统从功能上分成了两种类型：娱乐车机系统和汽车电子控制系统。车载操作系统是车载硬件与上层软件的接口。其功能包括管理车载系统的硬件、软件及数据资源，控制程序运行，改善人机界面，为上层软件提供支持，让车机系统的资源，以及接收到的数据、信号、音频、视频最大限度地发挥作用，提供各种形式的用户界面，使车主有一个好的驾驶环境，并有效的提供辅助驾驶、半自动驾驶，甚至自动驾驶。同时，在娱乐车机系统的基础上增加汽车电子控制系统，比如，实现一些电子钥匙和控制车内空调等功能。
4.对应于娱乐车机系统和汽车电子控制系统，车机硬件也对应的分成两大类模组：ap模组和mcu模组。ap模组为娱乐车机系统提供硬件支持，mcu模组为汽车电子控制系统硬件支持，即实际与人交互的部分由娱乐车机系统进行管理，实际与车辆进行交互的部分由汽车电子控制系统进行完成。车载操作系统运行于ap模组内的cpu芯片里，为了将汽车电子控制系统也纳入车载操作系统的统一管理，就需要在ap模组和mcu模组间实现通信。


技术实现要素：

5.为解决上述问题，本发明提供一种能够实现mcu模组与ap模组之间的通信，实现汽车电子控制系统与娱乐功能整合的一种车载mcu模组与ap模组之间的通信方法，具体技术方案为：
6.一种车载mcu模组与ap模组之间的通信方法，所述mcu模组与所述ap模组之间通过spi电路连接，包括以下步骤：
7.定义spi协议，ap模组和mcu模组一次交换13个字节固定长度的信息；
8.定义ap模组发送给mcu模组的字节格式；
9.定义mcu模组发送给ap模组的字节格式。
10.优选的，所述定义ap模组发送给mcu模组的字节格式时：
11.byte0中bit4～bit6代表有效数据内容的长度，bit7代表当前传输的can报文是扩展帧还是标准帧，byte0中低四位bit0～bit3定义如下：
12.0000：用于功能扩展；
13.0001：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且
通过can0通道跟车辆交互；
14.0010：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且通过can1通道跟车辆交互；
15.0011：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且通过can2通道跟车辆交互；
16.0100：代表当前ap模组中娱乐车机系统开机完成，由ap模组发送给mcu模组；此时，byte1～byte8填充“systemok”内容，byte9～byte12未用，用0填充；
17.0101：代表ap模组请求查询mcu模组中电子控制系统软件版本号，由ap模组发送给mcu模组；此时，byte1～byte8填充“mcu_ver？”内容，byte9～byte12未用，用0填充；
18.0110：代表ap模组请求复位，此时，byte1到byte5的值为“reset”，mcu模组收到该信息后会给ap模组执行断电再上电的动作；byte6～byte12未用，用0填充；
19.0111～1100：用于功能扩展；
20.1101：代表ap模组发送给mcu模组的信息报文，具体信息内容从byte1～byte12字节中的内容进行获取；
21.1110：代表ap模组发给mcu模组的信息是mcu模组控制软件的升级包数据；此时，byte1～byte8是实际的数据内容，byte9～byte12未用，用0填充；
22.1111：用于功能扩展。
23.进一步的，所述0001的定义中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0表明是标准帧，bit7为1表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据；
24.所述0010的定义中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0表明是标准帧，bit7为1表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据；
25.所述0011的定义中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0表明是标准帧，bit7为1表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
26.其中，所述1101的定义中，若byte1值为1，则byte2～byte5内容是mcu模组中电子控制系统软件ota升级包的crc32校验值，byte7～byte8内容是mcu模组中电子控制系统软件ota升级包的大小；若byte1值为2，byte2～byte4为“end”，则表示mcu模组中电子控制系统软件ota升级包数据已传输完成；若byte1值为4，byte2～byte5为“stop”，则表示将停止mcu模组中电子控制系统软件升级；若byte1值为7，byte2～byte5为“log1”，则表示ap模组通知mcu模组中电子控制系统软件的log等级调整到level1；若byte1值为7，byte2～byte5为“log2”，则表示ap模组通知mcu模组中电子控制系统软件的log等级调整到level2；其他
未用值用于功能扩展。
27.优选的，所述定义mcu模组发送给ap模组的字节格式时：byte0中bit4～bit6代表有效数据内容的长度，bit7代表当前传输的can报文是扩展帧还是标准帧，byte0低四位bit0～bit3定义如下：
28.0000：可用于功能扩展；
29.0001：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can0通道跟车辆交互；
30.0010：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can1通道跟车辆交互；
31.0011：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can2通道跟车辆交互；
32.0100：用于功能扩展；
33.0101：用于功能扩展；
34.0110：代表mcu模组向ap模组传递车辆方向盘按键信息；
35.0111：代表mcu模组给ap模组反馈mcu模组中电子控制系统软件的版本号，此时，byte1～byte6字节的内容格式为“rs_vxx”，其中的xx代表具体的版本号，比如rs_v01；byte7～byte12未使用，用0填充。
36.1000：用于功能扩展；
37.1001：用于功能扩展；
38.1010：代表mcu模组给ap模组反馈的固件升级状态；
39.1011：用于功能扩展；
40.1100：用于功能扩展；
41.1101：代表mcu模组给ap模组发送的信息报文；
42.1110：用于功能扩展；
43.1111：代表mcu模组给ap模组发送的电子控制系统软件的log日志信息。
44.进一步的，所述定义0001中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据；
45.所述定义0010中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
46.所述定义0011中，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧；若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1
是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
47.其中，所述定义0110中，若byte1的bit0位为1时，表示车辆方向盘上down键按下；若byte1的bit1位为1时，表示车辆方向盘上up键按下；若byte1的bit2位为1时，表示车辆方向盘上mode键按下；若byte1的bit3位为1时，表示车辆方向盘上vol 键按下；若byte1的bit4位为1时，表示车辆方向盘上vol-键按下；若byte1的bit5位为1时，表示车辆方向盘上mute键按下；若byte1的bit6位为1时，表示车辆方向盘上bton键按下；byte1其余未用bit位用0填充；若byte2的bit0位为1时，表示车辆方向盘上的接听电话键按下；若byte2的bit1位为1时，表示车辆方向盘上的挂断电话键按下；byte2其余未用bit位用0填充；若byte3的bit0位和bit1位数值为1，表示车辆方向盘上的seek-键正被用户短按；若byte3的bit0位和bit1位数值为2，表示车辆方向盘上的seek-键正被用户长按；若btye3的bit2位和bit3位数值为1，表示车辆方向盘上的seek 键被用户短按；若byte3的bit2和bit3位数值为2，表示车辆方向盘上的seek 键被用户长按；若byte4的bit0位为1，表示车辆方向盘上的src按键被按下。
48.优选的，所述定义1010中，byte1～byte7的值均为1，若byte7的bit0位为1，表示mcu模组接收到的电子控制系统软件的ota软件包的版本号和当前版本号相同，无需升级；若byte7的bit1位为1，则表明mcu模组此时未提取到ota软件包的版本号；若byte7的bit2位为1，则表示mcu模组成功接收ota软件包，并且crc32校验成功；若byte7的bit3位为1，则表明mcu模组停止接收ota软件包，恢复到正常工作状态。
49.进一步的，所述定义1101中，若byte1值为1，byte2～byte6的值为“reset”，则表明mcu模组收到了ap模组发送过来的复位请求；若byte1值为2，byte2～byte8的值为“scrn_on”，则表明mcu模组通知ap模组打开屏幕背光；若byte1值为2，byte2～byte9的值为“scrn_off”，则表明mcu模组通知ap模组关闭屏幕背光；若btye1值为3，byte2～byte7的值为“acc_on”，则表明mcu模组通知ap模组汽车已上电；若btye1值为3，byte2～byte8的值为“acc_off”，则表明mcu模组通知ap模组汽车已下电；若btye1值为4，byte2～byte9的值为“light_on”，则表明mcu模组通知ap模组汽车小灯已打开；若btye1值为4，byte2～byte10的值为“light_off”，则表明mcu模组通知ap模组汽车小灯已打关闭；其余未使用bit用0填充。
50.一种车载mcu模组与ap模组之间的通信系统，其特征在于，包括mcu模组、spi电路和ap模组，所述mcu模组通过所述spi电路与所述ap模组通信。
51.与现有技术相比本发明具有以下有益效果：
52.本发明提供的一种车载mcu模组与ap模组之间的通信方法可以将车辆电子控制系统的相关功能整合至车载操作系统，将汽车电子控制系统的功能和娱乐功能整合在一起，实现车主享受娱乐的同时对车辆电子进行部分控制，比如，及时响应车主对车辆方向盘上按键的操作、调节车辆空调相关的设置、控制车辆相关的辅助灯以及对车辆相关状态信息的多方式展示和提醒等。
附图说明
53.图1是一种车载mcu模组与ap模组之间的通信方法的协议格式图；
54.图2是一种车载mcu模组与ap模组之间的通信系统的结构框图；
55.图3是spi的电路原理图。
具体实施方式
56.现结合附图对本发明作进一步说明。
57.虽然spi这种接口技术是公开的标准，但是在汽车上无应用。本实施例充分考虑到了车载设备的自身应用需求：能满足当下甚至未来车载mcu模组和ap模组间各种通信场景的需求，通过采用spi进行通信并定义通信协议，该协议基本覆盖ap模组和mcu模块之间方方面面的信息通信，实现以下功能：
58.1、交换车辆can报文数据，可以支持三路can报文的通信，can报文格式同时支持标准帧和扩展帧，且can报文的支持路数仍然可以轻易扩充，即只要车厂公开在can总线上mcu模组可以获取到的信息，mcu模组都可以同步给ap模组，只要车厂允许mcu模组可以控制的车辆功能，ap模组都可以通过mcu模组进行控制；
59.2、车身物理按键信息的交换；
60.3、mcu模块固件升级；
61.4、ap模组和mcu模组之间其他需要交换或协同工作的信息。
62.如图1至图3所示，硬件设计上，在ap模组和mcu模组间通过spi电路进行连接。spi通信信号连接方式为：
63.ap模组中cpu芯片的四根spi信号线spi_0_mi、spi_0_mo、spi_0_cs、spi_0_sclk经过spi电平转换电路跟mcu模组的mcu_spi_miso_5v0、mcu_spi_mosi_5v0、mcu_spi_cs_5v0,mcu_spi_sclk_5v0四根信号线进行连接。
64.软件设计上，定义spi通信协议，ap模组和mcu模组间按照规定的协议进行信息的交换。
65.具体的spi通信协议制定如下。
66.ap模组和mcu模组一次交换13个字节固定长度的信息，即13个byte；
67.13个字节格式定义。主要分为ap模组发送给mcu模组和mcu模组发送给ap模组两种情况。
68.定义ap模组发送给mcu模组的字节格式时：
69.byte0中bit4～bit6代表有效数据内容的长度，bit7表明当前传输的can报文是标准帧还是扩展帧，byte0低四位bit0～bit3定义如下：
70.0000：暂时未用，后续可用于功能扩展；
71.0001：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且通过can0通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
72.0010：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且通过can1通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧
canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
73.0011：代表当前ap模组发给mcu模组的信息是跟车辆电子控制相关的can报文，且通过can2通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
74.0100：代表当前ap模组中娱乐车机系统开机完成，由ap模组发送给mcu模组。此时，byte1～byte8填充“systemok”内容，byte9～byte12未用，用0填充；
75.0101：代表ap模组请求查询mcu模组中电子控制系统软件版本号，由ap模组发送给mcu模组。此时，byte1～byte8填充“mcu_ver？”内容，byte9～byte12未用，用0填充；
76.0110：代表ap模组请求复位，此时，byte1到byte5的值为“reset”，mcu模组收到该信息后，会给ap模组执行断电再上电的动作。车载信息娱乐主机由车辆系统供电，而跟车辆通信的是mcu模组实现的，所以ap模组的供电由mcu模组进行管理。
77.0111～1100：暂时未用，后续可用于功能扩展
78.1101：代表ap模组发送给mcu模组的信息报文，具体信息内容从byte1～byte12字节中的内容进行获取。若byte1值为1，则byte2～byte5内容是mcu模组中电子控制系统软件ota升级包的crc32校验值，byte7～byte8内容是mcu模组中电子控制系统软件ota升级包的大小；若byte1值为2，byte2～byte4为“end”，则表示mcu模组中电子控制系统软件ota升级包数据已传输完成；若byte1值为4，byte2～byte5为“stop”，则表示将停止mcu模组中电子控制系统软件升级；若byte1值为7，byte2～byte5为“log1”，则表示ap模组通知mcu模组中电子控制系统软件的log等级调整到level1；若byte1值为7，byte2～byte5为“log2”，则表示ap模组通知mcu模组中电子控制系统软件的log等级调整到level2；其他未用值，可留作后续功能扩展使用。
79.1110：代表ap模组发给mcu模组的信息是mcu模组控制软件的升级包数据。此时，byte1～byte8是实际的数据内容，byte9～byte12未用，用0填充；mcu模组中的电子控制系统软件的ota升级包是跟随娱乐车机系统软件进行升级的，因为只有娱乐车机系统具有联网功能。
80.1111：暂时未用，后续可用于功能扩展
81.定义mcu模组发送给ap模组的字节格式时：
82.byte0中bit4～bit6代表有效数据内容的长度，bit7表明当前传输的can报文是标准帧还是扩展帧，byte0低四位bit0～bit3定义如下：
83.0000：暂时未用，后续可用于功能扩展；
84.0001：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can0通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
85.0010：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can1通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
86.0011：代表当前mcu模组发给ap模组的信息是跟车辆电子控制相关的can报文，且通过can2通道跟车辆交互；此时，通过byte0的bit7位表明当前传输的can报文类型是标准帧还是扩展帧，bit7为0，表明是标准帧，bit7为1，表明是扩展帧。若是标准帧，byte3和byte4两个字节表示标准帧canid，byte3是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据，byte1和byte2未用；若是扩展帧，byte1～byte4四个字节表示扩展帧canid，byte1是高位，byte4是低位，byte5～byte12是8个字节的can报文具体数据。
87.0100、0101：暂时未用，后续可用于功能扩展；
88.0110：代表mcu模组向ap模组传递车辆方向盘按键信息。
89.此时，若byte1的bit0位为1时，表示车辆方向盘上down键按下；若byte1的bit1位为1时，表示车辆方向盘上up键按下；若byte1的bit2位为1时，表示车辆方向盘上mode键按下；若byte1的bit3位为1时，表示车辆方向盘上vol 键按下；若byte1的bit4位为1时，表示车辆方向盘上vol-键按下；若byte1的bit5位为1时，表示车辆方向盘上mute键按下；若byte1的bit6位为1时，表示车辆方向盘上bton键按下；未用bit用0填充。
90.若byte2的bit0位为1时，表示车辆方向盘上的接听电话键按下；若byte2的bit1位为1时，表示车辆方向盘上的挂断电话键按下；其他未用bit为用0填充。
91.若byte3的bit0位和bit1位数值为1，表示车辆方向盘上的seek-键正被用户短按；若byte3的bit0位和bit1位数值为2，表示车辆方向盘上的seek-键正被用户长按；若btye3的bit2位和bit3位数值为1，表示车辆方向盘上的seek 键被用户短按；若byte3的bit2和bit3位数值为2，表示车辆方向盘上的seek 键被用户长按。
92.若byte4的bit0位为1，表示车辆方向盘上的src按键被按下。
93.0111：代表mcu模组给ap模组反馈mcu模组中电子控制系统软件的版本号，此时，byte1～byte6字节的内容格式为“rs_vxx”，其中的xx代表具体的版本号，比如rs_v01；
94.1000、1001：暂时未用，后续可用于功能扩展；
95.1010：代表mcu模组给ap模组反馈的固件升级状态；此时，byte1～byte7的值均为1，若byte7的bit0位为1，表示mcu模组接收到的电子控制系统软件的ota软件包的版本号和当前版本号相同，无需升级；若byte7的bit1位为1，则表明mcu模组此时未提取到ota软件包的版本号；若byte7的bit2位为1，则表示mcu模组成功接收ota软件包，并且crc32校验成功；若byte7的bit3位为1，则表明mcu模组停止接收ota软件包，恢复到正常工作状态；
96.1011、1100：暂时未用，后续可用于功能扩展；
97.1101：代表mcu模组给ap模组发送的信息报文。若byte1值为1，byte2～byte6的值为“reset”，则表明mcu模组收到了ap模组发送过来的复位请求；若byte1值为2，byte2～byte8的值为“scrn_on”，则表明mcu模组通知ap模组打开屏幕背光；若byte1值为2，byte2～byte9的值为“scrn_off”，则表明mcu模组通知ap模组关闭屏幕背光；若btye1值为3，byte2
～byte7的值为“acc_on”，则表明mcu模组通知ap模组汽车已上电；若btye1值为3，byte2～byte8的值为“acc_off”，则表明mcu模组通知ap模组汽车已下电；若btye1值为4，byte2～byte9的值为“light_on”，则表明mcu模组通知ap模组汽车小灯已打开；若btye1值为4，byte2～byte10的值为“light_off”，则表明mcu模组通知ap模组汽车小灯已打关闭；其余未使用bit用0填充。
98.1110：暂时未用，后续可用于功能扩展；
99.1111：代表mcu模组给ap模组发送的电子控制系统软件的log日志信息。
100.基于如上ap模组和mcu模组间的通信方法，就可以将车辆电子控制系统的相关功能整合至车载操作系统，将汽车电子控制系统的功能和娱乐功能整合在一起，实现车主享受娱乐的同时对车辆电子进行部分控制，比如，及时响应车主对车辆方向盘上按键的操作、调节车辆空调相关的设置、控制车辆相关的辅助灯以及对车辆相关状态信息的多方式展示和提醒等。
101.本协议基本覆盖了车载ap模组和mcu模组的各种交互场景，而且非常方便根据实际应用场景进行扩充。比如协议在以下应用场景下会发挥作用。
102.车载操作系统需要控制车辆相关功能时：
103.比如，运行于ap模组上的娱乐车机系统提供了空调操作面板界面，车主可以通过该空调面板对车辆空调进行控制。控制空调开关、设置空调温度、风速大小、风门方向和空气循环模式等。要控制这些车辆的功能，必须根据车厂提供的can矩阵协议，往车辆can总线上发送指定格式的can报文才能实现真正的控制。本实施例通过spi协议将ap模组相关的can报文发送给mcu模组，由mcu模组将该can报文发送到车辆can总线上。
104.车载娱乐车机系统需要根据车辆状态展示相关内容供车主查看时：
105.比如，车辆倒车时，车载娱乐车机系统需要自动将车后camera的倒车影像展示到屏幕上供车主查看，运行于ap模组上的娱乐车机系统如何才能知道目前车辆处于倒车状态呢？本实施例根据车辆的实时状态都是以一定的周期频率以can报文的形式公告在车辆can总线上，而连接车辆can总线的mcu模组是可以实时获取到这些can报文，mcu模组将获取到的这些can报文按照制定的spi协议转发给ap模组，运行于ap模组中的娱乐车机系统根据制定的spi协议对接收到的内容进行解析，即可实时接收到车辆相关状态的变化，然后再根据这些状态变化执行相应的动作。
106.当车主希望通过方向盘按键操作娱乐车机系统相关功能时：
107.比如，当车主在听歌或收音机时，希望通过方向盘上的vol 键或vol-键调整当前音量；或者希望通过方向盘上的up键或down键切换歌曲或电台。由于ap模组并未跟车辆信号线直接相连，因此，此时仍然需要跟连接车身信号线相连的mcu模组将检测到的相关信息按照制定的spi协议格式传输给ap模组，运行于ap模组之上的娱乐车机系统接收到相关信息后按照制定的spi协议格式进行解析，就能知道当前用户的操作，进而实现相应的控制功能。
108.以上结合具体实施例描述了本发明的技术原理。这些描述只是为了解释本发明的原理，而不能以任何方式解释为对本发明保护范围的限制。基于此处的解释，本领域的技术人员不需要付出创造性的劳动即可联想到本发明的其它具体实施方式，这些方式都将落入本发明权利要求的保护范围之内。