车载信息娱乐系统用异常处理方法、装置及车辆与流程

1.本技术属于车载信息娱乐系统技术领域，特别涉及一种车载信息娱乐系统用异常处理方法、车载信息娱乐系统用异常处理装置、车载信息娱乐系统以及车辆。


背景技术：

2.目前汽车行业向着智能化趋势发展，汽车的功能及应用场景愈发复杂，汽车座舱演化到网联化形态后，座舱功能和内容的丰富程度得到大幅提升，用户体验接近甚至开始超越智能手机，但由于车载信息娱乐的功能多样化引进，对系统稳定性和安全性的产生了更高的要求。
3.现有技术中，车载信息娱乐系统只能借助摄像头记录拍摄的图像数据，捕获图像数据的处理性能下降的情况，不能直接对异常问题进行处理。
4.因此，希望有一种技术方案来克服或至少减轻现有技术的至少一个上述缺陷。


技术实现要素：

5.本技术的目的是提供了一种车载信息娱乐系统用异常处理方法，以解决上述至少一方面的问题。
6.在本技术的第一方面，提供了一种车载信息娱乐系统用异常处理方法，所述车载信息娱乐系统用异常处理方法包括：
7.获取车载信息娱乐系统的运行参数；
8.判断所述运行参数是否异常，若是，则
9.获取预设异常处理策略；
10.根据所述预设异常处理策略对所述车载信息娱乐系统进行异常处理。
11.可选地，所述运行参数包括如下中的一种：
12.车载娱乐系统的运行参数、安卓启动状态参数、内存使用参数、cpu使用参数、关键进程运行参数；
13.所述判断所述运行参数是否异常包括如下中的一种：
14.判断车载娱乐系统的运行参数是否异常、判断所述安卓启动状态参数是否异常、判断内存使用参数是否异常、判断cpu使用参数是否异常以及判断关键进程运行参数是否异常；
15.所述预设异常处理策略包括如下中的一种：
16.车载娱乐系统的运行异常处理策略、安卓启动异常处理策略、内存使用异常处理策略、cpu使用异常处理策略、关键进程运行异常处理策略；
17.所述根据所述预设异常处理策略对所述车载信息娱乐系统进行异常处理包括：
18.当所述车载娱乐系统的运行参数异常时，根据所述车载娱乐系统的运行异常处理策略对所述车载信息娱乐系统进行异常处理；
19.当所述安卓启动状态参数异常时，根据所述安卓启动异常处理策略对所述车载信
息娱乐系统进行异常处理；
20.当所述内存使用参数异常时，根据所述内存使用异常处理策略对所述车载信息娱乐系统进行异常处理；
21.当所述cpu使用参数异常时，根据所述cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理；
22.当所述关键进程运行参数异常时，根据所述关键进程运行异常处理策略对所述车载信息娱乐系统进行异常处理。
23.可选地，所述判断车载娱乐系统的运行参数是否异常包括：
24.判断车载娱乐系统的mcu模块与所述soc模块之间的心跳包对话是否正常，若否，则
25.判断所述车载娱乐系统的运行参数异常。
26.可选地，所述判断车载娱乐系统的mcu模块与所述soc模块之间的心跳包对话是否正常包括：
27.判断mcu模块发送给soc模块心跳包后是否在预定周期内收到soc模块所传递的心跳包应答，若否，则
28.判断所述车载娱乐系统的运行参数异常。
29.可选地，当所述车载娱乐系统的运行参数异常时，根据所述车载娱乐系统的运行异常处理策略对所述车载信息娱乐系统进行异常处理包括：
30.当所述车载娱乐系统的运行参数异常时，对soc模块进行重启。
31.可选地，当所述运行参数为安卓启动状态参数时，所述判断所述运行参数是否异常包括：
32.判断soc模块中的安卓系统启动是否异常。
33.可选地，所述判断soc模块中的安卓系统启动是否异常包括：
34.判断soc模块中的linux系统是否在第一预设时间内收到安卓系统所发送的心跳包，若否，则
35.判断soc模块中的安卓系统启动异常。
36.可选地，当所述安卓启动状态参数异常时，根据所述安卓启动异常处理策略对所述车载信息娱乐系统进行异常处理包括：
37.当所述安卓启动状态参数异常时，重启所述android系统。
38.可选地，判断内存使用参数是否异常包括：
39.获取内存使用率；
40.判断所述内存使用率是否大于第一预设阈值，若是，则
41.判断内存使用参数异常。
42.可选地，所述当所述内存使用参数异常时，根据所述内存使用异常处理策略对所述车载信息娱乐系统进行异常处理包括：
43.获取内存使用参数异常时的内存使用状态；
44.将所述内存使用状态同步至云端数据。
45.可选地，所述当所述内存使用参数异常时，根据所述内存使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
46.合理配制缓存回收机制，明确各组件的生命周期、各组件的运行周期最小化处理；
47.减少系统允许同时运行的进程数，超过该数量直接按照优先级释放；
48.系统增加app使用频度检测机制，使用频度高的app，在退出时保留原生缓存机制，而频度不高的app，退出时立即释放。
49.可选地，所述判断cpu使用参数是否异常包括：
50.获取cpu使用率；
51.判断所述cpu使用率是否大于第二预设阈值，若是，则
52.判断cpu使用参数异常。
53.可选地，当所述cpu使用参数异常时，根据所述cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理包括：
54.获取预设数量的cpu进程信息；
55.将获取的cpu进程信息打印和/或上传至云端数据。
56.可选地，当所述cpu使用参数异常时，根据所述cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
57.获取各个进程的优先级和生命周期参数；
58.分别根据每个进程的优先级和生命周期参数判断该进程是否可释放，若是，则
59.释放可释放的进程。
60.可选地，当所述cpu使用参数异常时，根据所述cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
61.获取当前活跃的进程数据参数；
62.获取活跃的进程的预置参数；
63.将活跃的进程数据参数与其预置参数进行对比，判断该进程是否异常，若是，则
64.结束该进程。
65.可选地，所述判断关键进程运行参数是否异常包括：
66.获取weston进程进行状态；
67.判断是否有weston进程的pid发生改变，若有，则
68.判断关键进程运行参数异常。
69.可选地，当所述关键进程运行参数异常时，根据所述关键进程运行异常处理策略对所述车载信息娱乐系统进行异常处理包括：
70.重启soc模块中的安卓系统。
71.本技术还提供了一种车载信息娱乐系统用异常处理装置，所述车载信息娱乐系统用异常处理装置包括：
72.运行参数获取模块，所述运行参数获取模块用于获取车载信息娱乐系统的运行参数；
73.判断模块，所述判断模块用于判断所述运行参数是否异常；
74.异常处理策略获取模块，异常处理策略获取模块用于在所述判断模块判断为是时，获取预设异常处理策略；
75.异常处理模块，所述异常处理模块用于根据所述预设异常处理策略对所述车载信息娱乐系统进行异常处理。
76.本技术还提供了一种车载信息娱乐系统，所述车载信息娱乐系统包括soc模块、mcu模块以及如权利要求19所述的车载信息娱乐系统用异常处理装置。
77.本技术还提供了一种车辆，所述车辆包括如上所述的车载信息娱乐系统。
78.本技术至少存在以下有益技术效果：
79.本技术的车载信息娱乐系统用异常处理方法通过运行参数判断车载信息娱乐系统是否异常，当异常时读取预设异常处理策略从而解决或者至少减轻异常所带来的问题。
附图说明
80.图1是本技术一个实施方式提供的车载信息娱乐系统用异常处理方法的流程示意图。
81.图2是本技术一实施例的车载信息娱乐系统用异常处理装置的系统架构图。
具体实施方式
82.为使本技术实施的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行更加详细的描述。在附图中，自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。所描述的实施例是本技术一部分实施例，而不是全部的实施例。下面通过参考附图描述的实施例是示例性的，旨在用于解释本技术，而不能理解为对本技术的限制。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。下面结合附图对本技术的实施例进行详细说明。
83.需要说明的是，在本发明的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性。
84.图1是本技术一个实施方式提供的车载信息娱乐系统用异常处理方法的流程示意图。图2是本技术一实施例的车载信息娱乐系统用异常处理装置的系统架构图。
85.如图1所示的车载信息娱乐系统用异常处理方法包括：
86.步骤1：获取车载信息娱乐系统的运行参数；
87.步骤2：判断运行参数是否异常，若是，则
88.步骤3：获取预设异常处理策略；
89.步骤4：根据预设异常处理策略对车载信息娱乐系统进行异常处理。
90.本技术的车载信息娱乐系统用异常处理方法通过运行参数判断车载信息娱乐系统是否异常，当异常时读取预设异常处理策略从而解决或者至少减轻异常所带来的问题。
91.在本实施例中，运行参数包括如下中的一种：
92.车载娱乐系统的运行参数、安卓启动状态参数、内存使用参数、cpu使用参数、关键进程运行参数；
93.判断所述运行参数是否异常包括如下中的一种：
94.判断车载娱乐系统的运行参数是否异常、判断所述安卓启动状态参数是否异常、判断内存使用参数是否异常、判断cpu使用参数是否异常以及判断关键进程运行参数是否异常；
95.预设异常处理策略包括如下中的一种：
96.车载娱乐系统的运行异常处理策略、安卓启动异常处理策略、内存使用异常处理策略、cpu使用异常处理策略、关键进程运行异常处理策略；
97.根据所述预设异常处理策略对所述车载信息娱乐系统进行异常处理包括：
98.当车载娱乐系统的运行参数异常时，根据车载娱乐系统的运行异常处理策略对车载信息娱乐系统进行异常处理；
99.当安卓启动状态参数异常时，根据安卓启动异常处理策略对车载信息娱乐系统进行异常处理；
100.当内存使用参数异常时，根据内存使用异常处理策略对车载信息娱乐系统进行异常处理；
101.当cpu使用参数异常时，根据cpu使用异常处理策略对车载信息娱乐系统进行异常处理；
102.当关键进程运行参数异常时，根据关键进程运行异常处理策略对车载信息娱乐系统进行异常处理。
103.本技术针对车载信息娱乐系统内部的系统状态进行监测，监测维度全面，包含车载娱乐系统的运行参数、安卓启动状态参数、内存使用参数、cpu使用参数、关键进程运行参数等性能参数，并同步云端。从而能够最大程度的检测车载信息娱乐系统内部的整体情况。
104.在本实施例中，判断车载娱乐系统的运行参数是否异常包括：
105.判断车载娱乐系统的mcu模块与soc模块之间的心跳包对话是否正常，若否，则
106.判断车载娱乐系统的运行参数异常。
107.在本实施例中，判断车载娱乐系统的mcu模块与soc模块之间的心跳包对话是否正常包括：
108.判断mcu模块发送给soc模块心跳包后是否在预定周期内收到soc模块所传递的心跳包应答，若否，则
109.判断车载娱乐系统的运行参数异常。
110.在本实施例中，当车载娱乐系统的运行参数异常时，根据车载娱乐系统的运行异常处理策略对车载信息娱乐系统进行异常处理包括：
111.当车载娱乐系统的运行参数异常时，对soc模块进行重启。
112.具体而言，mcu启动成功后，会主动发送心跳包给soc侧的linux系统failsafe模块，failsafe模块收到心跳包消息进行应答。若mcu侧连续10个周期(10个周期即为预定周期)没有收到failsafe心跳包应答，则对soc进行强制重启。
113.在本实施例中，当运行参数为安卓启动状态参数时，判断运行参数是否异常包括：
114.判断soc模块中的安卓系统启动是否异常。
115.在本实施例中，判断soc模块中的安卓系统启动是否异常包括：
116.判断soc模块中的linux系统是否在第一预设时间内收到安卓系统所发送的心跳包，若否，则
117.判断soc模块中的安卓系统启动异常。
118.在本实施例中，本技术进一步包括仪表运行参数。
119.本技术中，判断所述运行参数是否异常进一步包括：
120.判断仪表运行参数是否异常。
121.本技术中，预设异常处理策略进一步包括仪表异常处理策略。
122.在本实施例中，判断仪表运行参数是否异常包括：
123.判断soc模块中的仪表系统启动是否异常。
124.在本实施例中，判断soc模块中的仪表系统启动是否异常包括：
125.判断仪表系统启动后，soc模块中的linux系统是否在第二预设时间(例如，2秒内)内收到仪表系统传递的心跳包，若否，则
126.判断仪表系统启动异常。
127.在本实施例中，当安卓启动状态参数异常时，根据安卓启动异常处理策略对车载信息娱乐系统进行异常处理包括：
128.当安卓启动状态参数异常时，重启android系统。
129.具体而言，判断soc模块中的安卓系统启动是否异常具体为：
130.android系统failsafemgr模块启动后会每隔2秒发送心跳包linux系统的failsafe模块。如果连续30秒(连续30秒即为第一预设时间)未收到心跳包消息，则请求powermgr重启异常的android系统。当soc启动后，linux侧failsafe会启动1分钟(升级第一次启动定时是4分钟)计时等待android系统启动的握手消息。如果在规定时间内没有收到握手消息，则表示android系统异常，linux侧的failsafe模块会发请求重启android的通信给powermgr，powermgr收到消息后重启指定的android系统，然后linux侧的failsafe重新开始对握手消息的监听。
131.具体而言，判断soc模块中的仪表系统启动是否异常具体为：
132.soc启动后，linux侧的failsafe会开始对仪表模块心跳包消息的监听。仪表启动后，每隔2秒会发送心跳包消息给failsafe模块，failsafe模块收到心跳包消息后会复位3秒超时定时器，清除超时次数。如果连续30次未收到仪表的心跳包消息，则将请求重启mcu重启soc。
133.在本实施例中，判断内存使用参数是否异常包括：
134.获取内存使用率；
135.判断内存使用率是否大于第一预设阈值，若是，则
136.判断内存使用参数异常。
137.在本实施中，当所述内存使用参数异常时，根据所述内存使用异常处理策略对所述车载信息娱乐系统进行异常处理包括：
138.获取内存使用参数异常时的内存使用状态；
139.将所述内存使用状态同步至云端数据。
140.在本实施中，当所述内存使用参数异常时，根据所述内存使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
141.合理配制缓存回收机制，明确各组件的生命周期、各组件的运行周期最小化处理；举例来说，首先判断运行的组件是否为用户常用应用，若非常用，当退到后台时直接回收，若为导航、音乐等应用，进入后台后进行保活，且可以根据需要设置为高优先级，当资源受限时，高优先级的应用会进行保护行为。
142.减少系统允许同时运行的进程数，超过该数量直接按照优先级释放；举例来说，当进程占用超过70％时，按照优先级逐步kill进程，直到进程达到70％以内停止。
143.系统增加app使用频度检测机制，使用频度高的app，在退出时保留原生缓存机制，而频度不高的app，退出时立即释放。
144.在本实施例中，判断cpu使用参数是否异常包括：
145.获取cpu使用率；
146.判断cpu使用率是否大于第二预设阈值，若是，则
147.判断cpu使用参数异常。
148.在本实施例中，当cpu使用参数异常时，根据cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理包括：
149.获取预设数量的cpu进程信息；
150.将获取的cpu进程信息打印和/或上传至云端数据。
151.在本实施例中，当cpu使用参数异常时，根据cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
152.获取各个进程的优先级和生命周期参数；
153.分别根据每个进程的优先级和生命周期参数判断该进程是否可释放，若是，则
154.释放可释放的进程。
155.在本实施例中，当cpu使用参数异常时，根据所述cpu使用异常处理策略对所述车载信息娱乐系统进行异常处理进一步包括：
156.获取当前活跃的进程数据参数；
157.获取活跃的进程的预置参数；
158.将活跃的进程数据参数与其预置参数进行对比，判断该进程是否异常，若是，则
159.结束该进程。
160.在本实施例中，判断关键进程运行参数是否异常包括：
161.获取weston(图层)进程进行状态；
162.判断是否有weston进程的pid发生改变，若有，则
163.判断关键进程运行参数异常。
164.在本实施例中，当关键进程运行参数异常时，根据所述关键进程运行异常处理策略对所述车载信息娱乐系统进行异常处理包括：
165.重启soc模块中的安卓系统。
166.本技术能够针对车载信息娱乐系统内部的系统状态进行监测，监测维度全面，包含故障信息，包含内存、gpu、关键进程、通信机制等性能参数，并同步云端。并且在监测到参数到达一定阈值时，会根据所述预设异常处理策略对所述车载信息娱乐系统进行异常处理，快速减轻系统本身运行负荷。
167.本技术可解决问题如下：
168.1.避免因系统本身运行负荷带来的用户体验问题，如卡屏，切换界面缓慢等。
169.2.在发生故障时，可通过云端数据获取车机系统事件发生时的状态数据，用以辅助分析使用。
170.参见图2，本技术还提供了一种车载信息娱乐系统用异常处理装置，所述车载信息娱乐系统用异常处理装置包括运行参数获取模块11、判断模块12、异常处理策略获取模块13以及异常处理模块14，运行参数获取模块11用于获取车载信息娱乐系统的运行参数；判
断模块12用于判断运行参数是否异常；异常处理策略获取模块13用于在判断模块判断为是时，获取预设异常处理策略；异常处理模块14用于根据所述预设异常处理策略对车载信息娱乐系统进行异常处理。
171.本技术还提供了一种车载信息娱乐系统，车载信息娱乐系统包括soc模块、mcu模块以及如上所述的车载信息娱乐系统用异常处理装置，在本实施例中，soc模块包括安卓系统以及linux模块，在本实施例中，linux内设置有仪表系统。
172.本技术还提供了一种车辆，所述车辆包括如上所述的车载信息娱乐系统。
173.在本实施例中，车载信息娱乐系统可以包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
174.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
175.计算机可读介质包括永久性和非永久性、可移动和非可移动，媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数据多功能光盘(dvd)或其他光学存储、磁盒式磁带、磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。
176.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
177.此外，显然“包括”一词不排除其他单元或步骤。装置权利要求中陈述的多个单元、模块或装置也可以由一个单元或总装置通过软件或硬件来实现。
178.附图中的流程图和框图，图示了按照本技术各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，模块、程序段、或代码的一部分包括一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地标识的方框实际上可以基本并行地执行，他们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或总流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。
179.在本实施例中所称处理器可以是中央处理单元(central processing unit，cpu)，还可以是其他通用处理器、数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现成可编程门阵列(field-programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻
辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
180.存储器可用于存储计算机程序和/或模块，处理器通过运行或执行存储在存储器内的计算机程序和/或模块，以及调用存储在存储器内的数据，实现装置/终端设备的各种功能。存储器可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据手机的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器可以包括高速随机存取存储器，还可以包括非易失性存储器，例如硬盘、内存、插接式硬盘，智能存储卡(smart media card,smc)，安全数字(secure digital,sd)卡，闪存卡(flash card)、至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
181.在本实施例中，装置/终端设备集成的模块/单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实现上述实施例方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，计算机程序包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、u盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减。本技术虽然以较佳实施例公开如上，但其实并不是用来限定本技术，任何本领域技术人员在不脱离本技术的精神和范围内，都可以做出可能的变动和修改，因此，本技术的保护范围应当以本技术权利要求所界定的范围为准。
182.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
183.最后需要指出的是：以上实施例仅用以说明本发明的技术方案，而非对其限制。尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。