发明内容
本发明实施例提供一种多系统启动方法、设备、存储介质及程序产品,以提高多系统启动的成功率。
第一方面,本发明实施例提供一种多系统启动方法,所述多系统包括第一系统、宿主机系统、第一容器对应的第二系统和第二容器对应的第三系统,该方法包括:
第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统;
通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性;
若所述第二系统的启动状态为启动异常,则所述第一系统重新启动所述第二系统;
通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性;
若所述第三系统的启动状态为启动异常,则所述第二系统对所述第三系统进行调整,并重新启动调整后的第三系统。
在一种可能的设计中,所述通过所述第二系统对所述第三系统的启动状态进行监测,包括:
所述第三系统在启动成功后,生成启动状态文件;
所述宿主机系统在预设时间内对所述第三系统的启动状态文件进行访问,确定所述第二系统的启动状态,并将所述第三系统的启动状态发送给所述第二系统。
在一种可能的设计中,所述第二系统对所述第三系统进行调整,包括:
所述第二系统对所述第三系统的启动日志进行问题检索;
若检索得到的问题为常规已知错误,则确定与常规已知错误对应的待修复文件的文件信息;
根据所述文件信息对所述待修复文件进行修复。
在一种可能的设计中,所述第二系统对所述第三系统的启动日志进行问题检索之后,还包括:
若检索得到的问题为非常规已知错误,则通过所述宿主机系统将所述第三系统恢复出厂设置。
在一种可能的设计中,所述重新启动调整后的第三系统之后,还包括:
若所述调整后的第三系统重启后的启动状态为启动异常,则保存所述启动日志,以在返厂后进行分析。
在一种可能的设计中,所述根据所述文件信息对所述待修复文件进行修复之后,还包括:
所述第二系统将修复启动标志写入所述第三系统,以使所述第三系统根据所述修复启动标志进行修复启动;
所述若所述第二系统的启动状态为启动异常,则所述第二系统对所述第三系统进行调整,包括:
若所述第三系统的启动状态为启动异常且为非修复启动,则所述第二系统在所述宿主机系统关闭所述第三系统的权限检测后,对所述第三系统进行调整。
在一种可能的设计中,所述重新启动调整后的第三系统之后,还包括:
通过所述宿主机系统开启所述第三系统的权限检测。
在一种可能的设计中,所述第一系统重新启动所述第二系统,包括:
所述第一系统将宿主机系统断电后再上电,实现对所述第二系统的重启。
第二方面,本发明实施例提供一种多系统启动设备,所述多系统包括第一系统、宿主机系统、第一容器对应的第二系统和第二容器对应的第三系统,该设备包括:
启动模块,用于在第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统;
第一监测模块,用于通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性;
重启模块,用于在所述第二系统的启动状态为启动异常时,通过所述第一系统重新启动所述第二系统;
第二监测模块,用于通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性;
调整模块,用于在所述第三系统的启动状态为启动异常时,通过所述第二系统对所述第三系统进行调整,并重新启动调整后的第三系统。
第三方面,本发明实施例提供一种多系统启动设备,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如上第一方面以及第一方面各种可能的设计所述的方法。
第四方面,本发明实施例提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上第一方面以及第一方面各种可能的设计所述的方法。
第五方面,本发明实施例提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时,实现如上第一方面以及第一方面各种可能的设计所述的方法。
本实施例提供的多系统启动方法、设备、存储介质及程序产品,多系统包括第一系统、宿主机系统、第一容器对应的第二系统和第二容器对应的第三系统,该方法包括第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统;通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性;若所述第二系统的启动状态为启动异常,则所述第一系统重新启动所述第二系统;通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性;若所述第三系统的启动状态为启动异常,则所述第二系统对所述第三系统进行调整,并重新启动调整后的第三系统。本实施例提供的方法通过最稳定的第一系统对较稳定的第二系统进行监测和辅助,提高了第二系统的启动成功率,且通过较稳定的第二系统对相对最不稳定的第三系统进行监测和辅助,提高了第三系统的启动成功率,从而提高了整个多系统的启动成功率。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
目前车载行业,智能座舱使用多系统方案已经越来越普及。现有技术中可以通过高通平台系列芯片搭载Qnx Hypervisor运行Qnx和Android双系统,还可以基于容器方案实现双系统,双系统分别对应Linux系统和Android系统。两个系统基于同一个内核,Linux主要是内核加用户空间运行仪表HMI程序,相对于应用与车机的Android系统来说,由于没有庞大的中间系统层软件,故更小更稳定,具有更高的启动稳定性。
在具体实现过程中,车机对应的Android系统和仪表对应的Linux系统,两个系统可以运行在一颗芯片上,并通过容器技术实现互相隔离,独立运行,两者通讯需要经过宿主机系统。MCU14对搭载双系统的主机(该主机用于运行第一系统和第二系统,包括必要芯片和相关硬件电路等)上电后,启动宿主机系统,宿主机系统启动两个容器,第一容器启动Linux系统仪表程序,第二容器启动Android系统。其中,Android系统由于功能复杂,搭载的应用很多,且支持第三方安装,导致系统稳定性远没有只用来运行仪表这一个程序的Linux系统侧稳定。例如,Android系统在断电异常情况下,极易出现文件损坏,从而导致下次开机时,读写失败,使开机画面卡在商标启动日志画面,不能开机。多系统的启动成功率受限于启动成功率较低的Android系统,无法满足用户需求。
为了解决上述问题,发明人研究发现,Linux系统稳定性远超过Android系统,基于该特点,本发明实施例提供一种多系统启动方法。
下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例不再赘述。
图1为本发明一实施例提供的多系统启动方法的流程示意图。如图1所示,所述多系统包括第一系统、宿主机系统、第一容器对应的第二系统和第二容器对应的第三系统,该方法包括:
101、第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统。
102、通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性。
103、根据监测得到的结果,判断第二系统的启动状态是否为启动异常,若是,则执行104,若否,则控制宿主机系统正常运行。
104、所述第一系统重新启动所述第二系统。
105、通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性。
106、根据监测得到的结果,判断第三系统的启动状态是否为启动异常,若是,则执行107,若否,则控制宿主机系统正常运行。
107、所述第二系统对所述第三系统进行调整,并重新启动调整后的第三系统。
本实施例中,第一系统相对于第二系统更加稳定,第二系统相对于第三系统更加稳定。例如,第一系统可以为MCU的实时系统,第二系统可以为Linux系统,第三系统可以为Android系统。
下面以第一系统为MCU的实时系统,第二系统为Linux系统,第三系统为Android系统,为例,对本实施例的方法进行示例说明。
实际应用中,座舱中对应MCU通过对搭载容器方案双系统的主机上拉电源的通用型输入输出引脚(General-purpose input/output,GPIO),控制主机开始上电,上电之后,启动容器方案对应的宿主机系统,宿主机系统再启动两个容器,第一容器去启动Linux的仪表程序,第二容器去启动Android系统,同时MCU的实时系统开始监测Linux系统仪表程序的启动,而宿主机系统则在规定时间内开始去监测Android系统是否正常启动。
第一容器对应Linux系统开始启动,MCU对应实时系统通过SPI或者串口等多种方式与Linux系统建立通讯机制,如果发现Linux系统仪表程序没有正常启动,则对整个主机平台进行重新断电再上电,进行重启。如果Linux系统仪表程序成功启动,则正常运行,并启动一个程序,去周期确认是否有宿主机系统发送的检索任务,若收到检索任务,则进行检索Android系统的启动日志任务。
在实际应用中,MCU对搭载容器方案双系统的主机上电后,主机启动宿主机系统,宿主机系统启动两个容器,第一容器启动第二系统,例如Linux系统,第二容器启动第三系统,例如Android系统。
Linux系统和Android系统通过宿主机系统建立通讯机制,根据通讯结果,Linux系统监听Android系统的启动状态,发现启动异常时,对Android系统进行调整修复,然后重新启动调整后的Android系统,最终实现提高Android系统正常启动概率。
本实施例提供的多系统启动方法,通过最稳定的第一系统对较稳定的第二系统进行监测和辅助,提高了第二系统的启动成功率,且通过较稳定的第二系统对相对最不稳定的第三系统进行监测和辅助,提高了第三系统的启动成功率,从而提高了整个多系统的启动成功率。
在一些实施例中,步骤106,可以具体包括:
所述第三系统在启动成功后,生成启动状态文件;
所述宿主机系统在预设时间内对所述第三系统的启动状态文件进行访问,确定所述第二系统的启动状态,并将所述第三系统的启动状态发送给所述第二系统。
实际应用中,第二容器对应的第三系统,例如Android系统开始启动,如果启动成功,则通过对指定文件例如启动状态文件,进行写入表示启动成功的数据等方式告知宿主机系统Android系统正常启动,如果没有正常启动,则不操作。
可选地,宿主机系统访问启动状态文件的预设时间可以是Android系统的正常启动时间,还可以是Android系统正常启动时间加上延迟时间。其中,延迟时间可以根据经验设定。
具体的,宿主机系统根据常规情况下Android系统的正常启动时间再加一定的延长时间去访问启动状态文件,并确认Android系统是否出现启动异常。常规情况下的Android系统的正常启动时间可以通过保存之前常规情况下的正常启动时间来得到。增加延迟时间,则是由于每次启动,由于Android是多线程操作,可能出现较小的延迟。从而开机时间略有差异。当然,如果是非常规启动,比如恢复出厂设置,或者异常断电等情况,则对启动状态文件的访问方式可以进行适应性调整,例如,可以以预设周期进行访问。
本实施例通过采用启动状态文件的方式能够方便快捷的实现对第三系统启动状态的监听。
图2为本发明又一实施例提供的多系统启动方法的流程示意图。如图2所示,在上述实施例,如在图1所示实施例的基础上,本实施例中对在第二系统启动异常时第一系统对第二系统的调整方式进行了具体限定。该方法,包括:
201、第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统。
202、通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性。
203、根据监测得到的结果,判断第二系统的启动状态是否为启动异常,若是,则执行104,若否,则控制宿主机系统正常运行。
204、所述第一系统重新启动所述第二系统。
205、通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性。
206、根据监测得到的结果,判断第三系统的启动状态是否为启动异常,若是,则执行207,若否,则控制宿主机系统正常运行。
本实施例中步骤201至步骤206与上述实施例中步骤101至步骤106相类似,此处不再赘述。
207、根据第三系统的修复启动标志,判断第三系统的启动状态是否为修复启动,若否,则执行步骤208,若是,则执行步骤214。
208、所述第二系统在宿主机系统关闭所述第三系统的权限检测后,对所述第三系统的启动日志进行问题检索。
209、判断检索得到的问题是否为常规已知错误,若是,则执行步骤210,若否,则执行步骤211。
210、确定与常规已知错误对应的待修复文件的文件信息,并根据所述文件信息对所述待修复文件进行修复,所述第二系统将修复启动标志写入所述第三系统,以使所述第三系统根据所述修复启动标志进行修复启动。
211、通过所述宿主机系统将所述第三系统恢复出厂设置。
212、重新启动调整后的第三系统。
213、判断调整后的第三系统重启后的启动状态是否为启动异常,若是,则执行步骤214,若否,则控制宿主机系统正常运行。
214、保存所述启动日志,以在返厂后进行分析。
215、通过所述宿主机系统开启所述第三系统的权限检测。
实际应用中,第二容器对应的第三系统,例如Android系统开始启动,如果启动成功,则通过对指定文件例如启动状态文件,进行写固定成功数据等方式告知宿主机系统Android系统正常启动,如果没有正常启动,则不操作。宿主机系统在获取Android系统正常启动后,继续运行,无需进行其他操作。如果确认Android系统没有正常启动,则再确认Android系统是否是修复启动,修复启动的判断可参照以下说明。如果不是修复启动,则关闭整个系统的权限检测,并通知第一容器对应的第二系统,例如Linux系统,启动程序去检索Android系统的启动日志。如果是修复启动,则说明修复启动还是失败,则保存启动日志,待后续车辆返厂后,根据该启动日志进行问题分析。
Linux系统启动检索程序,对启动日志进行问题检索,若检索到的问题是已知常规问题,例如Data分区Android应用程序对应文件损坏,或者权限不对等问题,则根据检索结果,得到存在问题的待修复文件的文件名和文件路径,对待修复文件进行删除等修复工作。然后进行重启,并在重启前通过对指定文件写修复启动标志来表示此次重启是修复启动。重启后恢复所有权限检测,以避免文件被随意篡改,提升安全性。
若检索到的问题不是常规已知问题,则通知宿主机系统对Android系统对应容器进行重启,并发送进入恢复模式命令。Android系统则恢复出厂设置,之后进行重启。如果启动成功,则通知宿主机系统启动成功,如果失败,则Linux系统保存对应启动日志,待后续车辆返厂后,根据该启动日志进行问题分析。
本实施例提供的多系统启动方法,通过对权限检测进行动态管理,以便控制第二系统对第三系统的启动日志进行问题检索,根据检索结果对第三系统进行调整,能够提高稳定性较差的第三系统的启动成功率,从而能够提高多系统的启动成功率。
图3为本发明一实施例提供的多系统启动设备的结构示意图。如图3所示,所述多系统包括第一系统、宿主机系统、第一容器对应的第二系统和第二容器对应的第三系统,该多系统启动设备30包括:启动模块301、第一监测模块302、重启模块303、第二监测模块304和调整模块305。
启动模块301,用于在第一系统启动后,启动宿主机系统,并通过所述宿主机系统分别启动所述第一容器对应的第二系统和所述第二容器对应的第三系统;
第一监测模块302,用于通过所述第一系统对所述第二系统的启动状态进行监测;所述第一系统的启动稳定性高于所述第二系统的启动稳定性;
重启模块303,用于在所述第二系统的启动状态为启动异常时,通过所述第一系统重新启动所述第二系统;
第二监测模块304,用于通过所述第二系统对所述第三系统的启动状态进行监测;所述第二系统的启动稳定性高于所述第三系统的启动稳定性;
调整模块305,用于在所述第三系统的启动状态为启动异常时,通过所述第二系统对所述第三系统进行调整,并重新启动调整后的第三系统。
本发明实施例提供的多系统启动设备,通过最稳定的第一系统对较稳定的第二系统进行监测和辅助,提高了第二系统的启动成功率,且通过较稳定的第二系统对相对最不稳定的第三系统进行监测和辅助,提高了第三系统的启动成功率,从而提高了整个多系统的启动成功率。
在一种可能的设计中,第二监测模块304,具体用于:
所述第三系统在启动成功后,生成启动状态文件;
所述宿主机系统在预设时间内对所述第三系统的启动状态文件进行访问,确定所述第二系统的启动状态,并将所述第三系统的启动状态发送给所述第二系统。
在一种可能的设计中,调整模块305,具体用于:
所述第二系统对所述第三系统的启动日志进行问题检索;
若检索得到的问题为常规已知错误,则确定与常规已知错误对应的待修复文件的文件信息;
根据所述文件信息对所述待修复文件进行修复。
在一种可能的设计中,调整模块305,还具体用于:
若检索得到的问题为非常规已知错误,则通过所述宿主机系统将所述第三系统恢复出厂设置。
在一种可能的设计中,调整模块305,还具体用于:
若所述调整后的第三系统重启后的启动状态为启动异常,则保存所述启动日志,以在返厂后进行分析。
在一种可能的设计中,调整模块305,还具体用于:
所述第二系统将修复启动标志写入所述第三系统,以使所述第三系统根据所述修复启动标志进行修复启动;
若所述第三系统的启动状态为启动异常且为非修复启动,则所述第二系统在所述宿主机系统关闭所述第三系统的权限检测后,对所述第三系统进行调整。
在一种可能的设计中,调整模块305,还具体用于:
通过所述宿主机系统开启所述第三系统的权限检测。
在一种可能的设计中,重启模块303,具体用于:
所述第一系统将宿主机系统断电后再上电,实现对所述第二系统的重启。
本发明实施例提供的多系统启动设备,可用于执行上述的方法实施例,其实现原理和技术效果类似,本实施例此处不再赘述。
图4为本发明一实施例提供的多系统启动设备的硬件结构示意图。如图4所示,本实施例提供的多系统启动设备40包括:至少一个处理器401和存储器402。其中,处理器401和存储器402通过总线403连接。
在具体实现过程中,至少一个处理器401执行所述存储器402存储的计算机执行指令,使得至少一个处理器401执行如上多系统启动设备40所执行的多系统启动方法。
处理器401的具体实现过程可参见上述方法实施例,其实现原理和技术效果类似,本实施例此处不再赘述。
在上述的图4所示的实施例中,应理解,处理器可以是中央处理单元(英文:Central Processing Unit,简称:CPU),还可以是其他通用处理器、数字信号处理器(英文:Digital Signal Processor,简称:DSP)、专用集成电路(英文:Application SpecificIntegrated Circuit,简称:ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器,也可能还包括非易失性存储NVM,例如至少一个磁盘存储器。
总线可以是工业标准体系结构(Industry Standard Architecture,ISA)总线、外部设备互连(Peripheral Component,PCI)总线或扩展工业标准体系结构(ExtendedIndustry Standard Architecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
本发明实施例还提供一种计算机程序产品,包括计算机程序,所述计算机程序被处理器执行时,实现如上多系统启动设备执行的多系统启动方法。
本发明实施例还提供一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如上多系统启动设备执行的多系统启动方法。
上述的计算机可读存储介质,上述可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(SRAM),电可擦除可编程只读存储器(EEPROM),可擦除可编程只读存储器(EPROM),可编程只读存储器(PROM),只读存储器(ROM),磁存储器,快闪存储器,磁盘或光盘。可读存储介质可以是通用或专用计算机能够存取的任何可用介质。
一种示例性的可读存储介质耦合至处理器,从而使处理器能够从该可读存储介质读取信息,且可向该可读存储介质写入信息。当然,可读存储介质也可以是处理器的组成部分。处理器和可读存储介质可以位于专用集成电路(Application Specific IntegratedCircuits,简称:ASIC)中。当然,处理器和可读存储介质也可以作为分立组件存在于设备中。
本领域普通技术人员可以理解:实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时,执行包括上述各方法实施例的步骤;而前述的存储介质包括:ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是:以上各实施例仅用以说明本发明的技术方案,而非对其限制;尽管参照前述各实施例对本发明进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。