CN117539593A - 一种车机系统的控制方法及装置 - Google Patents
一种车机系统的控制方法及装置 Download PDFInfo
- Publication number
- CN117539593A CN117539593A CN202311856596.0A CN202311856596A CN117539593A CN 117539593 A CN117539593 A CN 117539593A CN 202311856596 A CN202311856596 A CN 202311856596A CN 117539593 A CN117539593 A CN 117539593A
- Authority
- CN
- China
- Prior art keywords
- container
- vehicle
- ivi
- restarting
- restart
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 66
- 238000012544 monitoring process Methods 0.000 claims description 37
- 230000008569 process Effects 0.000 claims description 20
- 238000011084 recovery Methods 0.000 claims description 11
- 230000001105 regulatory effect Effects 0.000 claims description 7
- 230000001960 triggered effect Effects 0.000 claims description 5
- 230000001680 brushing effect Effects 0.000 claims description 4
- 230000001276 controlling effect Effects 0.000 claims description 3
- 238000005516 engineering process Methods 0.000 description 14
- 238000012545 processing Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000013473 artificial intelligence Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
- B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Mechanical Engineering (AREA)
- Stored Programmes (AREA)
Abstract
本发明提出一种车机系统的控制方法及装置,其中,方法包括容器管理服务接收IVI容器的退出信号,并根据退出信号的值确定车机系统的退出操作;在确定车机系统的退出操作为重启时,容器管理服务获取退出信号的重启属性参数;容器管理服务根据重启属性参数确定车机系统是执行整机重启还是执行IVI容器单独重启;若容器管理服务根据重启属性参数确定车机系统是执行整机重启,则容器管理服务调用车机系统的整机重启命令,以触发车机系统执行整机重启;若容器管理服务根据重启属性参数确定车机系统是执行IVI容器单独重启,则容器管理服务执行IVI容器的重启操作,以满足车机系统在各种应用场景下的重启需求。
Description
技术领域
本发明涉及车机系统技术领域,尤其涉及一种车机系统的控制方法及装置。
背景技术
近年来,科技和经济迅速发展,汽车在人们的日常生活中越来越普及,推动了汽车产业的蓬勃发展。特别是新能源技术、通信技术、人工智能等前沿科技的进步,引领汽车产业朝着新四化的方向迈进。整车厂、汽车零部件企业以及其他相关企业都深入参与其中并发生着深刻变化,智能座舱、智能驾驶、车联网等新技术成为行业关注的焦点,同时也带来了更高的技术复杂度和成本。在这样的背景下,如何平衡功能、成本等指标以获取市场成为整车最终落地必须考虑的问题。
以智能座舱为例,现在市场上汽车除了配置传统的汽车仪表之外,还配置了车载信息娱乐系统(In-Vehicle Infotainment,IVI)等系统,以实现车载娱乐、辅助驾驶等功能。早期版本的IVI系统配置了专用的主机,一方面成本较高,存在主机资源未被充分利用的情况,另一方面,IVI系统与车辆中原有设施的集成也存在一些问题。
针对这些问题,出现了一机多屏的方案,即汽车仪表系统、IVI系统等承载在一个主机上。具体地,已有方案中,采用虚拟机技术,汽车仪表系统、IVI系统等分别运行在一个虚拟机上。然而,多个虚拟机的系统程序需要较多的主机运算资源,这就要求主机具备较强大的运算能力,导致依然存在成本高的问题。
进一步地,针对虚拟机技术需要占用较多主机运算资源的问题,一种可能的方案是采用容器化技术,发明人对此进行了研究。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为达上述目的,本发明第一方面实施例提出了一种车机系统的控制方法,应用于车机系统,所述车机系统包括内核,所述内核上运行有运行在Host系统中的仪表系统和至少一个容器,所述至少一个容器由所述仪表系统中的容器管理服务创建,所述至少一个容器包括IVI容器,所述IVI容器中运行有IVI系统,所述车机系统的控制方法包括:
所述容器管理服务接收所述IVI容器的退出信号,并根据所述退出信号的值确定所述车机系统的退出操作;在确定所述车机系统的退出操作为重启时,所述容器管理服务获取所述退出信号的重启属性参数;所述容器管理服务根据所述重启属性参数,确定所述车机系统是执行整机重启还是执行IVI容器单独重启;若所述容器管理服务根据所述重启属性参数确定所述车机系统是执行整机重启,则所述容器管理服务调用所述车机系统的整机重启命令,以触发所述车机系统执行整机重启;若所述容器管理服务根据所述重启属性参数确定所述车机系统是执行IVI容器单独重启,则所述容器管理服务执行所述IVI容器的重启操作。
在第一方面的一具体实施例中,所述容器管理服务根据所述重启属性参数,确定所述车机系统是执行整机重启还是执行IVI容器单独重启,包括:
所述容器管理服务将所述重启属性参数与预置条件集合中的元素逐一比对,判断所述重启属性参数是否符合所述预置条件集合;其中,所述预置条件集合为所述容器管理服务预先设置的整机重启参数的集合;若所述重启属性参数符合所述预置条件集合,则确定所述车机系统执行整机重启;若所述重启属性参数不符合所述预置条件集合,则确定所述车机系统执行IVI容器单独重启。
在第一方面的一具体实施例中,所述预置条件集合中的每个整机重启参数表征一种车机系统执行整机重启的原因,包括IVI系统发动整机重启、 IVI系统发动车机系统恢复、重新烧写恢复车机系统、进入云重启模式、进入端口刷机模式和进入救援模式。
在第一方面的一具体实施例中,还包括:
在确定车机系统的退出操作为关机时,容器管理服务获取退出信号的关机属性参数,并调用所述车机系统的整机关机命令,以触发所述车机系统执行整机关机。
在第一方面的一具体实施例中,还包括:
容器管理服务对执行所述控制方法的子进程进行加锁处理。
在第一方面的一具体实施例中,Host系统中还包括容器监测服务,所述车机系统的控制方法还包括:
容器管理服务执行IVI容器的单独重启操作时,所述容器监测服务开始监测所述IVI容器的退出状态;在所述容器监测服务监测到所述IVI容器退出成功时,所述容器管理服务基于预先设置的启动阈值时长和所述IVI系统中的启动标志来确定所述IVI容器的启动状态;若在所述启动阈值时长内所述IVI系统的启动标志表征所述IVI容器启动成功,则所述容器管理服务判定所述IVI容器重启成功;若达到所述启动阈值时长后所述IVI系统的启动标志仍未表征所述IVI容器启动成功,则所述容器管理服务判定所述IVI容器重启失败,重新执行所述IVI容器的单独重启操作。
在第一方面的一具体实施例中,所述容器监测服务监测IVI容器的退出状态,包括:
容器管理服务执行所述IVI容器的单独重启操作时,所述容器监测服务调用计时器开始对所述IVI容器的退出过程进行计时;所述容器监测服务基于预先设置的退出阈值时长和所述计时器的实际计时时长,来确定所述IVI容器的退出状态;若所述实际计时时长未达到所述退出阈值时长,则判定所述IVI容器退出成功,将计时器停止并清零;若所述实际计时时长达到所述退出阈值时长,则判定所述IVI容器退出失败,并调用车机系统的整机重启命令,以触发所述车机系统执行整机重启。
在第一方面的一具体实施例中,还包括:
容器管理服务统计判定IVI容器重启失败的次数或频率;在判定IVI容器重启失败的次数达到阈值次数时,调用车机系统的整机重启命令,以触发所述车机系统执行整机重启;或者在判定IVI容器重启失败的频率达到阈值频率时,调用车机系统的整机重启命令,以触发所述车机系统执行整机重启。
在第一方面的一具体实施例中,应用于Host系统采用Android系统时,所述容器管理服务调用车机系统的整机重启命令,以触发所述车机系统执行整机重启,包括:所述容器管理服务将所述车机系统的系统属性赋值为reboot,通过init进程调用内核中的reboot()函数来执行所述整机重启。
在第一方面的一具体实施例中,还包括:
容器管理服务执行IVI容器单独重启时,触发守护进程来守护容器监测服务执行监测任务。
为达上述目的,本发明第二方面实施例提出了一种车机系统的控制装置,应用于车机系统,所述车机系统包括内核,所述内核上运行有运行在Host系统中的仪表系统和至少一个容器,所述至少一个容器由所述仪表系统中的容器管理服务创建,所述至少一个容器包括IVI容器,所述IVI容器中运行有IVI系统;
所述车机系统的控制装置包括:
接收单元,用于接收所述IVI容器的退出信号,并根据所述退出信号的值确定所述车机系统的退出操作;获取单元,用于在确定所述车机系统的退出操作为重启时,获取所述退出信号的重启属性参数;确定单元,用于根据所述重启属性参数确定,所述车机系统是执行整机重启还是执行IVI容器单独重启;整机重启单元,用于在根据所述重启属性参数确定所述车机系统是执行整机重启时,调用所述车机系统的整机重启命令,以触发所述车机系统执行整机重启;容器单独重启单元,用于在根据所述重启属性参数确定所述车机系统是执行IVI容器单独重启时,执行所述IVI容器的重启操作;其中,所述接收单元、所述获取单元、所述确定单元、所述整机重启单元、所述容器单独重启单元都位于所述容器管理服务中。
本发明的有益效果:
本发明基于一套硬件设备,在Host系统中运行仪表系统,采用容器化技术实现至少一个容器用以运行IVI系统等其它操作系统的方式实现车机系统,在保障车机系统功能健全和运行速率快等前提下,实现主机运算资源占用量和车机成本的显著降低;
在此基础上,仪表系统中的容器管理服务作为容器的创建方与管理方,通过接收到的IVI容器的退出信号来确定车机系统的退出操作,在车机系统的退出操作为重启时,能够根据获取到的重启属性参数确定车机系统需要执行整机重启还是IVI容器单独重启,并控制IVI容器单独重启或触发车机系统实现整机重启,以满足车机系统在各种应用场景下的重启需求。
附图说明
图1为本发明实施例提供的一种车机系统的控制方法的流程图;
图2为本发明实施例提供的一种车机系统的控制装置的方框示意图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点,下面结合附图和具体实施例对本发明进行详细描述。需要说明的是,在不冲突的情况下,本发明的实施例及实施例中的特征可以相互组合。
为方便理解,首先结合本发明的技术方案对本发明中涉及的自定义词和应用场景进行说明:
Host系统:运行在车机系统的内核上,负责管理车机仪表系统的数据资源、硬件和软件的操作系统。
IVI系统(In-Vehicle Infotainment,车载信息娱乐系统):运行在IVI容器中的操作系统,其中IVI容器运行于车机系统的内核上,IVI系统负责提供车机系统的信息娱乐和导航服务等。
容器管理服务:设置于仪表系统中,负责创建/启动容器、管理容器的运行状态的应用程序。用于创建多个子进程以创建/启动多个容器,并在创建容器的子进程中注册回调函数以检测容器的退出状态,子进程(容器)退出时容器管理服务会接收到相应的退出信号,并根据该退出信号对容器进行对应的管理操作;
重启属性参数:体现容器执行重启原因的参数,包括重启命令reboot和表征重启原因的参数。能够为车机系统执行重启的方式提供依据,使容器管理服务能够基于重启属性参数决定车机系统需要执行整机重启还是IVI容器单独重启。例如,重启属性参数为“reboot,recovery”时,表征容器发动系统恢复,容器管理服务据此能够确定车机系统需要执行整机重启以恢复发动系统。
预置条件集合:预先设置在容器管理服务中,存储所有互异的整机重启参数的集合,包括至少一个整机重启参数,整机重启参数的具体数量由业务、应用场景等决定。预置条件集合中的整机重启参数与重启属性参数的比对结果,能够作为容器管理服务确定车机系统执行重启的方式的依据。例如,重启属性参数为“reboot,recovery”,预置条件集合中的整机重启参数包括“reboot,recovery”,则容器管理服务能够据此确定车机系统需要执行整机重启。
整机重启参数:根据车机系统需要执行整机重启的原因或应用场景,预先配置在容器管理服务中的参数,包括重启命令reboot和表征车机系统执行整机重启原因的参数,所有互异的整机重启参数都存储于预置条件集合中。重启属性参数与整机重启参数一致时,容器管理服务会基于重启属性参数触发车机系统执行整机重启。
关机属性参数:表征车机系统执行整机关机的参数,包括关机命令shutdown。容器管理服务能够基于关机属性参数触发车机系统执行整机关机。
容器监测服务:设置于Host系统中,负责监测IVI容器的退出状态的应用程序。实际应用时,容器监测服务通过容器管理服务获知IVI容器的退出状态,对计时器设置计时总时长,并调用计时器对IVI容器的退出过程进行计时,在计时器的实际计时时长未达到计时器的计时总时长的情况下,容器监测服务认定IVI容器退出成功;在计时器的实际计时时长达到计时器的计时总时长的情况下,容器监测服务认定IVI容器退出失败,调用所述车机系统的整机重启命令,触发车机系统执行整机重启。
IVI系统的启动标志:用于表征IVI系统完成启动的标志,能够被容器管理服务获取以得到IVI容器的启动状态。在IVI系统采用Android系统时,可以将Android系统属性sys.boot.completed作为IVI系统的启动标志,Android系统启动完成后会为Android系统属性sys.boot.completed赋值(sys.boot.completed=1);在IVI系统采用Linux或其它操作系统时,IVI系统的启动标志可以由容器管理系统预先设置。
启动阈值时长:人为预先设置于容器管理服务中的时间长度,是容器管理服务允许IVI容器启动花费时长的最大值。启动阈值时长的具体数值可根据业务、应用场景等决定。
退出阈值时长:人为预先设置于容器监测服务中的时间长度,也是容器监测服务中对计时器设置的计时总时长,比容器监测服务允许IVI容器退出花费时长的最大值略大,退出阈值时长的具体数值可根据业务、应用场景等决定。实际应用时,在计时器的实际计时时长未达到退出阈值时长(计时器的计时总时长)的情况下,说明在退出阈值时长内IVI容器的退出成功;在计时器的实际计时时长达到退出阈值时长(计时器的计时总时长)的情况下,说明IVI容器的退出超时,IVI容器的重启过程中出现严重卡机状况,需要车机系统执行整机重启。
本发明中涉及的车机系统基于一套硬件设备开发,在内核上运行Host系统和容器化技术实现的容器,容器的数量为至少一个,在裁剪过的Host系统中运行仪表系统以保证仪表系统的高可靠性,在第一容器(IVI容器)中运行IVI系统。
Host系统和IVI系统(In-Vehicle Infotainment,车载信息娱乐系统)分别对应一个操作系统,两个操作系统可以是相同种类的,也可以是不同种类的;例如,Host系统采用Linux系统,IVI系统采用Android系统;或者,Host系统是Android系统,IVI系统采用Linux系统;再或者,两个操作系统均采用Android系统;
需要说明的是,即使Host系统和IVI系统是相同种类的操作系统,Host系统和IVI系统也不必是完全相同的操作系统,可以对操作系统进行一定的裁剪和定制化,例如Host系统采用裁剪的Android系统,IVI系统采用完整/标准的Android系统。
在一种具体实施方式中,Host系统和IVI系统基于Android开源项目(AOSP)进行开发,Host系统采用裁剪过的定制化Android系统来运行车机系统中的仪表系统,IVI系统使用Android应用程序框架来运行Android应用程序以实现汽车信息娱乐需求,操作系统之间采用容器技术相互隔离;
在传统采用两套独立的硬件设备分别开发仪表系统和IVI系统的车机系统中,以及在传统采用虚拟化技术实现一机多系统的车机系统中,仪表系统和IVI系统的内核是独立的,每个操作系统都有自己的内核。因此,在其中一个操作系统需要单独重启时,调用重启命令通过init进程执行重启操作,例如操作系统采用Android系统,需要单独重启时通常会将该操作系统属性设置为sys.powerctl.reboot,通过调用该操作系统对应的内核中的系统调用函数来控制该操作系统的重启;
而本发明涉及的车机系统基于一套硬件设备开发,仪表系统运行在Host系统中,IVI系统运行在采用容器化技术实现的IVI容器中。故IVI系统需要单独重启时,若不对IVI系统的单独重启操作作出处理,则IVI系统调用重启命令后,init进程会通过调用内核中的reboot()系统调用函数实现整机重启,将导致仪表屏幕的黑屏,影响仪表系统的正常使用。
因此,本发明的车机系统在仪表系统中设置容器管理服务,负责创建/启动IVI容器和管理IVI容器重启等操作。具体地,IVI容器执行重启操作时,先后进行了IVI容器退出和IVI容器启动两个流程;IVI容器进行退出流程时,将IVI容器的重启原因写入IVI重启文件中,且由于IVI容器是容器管理服务通过创建子进程来创建/启动的,IVI容器是容器管理服务的子进程,故IVI容器退出时容器管理服务会接收到IVI容器的退出信号,然后容器管理服务从IVI重启文件中查找IVI容器的重启原因,生成重启属性参数,并根据重启属性参数确定车机系统是执行整机重启还是执行IVI容器单独重启;若确定车机系统执行整机重启,则调用车机系统的整机重启命令,通过init进程调用内核中的系统调用函数实现车机系统的整机重启;若确定车机系统执行IVI容器重启,则由容器管理服务执行IVI容器的重启操作,不再调用车机系统的整机重启命令,也不会通过init进程调用内核中的系统调用函数执行车机系统的整机重启。
通过容器管理服务来获取IVI容器的重启原因,以区分IVI容器单独重启和整机重启两种重启需求,区分后容器管理服务使用两种控制重启方法来分别实现控制IVI容器单独重启或触发整机重启,避免IVI系统单独重启影响仪表系统的正常使用,从而满足车机系统在各种应用场景下的重启需求。
实际应用中,为了进一步满足人们对于汽车娱乐的需求,车机系统还包括副驾娱乐系统(Passenger Entertainment System,FSE),在第二容器(FSE容器)中运行FSE系统。本发明涉及的IVI容器的创建/启动和IVI容器的单独重启等所有对IVI容器的管理操作同样适用于FSE容器。
下面结合附图描述本发明实施例的车机系统的控制方法。
如图1所示,本发明实施例的一种车机系统的控制方法,应用于车机系统,车机系统包括内核,内核上运行有运行在Host系统中的仪表系统和至少一个容器,所述至少一个容器由仪表系统中的容器管理服务创建,所述至少一个容器包括IVI容器,IVI容器中运行有IVI系统,车机系统的控制方法包括:
容器管理服务接收IVI容器的退出信号,并根据退出信号的值确定车机系统的退出操作;
可以理解,IVI容器的退出信号包括SIGHUP信号和SIGINT信号,IVI容器的退出信号值为SIGHUP时,车机系统的退出操作为重启;IVI容器的退出信号值为SIGINT时,车机系统的退出操作为关机;
在确定车机系统的退出操作为重启时,容器管理服务获取退出信号的重启属性参数;
容器管理服务根据重启属性参数,确定车机系统是执行整机重启还是执行IVI容器单独重启;
若容器管理服务根据重启属性参数确定车机系统是执行整机重启,则容器管理服务调用所述车机系统的整机重启命令,以触发车机系统执行整机重启;
若容器管理服务根据重启属性参数确定车机系统是执行IVI容器单独重启,则容器管理服务执行IVI容器的重启操作。
需要说明的是, IVI容器由容器管理服务创建/启动,IVI容器是容器管理服务的子进程,因此容器管理服务能够执行IVI容器的重启操作。
在一些实施例中,车机系统中的Host系统采用经裁剪后的定制化Android系统,Android系统中存在系统属性sys.powerctl,则容器管理服务调用车机系统的整机重启命令reboot,以触发车机系统执行整机重启,具体为将Android系统的系统属性赋值为reboot即setprop sys.powerctl reboot,sys.powerctlreboot属性用于控制车机系统执行整机重启,重启操作由Init进程调用内核中的reboot系统调用函数来执行。优选地,容器管理服务将车机系统的系统属性赋值为reboot时,直接将重启属性参数中的reboot赋给系统属性sys.powerctl。
在另一些实施例中,车机系统中的Host系统采用经裁剪后的定制化linux系统,则容器管理服务调用车机系统的整机重启命令reboot,以触发车机系统执行整机重启,具体为整机重启命令reboot调用内核中的reboot函数来执行整机重启。
还需要说明的是,在IVI容器执行重启操作的情况下,IVI容器会先后执行退出和启动两个操作,在IVI容器执行退出操作的流程中,会将IVI容器的重启原因写入IVI重启文件中,并向容器管理服务发送退出信号;容器管理服务信号接收到IVI容器的退出信号后,从IVI重启文件中读取出IVI容器的重启原因,并根据IVI容器的重启原因生成重启属性参数;由于重启属性参数表征IVI容器的重启原因,因此容器管理服务能够根据重启属性参数确定车机系统需要执行IVI单独重启还是需要执行整机重启。
在一些实施例中,容器管理服务能够根据重启属性参数表征的IVI容器的重启原因,结合汽车使用场景分析出车机系统需要执行的重启方式;在另一些实施例中,容器管理系服务预先根据业务、应用场景等规划出车机系统需要执行整机重启或IVI单独重启的条件集合,判断重启属性参数表征的IVI容器的重启原因是否满足预先设置的条件集合,满足时控制车机系统执行该条件集合对应的重启方式。
本发明实施例的车机系统基于一套硬件设备,在Host系统中运行仪表系统,采用容器化技术实现至少一个容器用以运行IVI系统等其它操作系统的方式实现车机系统,在保障车机系统功能健全和运行速率快等前提下,实现主机运算资源占用量和车机成本的显著降低;
本发明实施例的车机系统的控制方法中,容器管理服务作为容器的创建方与管理方,通过接收到的IVI容器的退出信号来确定车机系统的退出操作,在车机系统的退出操作为重启时,能够根据获取到的重启属性参数确定车机系统需要执行整机重启还是IVI容器单独重启,并控制IVI容器单独重启或触发车机系统实现整机重启,以满足车机系统在各种应用场景下的重启需求。
在一些实施例中,容器管理服务根据重启属性参数,确定车机系统是执行整机重启还是执行IVI容器单独重启,包括:
容器管理服务将重启属性参数与预置条件集合中的元素逐一比对,判断重启属性参数是否符合预置条件集合;其中,预置条件集合为容器管理服务预先设置的整机重启参数的集合;
若重启属性参数符合预置条件集合,则确定所述车机系统执行整机重启;
若重启属性参数不符合预置条件集合,则确定所述车机系统执行IVI容器单独重启。
需要说明的是,预置条件集合中的整机重启参数包括"reboot,fission-all"、"reboot,recovery" 、"reboot,bootloader" 、"reboot,bydcloud"、"reboot,edl"和reboot,rescueparty-tryReboot",重启属性参数与预置条件集合中的其中一个整机重启参数相同或一致时,说明车机系统需要执行整机重启;重启属性参数与预置条件集合中的所有整机重启参数都不相同或不一致时,说明车机系统不需要执行整机重启,车机系统需要执行IVI容器单独重启。
还需要说明的是,在另一些实施例中,容器管理服务将重启属性参数与预置条件集合中的元素逐一比对,判断重启属性参数是否符合预置条件集合;其中,预置条件集合为容器管理服务预先设置的IVI单独重启参数的集合;若重启属性参数符合预置条件集合,则车机系统执行IVI容器单独重启;若重启属性参数不符合预置条件集合,则车机系统执行整机重启。
在一些实施例中,预置条件集合中的每个整机重启参数表征一种车机系统执行整机重启的原因,包括IVI系统发动整机重启、 IVI系统发动车机系统恢复、重新烧写恢复车机系统、进入云重启模式、进入端口刷机模式和进入救援模式。
具体地,整机重启参数"reboot,fission-all"表征IVI系统发动整机重启;整机重启参数"reboot,recovery"表征IVI系统发动车机系统恢复;整机重启参数"reboot,bootloader"表征重新烧写恢复车机系统;整机重启参数"reboot,bydcloud"表征入云重启模式;整机重启参数"reboot,edl"表征进入端口刷机模式;整机重启参数"reboot,rescueparty-tryReboot"表征进入救援模式。
在一些实施例中,车机系统的控制方法还包括:
在确定车机系统的退出操作为关机时,容器管理服务获取退出信号的关机属性参数,并调用所述车机系统的整机关机命令shutdown,以触发车机系统执行整机关机。
在一些实施例中,车机系统中的Host系统采用经裁剪后的定制化Android系统,Android系统中存在系统属性sys.powerctl,则容器管理服务调用车机系统的整机关机命令,以触发车机系统执行整机关机,具体为将Android系统的系统属性赋值为shutdown即setprop sys.powerctl shutdown,sys.powerctlshutdown属性用于控制车机系统执行整机关机,关机操作由Init进程调用内核中的shutdown系统调用函数来执行。优选地,容器管理服务将车机系统的系统属性赋值为shutdown时,直接将关机属性参数中的shutdown赋给系统属性sys.powerctl。
需要说明的是,IVI容器在执行关机操作时,将IVI容器的关机原因写入IVI关机文件中,并向容器管理服务发送退出信号,退出信号值为SIGINT;当容器管理服务接收到SIGINT信号时,从IVI关机文件中读取IVI容器的关机原因,生成关机属性参数。
还需要说明的是,在目前的车机系统使用场景中,还未涉及到单独关闭IVI容器的需求,因此容器管理服务获取SIGINT信号时,获取关机属性参数后直接调用所述车机系统的整机关机命令shutdown,触发车机系统执行整机关机;之后随着车机系统应用场景的扩展,可能会涉及到单独关闭IVI容器的需求,因此在另一些实施例中,容器管理服务接收到SIGINT信号时,获取关机属性参数并根据关机属性参数表征的IVI容器的关闭原因确定车机系统需要执行整机关机还是IVI容器单独关机。
在一些实施例中,车机系统的控制方法还包括:
容器管理服务对执行控制方法的子进程进行加锁处理。
需要说明的是,容器管理服务是多线程的应用程序,为了保护对执行车机系统的控制方法的子进程的访问,对所述执行控制方法的子进程进行加锁处理。
在一些实施例中,Host系统中还包括容器监测服务,车机系统的控制方法还包括:
容器管理服务执行IVI容器的单独重启操作时,容器监测服务开始监测所述IVI容器的退出状态;
在容器监测服务监测到IVI容器退出成功时,容器管理服务基于预先设置的启动阈值时长和IVI系统中的启动标志来确定IVI容器的启动状态;
若在启动阈值时长内IVI系统的启动标志表征IVI容器启动成功,则容器管理服务判定IVI容器重启成功;
若达到启动阈值时长后IVI系统的启动标志仍未表征IVI容器启动成功,则容器管理服务判定IVI容器重启失败,重新执行IVI容器的单独重启操作。
在一些实施例中,IVI系统采用Android系统,Android系统存在系统属性sys.boot.completed,可以作为IVI系统的启动标志;sys.boot.completed作为IVI系统的启动标志时,其默认值为sys.boot.completed=0,表征IVI容器还未启动成功,Android系统启动完成后会为Android系统属性sys.boot.completed赋值即sys.boot.completed=1,表征IVI容器启动成功;达到启动阈值时长后IVI系统的启动标志sys.boot.completed=0,说明IVI容器启动一直未成功,则容器管理服务判定IVI容器重启失败。
在一些实施例中,容器监测服务监测IVI容器的退出状态,包括:
容器管理服务执行所述IVI容器的单独重启操作时,所述容器监测服务调用计时器开始对所述IVI容器的退出过程进行计时;
上述计时器可以是车机系统独立设置的,也可以集成于容器监测服务内;
所述容器监测服务基于预先设置的退出阈值时长和所述计时器的实际计时时长,来确定所述IVI容器的退出状态;
若所述实际计时时长未达到所述退出阈值时长,则判定所述IVI容器退出成功,将计时器停止并清零;
若所述实际计时时长达到所述退出阈值时长,则判定所述IVI容器退出失败,并调用车机系统的整机重启命令,以触发所述车机系统执行整机重启。
需要说明的是,容器监测服务预先对计时器设置计时总时长,并设置计时器在IVI容器退出成功时或达到计时总时长时停止计时并清零。计时器的实际计时时长未达到退出阈值时长,说明IVI容器的退出时长小于退出阈值时长,判定IVI容器退出成功,计时器因IVI容器退出成功而被容器监测服务停止并清零;计时器的实际计时时长达到退出阈值时长,说明IVI容器的退出时长大于退出阈值时长,判定IVI容器退出失败,计时器因达到计时总时长时停止计时并清零。
还需要说明的是,IVI容器重启的过程中,若IVI容器在退出流程中被判定为IVI容器退出失败,说明IVI容器在退出过程中卡机,则只能通过车机系统执行整机重启的方式重启IVI容器。
在一些实施例中,车机系统的控制方法还包括:
容器管理服务统计判定IVI容器重启失败的次数或频率;
在判定IVI容器重启失败的次数达到阈值次数时,调用车机系统的整机重启命令,以触发车机系统执行整机重启;或者
在判定IVI容器重启失败的频率达到阈值频率时,调用车机系统的整机重启命令,以触发车机系统执行整机重启。
需要说明的是,IVI容器单独重启失败的次数或频率过高,则IVI容器单独重启失败的原因通常会涉及Host系统侧,因此需要执行整机重启来重启IVI容器。
在一些实施例中,应用于Host系统采用Android系统时,容器管理服务调用车机系统的整机重启命令,以触发所述车机系统执行整机重启,包括:
容器管理服务将车机系统的系统属性赋值为reboot,通过init进程调用内核中的reboot()函数执行所述整机重启。
在一些实施例中,车机系统的控制方法还包括:
容器管理服务执行IVI容器单独重启时,触发守护进程来守护容器监测服务执行监测任务。
需要说明的是,守护进程在容器管理服务每次执行IVI容器单独重启时启动,开始守护容器监测服务执行监测任务;在计时器计时停止后停止,结束本次的监测任务。
下面结合附图描述本发明实施例的一种车机系统的控制装置。
如图2所示,本发明实施例的一种车机系统的控制装置,应用于车机系统,车机系统包括内核,内核上运行有运行在Host系统中的仪表系统和至少一个容器,至少一个容器由仪表系统中的容器管理服务创建,至少一个容器包括IVI容器,IVI容器中运行有IVI系统;
车机系统的控制装置包括:
接收单元,用于接收IVI容器的退出信号,并根据退出信号的值确定车机系统的退出操作;
获取单元,用于在确定车机系统的退出操作为重启时,获取退出信号的重启属性参数;
确定单元,用于根据重启属性参数,确定车机系统是执行整机重启还是执行IVI容器单独重启;
整机重启单元,用于在根据重启属性参数确定车机系统是执行整机重启时,调用所述车机系统的整机重启命令,以触发车机系统执行整机重启;
容器单独重启单元,用于在根据重启属性参数确定车机系统是执行IVI容器单独重启时,执行IVI容器的重启操作;
其中,接收单元、获取单元、确定单元、整机重启单元、容器单独重启单元都位于容器管理服务中。
本发明实施例的一种车机系统基于一套硬件设备,在Host系统中运行仪表系统,采用容器化技术实现至少一个容器用以运行IVI系统等其它操作系统的方式实现车机系统,在保障车机系统功能健全和运行速率快等前提下,实现主机运算资源占用量和车机成本的显著降低;
本发明实施例的车机系统的控制装置中,接收单元通过接收到的IVI容器的退出信号来确定车机系统的退出操作,获取单元在车机系统的退出操作为重启时,获取重启属性参数,确定单元根据获取到的重启属性参数确定车机系统需要执行整机重启还是IVI容器单独重启,整机重启单元触发车机系统执行整机重启,容器单独重启单元控制IVI容器单独重启,以满足车机系统在各种应用场景下的重启需求。
Claims (10)
1.一种车机系统的控制方法,其特征在于,应用于车机系统,所述车机系统包括内核,所述内核上运行有运行在Host系统中的仪表系统和至少一个容器,所述至少一个容器由所述仪表系统中的容器管理服务创建,所述至少一个容器包括IVI容器,所述IVI容器中运行有IVI系统,所述车机系统的控制方法包括:
所述容器管理服务接收所述IVI容器的退出信号,并根据所述退出信号的值确定所述车机系统的退出操作;
在确定所述车机系统的退出操作为重启时,所述容器管理服务获取所述退出信号的重启属性参数;
所述容器管理服务根据所述重启属性参数,确定所述车机系统是执行整机重启还是执行IVI容器单独重启;
若所述容器管理服务根据所述重启属性参数确定所述车机系统是执行整机重启,则所述容器管理服务调用所述车机系统的整机重启命令,以触发所述车机系统执行整机重启;
若所述容器管理服务根据所述重启属性参数确定所述车机系统是执行IVI容器单独重启,则所述容器管理服务执行所述IVI容器的重启操作。
2.如权利要求1所述的车机系统的控制方法,其特征在于,所述容器管理服务根据所述重启属性参数,确定所述车机系统是执行整机重启还是执行IVI容器单独重启,包括:
所述容器管理服务将所述重启属性参数与预置条件集合中的元素逐一比对,判断所述重启属性参数是否符合所述预置条件集合;其中,所述预置条件集合为所述容器管理服务预先设置的整机重启参数的集合;
若所述重启属性参数符合所述预置条件集合,则确定所述车机系统执行整机重启;
若所述重启属性参数不符合所述预置条件集合,则确定所述车机系统执行IVI容器单独重启。
3.如权利要求2所述的车机系统的控制方法,其特征在于,所述预置条件集合中的每个整机重启参数表征一种车机系统执行整机重启的原因,包括IVI系统发动整机重启、IVI系统发动车机系统恢复、重新烧写恢复车机系统、进入云重启模式、进入端口刷机模式和进入救援模式。
4.如权利要求1所述的车机系统的控制方法,其特征在于,还包括:
在确定车机系统的退出操作为关机时,容器管理服务获取退出信号的关机属性参数,并调用所述车机系统的整机关机命令,以触发所述车机系统执行整机关机。
5.如权利要求1所述的车机系统的控制方法,其特征在于,Host系统中还包括容器监测服务,所述车机系统的控制方法还包括:
容器管理服务执行IVI容器的单独重启操作时,所述容器监测服务开始监测所述IVI容器的退出状态;
在所述容器监测服务监测到所述IVI容器退出成功时,所述容器管理服务基于预先设置的启动阈值时长和所述IVI系统中的启动标志来确定所述IVI容器的启动状态;
若在所述启动阈值时长内所述IVI系统的启动标志表征所述IVI容器启动成功,则所述容器管理服务判定所述IVI容器重启成功;
若达到所述启动阈值时长后所述IVI系统的启动标志仍未表征所述IVI容器启动成功,则所述容器管理服务判定所述IVI容器重启失败,重新执行所述IVI容器的单独重启操作。
6.如权利要求5所述的车机系统的控制方法,其特征在于,所述容器监测服务监测IVI容器的退出状态,包括:
容器管理服务执行所述IVI容器的单独重启操作时,所述容器监测服务调用计时器开始对所述IVI容器的退出过程进行计时;
所述容器监测服务基于预先设置的退出阈值时长和所述计时器的实际计时时长,来确定所述IVI容器的退出状态;
若所述实际计时时长未达到所述退出阈值时长,则判定所述IVI容器退出成功,将计时器停止并清零;
若所述实际计时时长达到所述退出阈值时长,则判定所述IVI容器退出失败,并调用车机系统的整机重启命令,以触发所述车机系统执行整机重启。
7.如权利要求5所述的车机系统的控制方法,其特征在于,还包括:
容器管理服务统计判定IVI容器重启失败的次数或频率;
在判定IVI容器重启失败的次数达到阈值次数时,调用车机系统的整机重启命令,以触发所述车机系统执行整机重启;或者
在判定IVI容器重启失败的频率达到阈值频率时,调用车机系统的整机重启命令,以触发所述车机系统执行整机重启。
8.如权利要求1-7任一项所述的车机系统的控制方法,其特征在于,应用于Host系统采用Android系统时,所述容器管理服务调用车机系统的整机重启命令,以触发所述车机系统执行整机重启,包括:
所述容器管理服务将所述车机系统的系统属性赋值为reboot,通过init进程调用内核中的reboot()函数来执行所述整机重启。
9.如权利要求5或6所述的车机系统的控制方法,其特征在于,还包括:
容器管理服务执行IVI容器单独重启时,触发守护进程来守护容器监测服务执行监测任务。
10.一种车机系统的控制装置,其特征在于,应用于车机系统,所述车机系统包括内核,所述内核上运行有运行在Host系统中的仪表系统和至少一个容器,所述至少一个容器由所述仪表系统中的容器管理服务创建,所述至少一个容器包括IVI容器,所述IVI容器中运行有IVI系统;
所述车机系统的控制装置包括:
接收单元,用于接收所述IVI容器的退出信号,并根据所述退出信号的值确定所述车机系统的退出操作;
获取单元,用于在确定所述车机系统的退出操作为重启时,获取所述退出信号的重启属性参数;
确定单元,用于根据所述重启属性参数,确定所述车机系统是执行整机重启还是执行IVI容器单独重启;
整机重启单元,用于在根据所述重启属性参数确定所述车机系统是执行整机重启时,调用所述车机系统的整机重启命令,以触发所述车机系统执行整机重启;
容器单独重启单元,用于在根据所述重启属性参数确定所述车机系统是执行IVI容器单独重启时,执行所述IVI容器的重启操作;
其中,所述接收单元、所述获取单元、所述确定单元、所述整机重启单元、所述容器单独重启单元都位于所述容器管理服务中。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311856596.0A CN117539593A (zh) | 2023-12-29 | 2023-12-29 | 一种车机系统的控制方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202311856596.0A CN117539593A (zh) | 2023-12-29 | 2023-12-29 | 一种车机系统的控制方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN117539593A true CN117539593A (zh) | 2024-02-09 |
Family
ID=89790316
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202311856596.0A Pending CN117539593A (zh) | 2023-12-29 | 2023-12-29 | 一种车机系统的控制方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN117539593A (zh) |
-
2023
- 2023-12-29 CN CN202311856596.0A patent/CN117539593A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110187996A (zh) | Bmc主进程故障诊断方法、装置、设备及可读存储介质 | |
US20030204550A1 (en) | Method for multi-tasking multiple Java virtual machines in a secure environment | |
US20080141283A1 (en) | Application Controlling Apparatus And Storage Medium Which Stores Software For The Apparatus | |
JP2001101033A (ja) | オペレーティングシステム及びアプリケーションプログラムの障害監視方法 | |
US20170132063A1 (en) | Information system fault scenario information collecting method and system | |
CN110413417A (zh) | 车载系统进程的运行优化方法、装置和系统 | |
US7089413B2 (en) | Dynamic computer system reset architecture | |
CN114064132A (zh) | 一种系统宕机恢复方法、装置、设备和系统 | |
CN108897603B (zh) | 一种内存资源管理方法和装置 | |
CN109255846A (zh) | 一种车辆入场监测方法和系统 | |
CN114691407A (zh) | 一种车辆日志的获取方法、装置、电子设备及存储介质 | |
CN110908866A (zh) | 软件监控方法及相关设备 | |
CN112363828B (zh) | 内存碎片管理方法、装置、车载系统及车辆 | |
CN114184885A (zh) | 一种故障检测方法、装置及存储介质 | |
CN117539593A (zh) | 一种车机系统的控制方法及装置 | |
CN115904793B (zh) | 一种基于多核异构系统的内存转存方法、系统及芯片 | |
CN112165622A (zh) | 一种单Pod多协程视频文件转码方法及系统 | |
CN116643842A (zh) | 虚拟机安全监控处理方法、装置、设备及介质 | |
CN115934390A (zh) | 处理应用程序崩溃的方法、系统和运行应用程序的设备 | |
US5914874A (en) | Automatic application restarting system and method | |
CN109284137B (zh) | 一种基于Hypervisor的QNX操作系统启动方法及装置 | |
CN114816662A (zh) | 应用于Kubernetes的容器编排方法和系统 | |
CN108595273A (zh) | 一种控制台程序守护方法及系统 | |
CN110519558A (zh) | 视频数据的处理方法及其主板管理控制器 | |
CN109995569B (zh) | 故障联动处理方法、网元及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |