基于someip仪表数据的汽车服务系统的制作方法

1.本发明涉及汽车仪表技术领域，具体涉及基于someip仪表数据的汽车服务系统。


背景技术：

2.随着汽车电子电汽技术的快速发展，人们希望获得越来越多的可视化的呈现效果。 汽车的液晶数字仪表迎合了人们的需求。它给我们带来了非常有越的驾驶体验及更多方便 有用的信息。驾驶者可以通过生动的动画来获得想要的信息，不再只限于传统的lcd灯。 该汽车液晶数字仪表平台软件提供了多种附加信息，同时通过可扩展的软件架构来适应更 多的场景。
3.目前汽车液晶数字仪表的整体架构为soc加mcu主从处理器协调工作，soc负责所 有通用运算及图像处理，mcu负责总览所有总线上的数据并汇总上报给soc。除来自于mcu 的数据外，为获得更好的用户体验，很多来自ivi信息也需要数字仪表接收，形成了多种 数据源。负责主要逻辑处理的hmi程序就必须从多处获取数据，造成hmi除了负责本身的 显示逻辑之外还要处理通信相关的问题，造成软件复杂度上升及质量下降。
4.这就需要一个专门的数据服务中心来融合所有数据源。目前，为了应用程序开发方 便，软件架构中都不会使用操作系统的原生进程间通信方式，而是基于此做的基本中间件。 目前主流的是d
‑
bus，基于有分发中心的架构方式，通信效率较低并且主设计初衷是为桌 面机设计，因此需要一种新的能够提高通信效率的数据处理系统。


技术实现要素：

5.本发明的目的在于克服现有技术的不足，提供基于someip仪表数据的汽车服务系统， 数据服务模块是选用someip作为底层通信模块，该模块是专为汽车电子而设计，适应于 单节点内部通信或者多节点通信。
6.通过以下技术方案来实现的：基于someip仪表数据的汽车服务系统，系统包括有工 具模块、服务类模块、应用类模块、基础模块和服务类配置文件模块，
7.所述工具模块包括有第一工具、第二工具和第三工具，第一工具和第二工具用于生成 通用的类和接口，第三工具用于生成服务类模块的类和接口；
8.所述服务类模块包括有第一服务、第二服务和第三服务，第一服务和第二服务用于收 集底层mcu的数据，第三服务用于编写后端库；
9.应用类模块包括有hmi显示模块、hud显示模块、动画模块和声音播放器；
10.基础模块包括有boost，vsomeip及common api，其中boost主要被vsomeip使用， 而common api将专用vsomeip接口统一为固定的接口；
11.服务类配置文件模块包括有ipc_sheet.xls、hmi_server.fidl和hmi_server.fdepl， ipc_sheet.xls，ipc_sheet.xls用于定义第一服务中与具体业务相关的数据类型，并通过 第三工具生成文件，hmi_server.fidl和hmi_server.fdepl分别用于配置服务接口及信号、 传输层的参数。
12.优选的，第一工具、第二工具和第三工具分别为commonapi
‑
generator
‑
linux
‑
x86_64、 commonapi
‑
someip
‑
generator
‑
linux
‑
x86_64和generate_ipc_headfile， generate_ipc_headfile是第一服务ipc_data_server的工具，负责生成第一服务 ipc_data_server的类和接口，以及其枚举和结构体定义。
13.优选的，第一服务、第二服务和第三服务分别为ipc_data_server、hmi_server和 libspiipc，其中，hmi_server的包含有proxy管理器，用来管理多个通信方工的客户端 代理，同时提供一个统一的服务给外部使用。
14.优选的，所述libspiipc作为通信后端，负责与mcu之间进行通信并取得底层总线上 的数据，其除了基本的通信能力之外，还具备有拼帧、解帧、数据校验和虚拟通道， libspiipc核心模块中分为基础模块、核心模块以及底层模块，所述基础模块包括有三种 实现通道，分别为queue的queue event实现，基于pipe的pipe event实现，基于socket 的socket event实现。
15.优选的，底层模块为spi硬件外设，基于spi的协议需要两根硬线作为数据请求和确 认使用，需要通过gpio来完成数据的应答。
16.优选的，核心模块包括有resmgr和handler，resmgr用以实现虚拟通道。
17.优选的，mcu数据服务中心即为第一服务的ipc_data_server，ipc_data_server由通用代 码和应用类代码组成，通用代码保持不变，应用代码由工具生成，其基本开发流程包括下 列步骤：
18.s71:需要由人工将用户需求转成ipc_sheet.xls文件,并定义好数据的传输周期，传输类 型以及数据标识；
19.s72:使用工具generate_ipc_headfile将ipc_sheet.xls生成文件，command_defines_map.h，data_server_impl.h，message_defines_map.h， vital_message_defines_map.h以及fidl文件；
20.s73:将通用代码与生成代码编译生成ipc_data_server。
21.优选的，ipc_data_server包含有主函数、数据帧管理器、命令管理器、消息管理器、 服务接口以及驱动管理。
22.基于someip仪表数据的汽车服务系统用于液晶数字仪表、人机交互界面的用途。
23.本发明的有益效果是：
24.(1)汽车液晶数字仪表平台软件提供了多种附加信息，同时通过可扩展的软件架构 来适应更多的场景；
25.(2)适应于单节点内部通信或者多节点通信。
附图说明
26.图1为本发明的整体系统框图；
27.图2为本发明的一个实施例中ipc_data_server的工作原理图；
28.图3为本发明的一个实施例中ipc_data_server组成图；
29.图4为本发明的一个实施例中ipc_data_server自动分发原理图；
30.图5为本发明的一个实施例中hmi_server组成图；
31.图6为本发明的一个实施例中客户端分组及安装方式原理图；
32.图7为本发明的一个实施例中通信后端libspiipc组成图
33.图8为本发明的一个实施例的核心模块原理图。
具体实施方式
34.下面结合本发明的附图1～8，对本发明实施例中的技术方案进行清楚、完整地描述， 显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中 的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施。
35.在本发明的描述中，需要理解的是，术语“逆时针”、“顺时针”“纵向”、“横向”、
ꢀ“
上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”、
ꢀ“
内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便 于描述本发明，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位 构造和操作，因此不能理解为对本发明的限制。
36.实施例：
37.请参照图1，所涉及的模块分为五大类，其中commonapi
‑
generator
‑
linux
‑
x86_64和 commonapi
‑
someip
‑
generator
‑
linux
‑
x86_64是基础模块中工具，负责生成通用的类和接 口，而generate_ipc_headfile是ipc_data_server的工具，负责生成ipc_data_server 的类和接口，以及其它应用模块的枚举和结构体定义。
38.服务类是核心部分，请参照图2、图3，由两个应用程序构成ipc_data_server及 hmi_server。ipc_data_server负责来自于底层mcu的数据收集，其模块代码分为通用代 码和具体业务相关的数据，具体相关的业务数据代码可以通过generate_ipc_headfile生 成而不用手工编写，同时他还负责加载ipc通信的后端库，libspipc是基于spi外设的后 端，同样可以编写其它的后端库。除了来自于mcu的数据之外，还有一部分数据来自于ivi 等部件，其通信方式可能是多种多样，为此有一个服务用来屏蔽掉通信方工的差异，它就 是hmi_server，hmi_server的有一个proxy管理器，用来管理多个通信方工的客户端代 理，同时提供一个统一的服务给外部使用。
39.应用类部分是各种种样的应用，有具体业务的hmi显示程序，hud显示程序，也可能 是自动测试程序等。它们具有相同的地位，可以无差别的与hmi_server或者 ipc_data_server进行交互。
40.基础模块包括boost，vsomeip及common api，其中boost主要被vsomeip使用，而 common api将专用vsomeip接口统一为固定的接口，这也导致其可以支持其它的底层通信 方式，如dbus,dds等。
41.配置文件主要有三个，ipc_sheet.xls用于定义ipc_data_server中与具体业务相关 的数据类型，只需要将应用数据在ipc_sheet中配好以后，可以通过 generate_ipc_headfile生成一系列需要被使用的文件，由于_ipc_data_server也是一个 someip服务端，所以也需要fidl及fdepl文件，但这也是通过工具自动生成的。另外两 个配置文件用于hmi_server分别用于配置服务接口及信号，以及传输层的参数。
42.libspiipc是通信后端，参照图7，负责与mcu之间进行通信并取得底层总线上的数 据，其除了基本的通信能力之外，还具备拼帧，解帧，数据校验，虚拟通道等。libspiipc 提供如下接口供ipc_data_server使用：
43.int32_t init_drv(int32_t*argc,char**argv)
44.int32_t receive_drv_resmgr_frame(int32_t*channel_id,uint8_t*app_data, int32_t*size)
45.int32_t send_drv_resmgr_frame(int32_t channel_id,uint8_t*app_data, int32_t size)
46.void cleanup_drv_resmgr(void)
47.这些接口是抽想的ipc_data_server后央的通用接口，其它任何只要具备这些接口的 都可以作为其后端。
48.其它核心实现在libspiipc核心中完成，libspiipc核心模块中分为基础模块，核心 模块以及底层模块。
49.基础模块中对一些基础进行了封装以更利于模块化编程，目前基础模块的通道中支持 三种实现，分别为基于queue的queue event实现，基于pipe的pipe event实现，基于 socket的socket event实现。其可以通过配置选择，目前默认选择以socket的socketevent来实现channel。
50.底层模块主要使用spi硬件外设，为具有通用性，抽象为一个通信hal设备，hal设 备再调用spi接口完成底层数据的收发，当然可以调整hal以支持其它的外设接口，如 uart。目前基于spi的协议需要两根硬线作为数据请求和确认使用，需要通过gpio来完 成数据的应答，所以hal中还实现了对gpio的操作。
51.核心模块由两部份组成：resmgr和handler，resmgr是虚拟通道的实现地方，如图 8所示，主设备写入的帧格式：
52.表1 主设备写入的帧格式示例
[0053][0054]
表2 主设备读取的帧格式
[0055][0056]
目前帧在底层传输采用的是固定帧格式，其格式如图8所示，其中长度的计算公式如下，
[0057]
总长度＝消息1长度 消息2长度
…
消息n长度 4(crc校验长度) 在每一固定帧内部，可以包含多条消息。每一条消息的格式如下：
[0058]
表3 固定帧内的消息格式
[0059][0060]
ipc_data_server由通用代码和应用类代码组成，通用代码保持不变，应用代码由工 具生成。其基本开发流程如下：
[0061]
步骤1：需要由人工将用户需求转成ipc_sheet.xls文件,并定义好数据的传输周期，传输 类型以及数据标识。
[0062]
步骤2：使用工具generate_ipc_headfile将ipc_sheet.xls生成文件， command_defines_map.h，data_server_impl.h，message_defines_map.h， vital_message_defines_map.h以及fidl文件。
[0063]
步骤3：将通用代码与生成代码编译生成ipc_data_server。
[0064]
由于ipc_data_server需要提供基于someip的服务接口，所以也需要fidi文件，而 内容又与具体应用数据相关，所以其fidi文件也必须由工具生成，其生成的示例如下所 示：ipc_data_server.fidl示例文件:
[0065]
[0066]
[0067]
[0068]
[0069]
[0070][0071]
上面展示ipc_data_server模块中各主要模块及其主要任务。除主函数之外， ipc_data_server由下列主要模块组成：数据帧管理器，命令管理器，消息管理器，服务 接
口以及驱动管理。
[0072]
主函数是该ipc_data_server的入口点，首先其建立基本的运行环境，比如选项的解析，打印消息级别处理，环境变量的设定。当这一切就绪后就会实例化一个驱动管理器，其作用是根据选项参数将驱动的接口暴露给ipc_data_server使用。其接口原型如下所示：
[0073]
typedefint32_t(*drvinit)(int32_t*argc,char**argv)；
[0074]
typedefint32_t(*drvreceive)(int32_t*channel_id,uint8_t*app_data,int32_t*size)；
[0075]
typedefint32_t(*drvsend)(int32_tchannel_id,uint8_t*app_data,int32_tsize)；
[0076]
typedefvoid(*drvcleanup)(void)；
[0077]
这些是通用型原型接口，并不区别底层实际的物理通信接口，此种设计的目的是方便加载不同的驱动后端，目前只实现基于spi的后端驱动，实际其它的接口后端也可以支持，只要对ipc_data_server提供同样的驱动接口即可。当完成驱动的加载及实始化后，就可以开始接收mcu来的数据帧了。当前libspiipc.so已经具备了拼帧与拆帧的能力，所以到达ipc_data_server的数据已经是拆帧以后的原始消息。
[0078]
表4原始消息的格式
[0079][0080]
目前支持特性功能有如下几路：
[0081][0082][0083]
从mcu发向soc的数据只有三种：ipc_feature_ioc_ntf，ipc_feature_ioc_req，ipc_feature_ioc_rep。
[0084]
其中ipc_feature_ioc_ntf，ipc_feature_ioc_req承载有效数据，而ipc_feature_ioc_rep的目的只是确认mcu已收到soc发来的数据。ipc_feature_ioc_ntf支持的数据是周期性数据，由于该特性，所以soc是不需要对其进行确认回复，但ipc_feature_ioc_req是需要soc接收到以后进行回复确认，回复的序列号必须跟接收到序列号一样。接
下来就是消息的分法。自动分发采用以功能id为索引，自动生成的消息 分发函数。如图4所示。
[0085]
如果客户端阅了该信号，则该消息就会递送到该客户端。没有订阅该消息的客户端是 不会收到该消息。
[0086]
同是ipc_data_server具有缓存机制，也即当没有任何客户端在线时，如果底层有消 息发出，该服务会缓存不同消息的最新状态，此机制是为了解决如一些消息是非周期信息， 但是客户端还没有上线时，该消息已经到来，导致消息丢失的问题。
[0087]
消息中有一类消息比较特殊名叫small message，此种消息是传递告警类，其类型如 下：
[0088][0089]
此类消息将告警中的指示灯，弹窗及声音全都整合到一个small message中，但在消 息传输层使用的可靠传输(有确认机制，如果数据相同，则不会上报应用层)，同时为了 节省数据带宽可能在一包数据中包含多个small message。这样在ipc_data_serve中对于 small message类型的消息要解开整个数据包。为了达到此目的，增加一个small message 集合表。同种id的small message会最后一次值存储。以保证不同的客户端上线时都能 收到最新的消息。
[0090]
实际情况中还有另外一种情况，该种消息是一种事件型消息，不存在最后一次的值， 这种消息是不需要存储的。为此定义了另外一种消息叫做vital message，比如按键操作， 当新的客户端上线时，如果存储会误触发。
[0091]
综合数据服务中心hmi_server：
[0092]
当前数据有多各种来源，目前ipc_data_server集中处理了来自于mcu的数据。但是 来自于ivi或者hud的数据也需要管理。所以有一个叫综合数据服务中心模块hmi_server， 它会管理ipc_data_server的部分数据，同时也会管其它所有的数据。对于hmi来说，只 需要与hmi_server交互就可以拿到所有的数据。
[0093]
如图5，将其它辅助模块及具体业务模块去除了，只保留了与数据服务相关的模块。 主要分为两部分：
[0094]
核心模块：
[0095]
proxy manage:每一个数据服务在本地都需要一个代理，proxy manage管理所有的代 理。包括数据服务的代理，也包括基它具体业务的代理。如开机动画代理，声音播放器代 理等。
[0096]
message manage:所有从外部来的数据都将其当作一条消息，这些消息的类型可能多 种多样，有结构体，有原始字节流，有small message，等。message manage管理所有的 消息。
[0097]
signal manage:在后端报给应用层的数据都叫做信号，在数据消息的时候会将其转 化为一些信号。
[0098]
配置文件：
[0099]
主要是提供数据服务接口，其配置文件如下：
[0100]
[0101]
[0102][0103]
由于信号很多，客户端只关心自己关心的的信号，所以在这一层将信号转化为统一的 结构，如下所示：
[0104][0105]
同时在客户端需要通过setsignalfilters接口来告诉hmi_server自己关心的信号， 这时客户端只会接收到特定的信号。为了区分不同的信号，信号有唯一的id来标识。目 前将信号分成如下分组，每一个分组支持的最大信号数为2000。
[0106]
[0107][0108]
同样的客户端发来的命令也进行分组，分组情况如下所示，每一个命令组支持的最大 命令个数为200：
[0109][0110]
同样的消息也是分组的，目前的分组及安装方式如图6所示，每一个分组支持的最大 消息数为256：
[0111][0112]
由于数据服务模块底层采用someip形式，因此采用cmake编译方式，目前内部编译 系统所支持的方式为makefile及shell脚本，所以cmake的支持方式是通过shell脚本 来实现。
[0113]
首先模块内部需要编写build.sh及cmakelist.txt文件，形式如下：
[0114]
[0115]
[0116]
[0117]
[0118]
[0119][0120]
在build.sh及cmakelist.txt文件编写好以后，需要将其加入到编译系统，每个项 目都有一个专用的配置文件env_setup.py，在该文件的module_config中加入下列行即可， 请注意，其中的build_sys必须选择build，至此该模块已加入编译系统，当编译整个项 目时，该模块也会编译进去。
[0121]
{'module_name':'hmi_server','workspace_path':'hmi_server', 'copyfiles_config':'tcfg_app/hmiserver.txt','build_sys':'build'}
[0122]
值得说明的是，软件的环境为boost>＝1.55，c 11标准，gcc>＝4.8，cake编译 系统>2.8.12，vsome模块，common api模块。
[0123]
综上所述，本实施例基于汽车仪表显示系统，综合对数据进行汇总和处理，不局限于 mcu单方面的数据，将多个数据源的信息融合，才用上述的整体架构，得到了基于someip 作为底层通信模块的新型通用性系统。