掌桥专利:专业的专利平台
掌桥专利
首页

车载日志记录方法、装置和控制器

文献发布时间:2023-06-19 18:37:28


车载日志记录方法、装置和控制器

技术领域

本申请涉及汽车领域,尤其涉及一种车载日志记录方法、装置和控制器。

背景技术

随着车辆中操作系统的发展推进,越来越多的应用程序被部署到了车辆的操作系统中。这些应用程序之间通常存在复杂的依赖关系。在车辆使用过程中,车辆会记录日志文件。工作人员可以使用该日志文件,分析车辆的运行情况。

现有技术中,车辆的操作系统中通常使用logcat、kernel message等工具实现日志文件的生成和读写。通过该两个工具,工作人员可以使用命令查看日志文件。但是使用该两个工具生成的日志文件无法导出,工作人员必须连接设备才能查看该设备的日志文件。

在实际应用中,被装载到车辆内部的设备,无法因为只是导出日志就进行拆卸再装载的行为。因此,工作人员通常只能查看设备的日志文件,而无法针对导出的日志文件进行综合分析,存在车辆的运行情况的分析效率低的问题。

发明内容

本申请提供一种车载日志记录方法、装置和控制器,用以解决无法针对导出的日志文件进行综合分析,存在车辆的运行情况的分析效率低的问题。

第一方面,本申请提供一种车载日志记录方法,包括:

监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个所述目标缓冲区中读取新增日志数据;

根据本地配置文件,将所述新增日志数据写入本地配置文件中预设的目标路径下的当前日志文件中。

可选地,所述本地配置文件中包括预设文件大小、预设命名规则、目标路径,所述根据本地配置文件,将所述新增日志数据写入目标路径下的当前日志文件中,具体包括:

根据所述新增日志数据的数据大小、所述当前日志文件的大小和预设文件大小,判断所述当前日志文件中是否存在足够空间写入所述新增日志数据;

若是,则在所述当前日志文件中写入所述新增日志数据;

若否,则根据所述预设命名规则在所述目标路径中创建新日志文件,并将所述新增日志数据写入所述新日志文件。

可选地,所述本地配置文件中包括预设目录大小,所述判断所述当前日志文件中是否存在足够空间写入所述新增日志数据之前,所述方法,还包括:

根据所述预设目录大小和所述目标路径中各个日志文件的大小总和,判断所述目标路径中各个日志文件的大小总和是否超过所述预设目录大小;

若是,则删除创建时间最久的日志文件。

可选地,所述监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个所述目标缓冲区中读取新增日志数据,具体包括:

通过socket通信监听线程,监听车载系统中用于存储日志数据的各个目标缓冲区;

通过socket通信协议实现各个所述目标缓冲区中新增日志数据的读取和传输。

可选地,所述监听车载系统中用于存储日志数据的各个目标缓冲区之前,所述方法,还包括:

在所述车辆上电后,运行日志管理进程,并通过所述日志管理进程读取所述本地配置文件;

根据所述本地配置文件中的运行参数,判断所述日志管理进程是否第一次运行;

若是,则在所述本地配置文件中设置目标路径。

可选地,所述方法,还包括:

获取异常捕获和调试信息生成机制库中的函数接口,并通过所述函数接口开启异常捕获机制;

当所述车辆的车载系统发生崩溃时,通过所述异常捕获机制获取所述车辆的异常信息,并将所述异常信息生成压缩包后存放到所述目标路径下。

第二方面,本申请提供一种车载日志记录装置,包括:

读取模块,用于监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个所述目标缓冲区中读取新增日志数据;

写入模块,用于根据本地配置文件,将所述新增日志数据写入本地配置文件中预设的目标路径下的当前日志文件中。

可选地,所述本地配置文件中包括预设文件大小、预设命名规则、目标路径,所述写入模块,具体用于:

根据所述新增日志数据的数据大小、所述当前日志文件的大小和预设文件大小,判断所述当前日志文件中是否存在足够空间写入所述新增日志数据;

若是,则在所述当前日志文件中写入所述新增日志数据;

若否,则根据所述预设命名规则在所述目标路径中创建新日志文件,并将所述新增日志数据写入所述新日志文件。

可选地,所述本地配置文件中包括预设目录大小,所述判断所述当前日志文件中是否存在足够空间写入所述新增日志数据之前,所述写入模块,还用于:

根据所述预设目录大小和所述目标路径中各个日志文件的大小总和,判断所述目标路径中各个日志文件的大小总和是否超过所述预设目录大小;

若是,则删除创建时间最久的日志文件。

可选地,所述读取模块,具体用于:

通过socket通信监听线程,监听车载系统中用于存储日志数据的各个目标缓冲区;

通过socket通信协议实现各个所述目标缓冲区中新增日志数据的读取和传输。

可选地,所述监听车载系统中用于存储日志数据的各个目标缓冲区之前,所述读取模块,还用于:

在所述车辆上电后,运行日志管理进程,并通过所述日志管理进程读取所述本地配置文件;

根据所述本地配置文件中的运行参数,判断所述日志管理进程是否第一次运行;

若是,则在所述本地配置文件中设置目标路径。

可选地,所述写入模块,还用于:

获取异常捕获和调试信息生成机制库中的函数接口,并通过所述函数接口开启异常捕获机制;

当所述车辆的车载系统发生崩溃时,通过所述异常捕获机制获取所述车辆的异常信息,并将所述异常信息生成压缩包后存放到所述目标路径下。

第三方面,本申请提供一种控制器,包括:存储器和处理器;

所述存储器用于存储计算机程序;所述处理器用于根据所述存储器存储的计算机程序执行第一方面及第一方面任一种可能的设计中的车载日志记录方法。

第四方面,本申请提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,当控制器的至少一个处理器执行该计算机程序时,控制器执行第一方面及第一方面任一种可能的设计中的车载日志记录方法。

第五方面,本申请提供一种计算机程序产品,所述计算机程序产品包括计算机程序,当控制器的至少一个处理器执行该计算机程序时,控制器执行第一方面及第一方面任一种可能的设计中的车载日志记录方法。

本申请提供的车载日志记录方法、装置和控制器,通过通过监听线程,监听该车辆的车载系统中用于存储日志数据的各个目标缓冲区;当有日志数据被写入到这些目标缓冲区时,通过这些监听线程,实时从各个目标缓冲区中读取新增日志数据;从本地配置文件中读取目标路径以及当前日志文件的文件名;将该新增日志数据写入该目标路径下的当前日志文件中的手段,实现提高这些日志数据的利用率和分析效率的效果。

附图说明

为了更清楚地说明本申请或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的一种车载日志记录的系统结构示意图;

图2为本申请一实施例提供的一种车载日志记录方法的流程图;

图3为本申请一实施例提供的一种车载日志记录方法的流程图;

图4为本申请一实施例提供的一种车载日志记录方法的流程图;

图5为本申请一实施例提供的一种车载日志记录装置的结构示意图;

图6为本申请一实施例提供的一种控制器的硬件结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚,下面将结合本申请中的附图,对本申请中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换。例如,在不脱离本文范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。再者,如同在本文中所使用的,单数形式“一”、“一个”和“该”旨在也包括复数形式,除非上下文中有相反的指示。此处使用的术语“或”和“和/或”被解释为包括性的,或意味着任一个或任何组合。因此,“A、B或C”或者“A、B和/或C”意味着“以下任一个:A;B;C;A和B;A和C;B和C;A、B和C”。仅当元件、功能、步骤或操作的组合在某些方式下内在地互相排斥时,才会出现该定义的例外。

随着车辆中操作系统的发展推进,越来越多的应用程序被部署到了车辆的操作系统中。为了提高车辆中应用程序的部署效率,现有技术中通常使用容器化的部署方法实现这些应用程序的部署。这些应用程序之间通常存在复杂的依赖关系。在车辆使用过程中,车辆会记录日志数据。工作人员可以使用该日志数据,分析车辆的运行情况。与复杂的依赖关系对应,这些应用程序通常包括庞大的日志。

现有技术中,车辆的操作系统中通常使用logcat、kernel message等工具实现日志数据的生成和读写。通过该两个工具,工作人员可以使用命令查看日志数据。但是使用该两个工具生成的日志数据无法导出,工作人员必须连接设备才能查看该设备的日志数据。并且,logcat的日志存在繁杂度高,难以分析的问题。由于日志数据无法导出,因此,使用这些工具进行日志数据的记录,容易出现积累过大的日志数据数量,导致系统存储不够的问题。并且由于这些日志数据繁杂度高,通常出现日志数量巨大,确没有体现关键信息的问题。同时,由于该两个工具无法记录modemlog、netlog这样的模块日志,因此,当4G、GPS等模块产生问题时,很可能出现没有日志可以分析的情况。

在实际应用中,智能座舱等被装载到车辆内部的设备,无法因为只是需要导出日志就进行拆卸再装载的行为。因此,工作人员通常只能查看设备的日志数据,而无法针对导出的日志数据进行综合分析,存在车辆的运行情况的分析效率低的问题。此外,考虑到汽车系统安全因素,如果日志系统仅包括logcat日志和kernel message这两种,在出现问题或故障时,会很大程度上降低技术人员定位问题的效率,导致问题无法及时解决,影响客户使用和体验。而在通用的linux系统当中,虽然存在着syslog和proc等其他查看系统各种信息的方式,但这种方式往往需要技术人员进行手动操作查看。并且,在大多数情况下,如果设备发生宕机,在设备宕机重启后虽然可以恢复正常,但是宕机时的日志信息就会丢失,因此,技术人员将无法获取到设备发生问题时刻的信息,而往往此类信息是定位宕机问题的至关重要的信息。

为了解决上述技术问题,本申请实施例提供的车载日志记录方法的发明构思在于,本申请提出了一种新的集成式混合日志系统管理方法,该方法结合了logcat、kernelmessage、proc等多种日志技术,并通过系统自检测来进行日志数据管理。本申请还可以通过故障触发等方式采集系统关键信息。本申请充分利用了locat、kernel、proc的信息丰富、自检测导出、故障触发功能的便利性,提高问题定位的效率和便捷性。本申请具体将应用层的日志以及内核和系统的日志保存到配置指定的目录中,方便开发人员导出日志。此外,本申请还使用了logcat的底层实现原理,根据logcat的分类信息将proc、sys、kernelmessage的关键性系统信息保存后提供给技术人员,以便技术人员可以根据这些信息实现问题的定位。该日志记录的方式可以更好地使得日志系统发挥日志类型的全面性,并且,该分类方式避免了logcat的日志庞大杂乱的问题。在正常运行情况下,日志系统可以将日志保存为不同类型的文件,一旦有系统及错误或者应用程序中出现了内存错误,控制器就会触发AEE机制。该异常捕获和调试信息生成机制库(Android Exception Engine,AEE)是一种在发生内存错误或内核错误时,无法依靠手动保存日志信息时,能自动保存系统日志信息的机制。控制器可以将proc、sys、kernel message等关键性的信息保存下来并压缩。这些日志最终都会存储到设备上的外部sd卡中,提高日志的导出效率。本申请中,控制器可以充分发挥logcat功能调试的优势,又避免了其繁杂无保存分类的缺点。同时,AEE触发机制实现了proc、sys、kernel message等关键性系统级信息的保存,充分发挥日志系统的优势,方便工作人员快速定位问题。

以下,对本申请实施例的示例性应用场景进行介绍。

图1示出了本申请一实施例提供的一种车载日志记录的系统结构示意图。如图1所示,该车辆中可以包括显示界面。该显示界面可以为该车辆的车机的显示界面。或者,该显示界面还可以为与该车辆存在通信连接的其他终端设备的显示界面。该车辆中可以包括配置文件。车辆的控制器可以获取该配置文件。该车辆中还可以设置有log进程和AEE机制。在该车辆的其他进程运行时,该log进程可以通过petlog和logdr socket实现日志数据的记录。当该车辆的AEE机制被触发时,该车辆中proc、sys可以保存关键信息。该车辆中可以包括硬件。该硬件中可以包括贮存器。该车辆中还可以包括SD卡。proc、sys、petlog和logdrsocket生成的日志可以存储在该车辆的硬件的贮存器中。该车辆中还可以包括监听进程。当该监听进程监听到日志数据被写入贮存器的时,该车辆的控制器可以将该日志数据进一步写入SD卡中。用户可以在SD卡被存满之后,通过更换SD卡的方式继续存储日志数据。本申请所使用的方法适应于所有基于Android系统领域实现的日志管理系统解决方案。目前该场景在车机系统集成化领域比较常见。

本申请中,以控制器为执行主体,执行如下实施例的车载日志记录方法。具体地,该执行主体可以为控制器的硬件装置,或者为控制器中实现下述实施例的软件应用,或者为安装有实现下述实施例的软件应用的计算机可读存储介质,或者为实现下述实施例的软件应用的代码。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合,对于相同或相似的概念或过程可能在某些实施例不再赘述。

图2示出了本申请一实施例提供的一种车载日志记录方法的流程图。在图1所示实施例的基础上,如图2所示,车辆的车载系统可以运行于控制器中,以控制器为执行主体,本实施例的方法可以包括如下步骤:

S101、监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个目标缓冲区中读取新增日志数据。

本实施例中,控制器可以利用logcat的底层实现原理,将日志数据存储在多个目标缓冲区。控制器中还可以设置有监听线程。控制器可以通过监听线程,监听该车辆的车载系统中用于存储日志数据的各个目标缓冲区。当有日志数据被写入到这些目标缓冲区时,控制器可以通过这些监听线程,实时从各个目标缓冲区中读取新增日志数据。

一种示例中,控制器可以通过socket通信监听线程,监听车载系统中用于存储日志数据的各个目标缓冲区。其后,控制器可以通过socket通信协议实现各个目标缓冲区中新增日志数据的读取和传输。

S102、根据本地配置文件,将新增日志数据写入本地配置文件中预设的目标路径下的当前日志文件中。

本实施例中,控制器可以从车辆的存储设备中获取本地配置文件。控制器可以从本地配置文件中读取目标路径以及当前日志文件的文件名。控制器可以将该新增日志数据写入该目标路径下的当前日志文件中。

一种示例中,本地配置文件中具体可以包括预设文件大小、预设命名规则和目标路径。

一种示例中,控制器可以根据新增日志数据,确定该新增日志数据的数据大小。控制器可以根据该当前日志文件的文件名,确定当前日志文件的大小。该大小即为该当前日志文件中已经写入的日志数据的数据量。控制器还可以根据本地配置文件,确定预设文件大小。该预设文件大小为技术人员预先设置的每一个日志文件的大小。控制器可以根据预设文件大小和当前日志文件的大小,确定该当前日志文件中的剩余空间。控制器可以根据该剩余空间和新增日志数据的数据大小,判断当前日志文件的剩余空间是否存在足够写入新增日志数据。若是,则控制器可以直接在当前日志文件中写入新增日志数据。若否,则控制器需要从本地配置文件中获取预设命名规则。控制器可以根据该本地配置文件的名称规则,生成新日志文件的文件名。控制器可以根据该新日志文件的文件名,在目标路径中创建该新日志文件。控制器可以将新增日志数据写入该新日志文件中。

一种示例中,本地配置文件中还可以包括预设目录大小。该预设目录大小用于指示目标路径对应的文件夹中可以存储的总数据量。控制器可以在判断当前日志文件中是否存在足够空间写入新增日志数据之前,先获取该目标路径中各个日志文件的大小总和。控制器可以比较该目标路径中各个日志文件的大小总和与该预设目录大小,如果该目标路径中各个日志文件的大小总和小于或者等于预设目录大小,则控制器可以直接将该新增日志数据写入该目标路径中。否则,如果该目标路径中各个日志文件的大小总和超过预设目录大小,则控制器可以在删除创建时间最久的日志文件后,将该新增日志数据写入该目标路径下的日志文件中。

一种示例中,该目标路径可以为SD卡中的路径。

本申请提供的车载日志记录方法,控制器可以通过监听线程,监听该车辆的车载系统中用于存储日志数据的各个目标缓冲区。当有日志数据被写入到这些目标缓冲区时,控制器可以通过这些监听线程,实时从各个目标缓冲区中读取新增日志数据。控制器可以从本地配置文件中读取目标路径以及当前日志文件的文件名。控制器可以将该新增日志数据写入该目标路径下的当前日志文件中。本申请中,通过对目标缓冲区的实时监控,将各个目标缓冲区中的新增日志数据实时写入SD卡中的目标路径,使技术人员可以通过获取该SD卡,实现这些日志数据的导出,提高这些日志数据的利用率和分析效率。

图3示出了本申请一实施例提供的一种车载日志记录方法的流程图。在图2实施例的基础上,如图3所示,车辆的车载系统可以运行于控制器中,以控制器为执行主体,本实施例的方法可以包括如下步骤:

S201、在车辆上电后,运行日志管理进程,并通过日志管理进程读取本地配置文件。

本实施例中,在车辆的控制器上电后,该车辆的控制器可以运行车载系统。该车载系统中可以包括日志管理进程。即,当该车载系统开始运行后,该车辆的日志管理进程开始运行。控制器可以通过日志管理进程读取存储在该控制器上的本地配置文件。

S202、根据本地配置文件中的运行参数,判断日志管理进程是否第一次运行。

本实施例中,该本地配置文件中可以包括运行参数。该运行参数可以用于指示该日志管理进程的运行次数。例如,当该日志管理进程为第一次运行时,该运行参数可以为1,否则,该运行参数可以为0。即,该本地配置文件中该运行参数的出厂值可以为1。当该日志管理进程运行后,控制器可以通过该日志管理进程将该本地配置文件中的运行参数设置为0。控制器可以通过该运行参数,判断该日志管理进程是否是第一次运行。

S203、若是,则在本地配置文件中设置目标路径。

本实施例中,若控制器确定该日志管理进程是第一次运行,则控制器可以从该车载系统中获取目标路径。可选地,该目标路径可以为该车辆中SD卡的路径。控制器可以将该目标路径写入到该本地配置文件中,以使日志管理进程的监听线程在后续执行时,将新增日志数据写入该目标路径下。由于不同的车辆中,该SD卡的路径并不一定相同,因此,控制器可恶意在第一次启动日志管理进程时,执行该目标路径的写入,以避免路径不存在或者路径不在SD卡的情况发生。并且,该控制器还可以在设置该目标路径的同时,完成该车辆中SD卡是否存在的判断。如果该车辆中未插入SD卡,则控制器可以在显示设备中提醒技术人员或者用户插入SD卡。

S204、监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个目标缓冲区中读取新增日志数据。

S205、根据本地配置文件,将新增日志数据写入目标路径下的日志文件中。

其中,步骤S204和S205与图2实施例中的步骤S101和S102实现方式类似,本实施例此处不再赘述。

S206、获取异常捕获和调试信息生成机制库中的函数接口,并通过函数接口开启异常捕获机制。

本实施例中,控制器还可以从异常捕获和调试信息生成机制库(AndroidException Engine,AEE)中获取函数接口。控制器可以通过调用这些函数接口,实现该车辆的车载系统的异常捕获机制的开启。即,当控制器通过这些函数接口实现异常捕获和调试信息生成机制库中函数的调用时,该控制器在该车载系统中开启该车载系统的异常捕获。

S207、当车辆的车载系统发生崩溃时,通过异常捕获机制获取车辆的异常信息,并将异常信息生成压缩包后存放到目标路径下。

本实施例中,当车辆的车载系统发生崩溃时,该已经被开启的异常捕获机制将捕获该车辆的异常信息。该异常捕获机制还可以将该异常信息生成压缩包。该异常捕获机制还可以将该压缩包存储到目标路径下。控制器可以在该车辆的车载系统重启后,从该目标路径下获取该异常信息的压缩包,并实现该异常的解析。或者,技术人员还可以直接取出该SD卡,并通过读卡的方式,在其他终端设备中从该SD卡中读取该异常信息的压缩包,实现该异常的解析。

本申请提供的车载日志记录方法,在车辆上电后,控制器运行日志管理进程,并通过日志管理进程读取本地配置文件。控制器可以根据本地配置文件中的运行参数,判断日志管理进程是否第一次运行。若是,则控制器可以在本地配置文件中设置目标路径。控制器可以监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个目标缓冲区中读取新增日志数据。控制器可以根据本地配置文件,将新增日志数据写入目标路径下的日志文件中。控制器可以获取异常捕获和调试信息生成机制库中的函数接口,并通过函数接口开启异常捕获机制。当车辆的车载系统发生崩溃时,控制器可以通过异常捕获机制获取车辆的异常信息,并将异常信息生成压缩包后存放到目标路径下。本申请中,通过判断该日志管理进程是否第一次运行,控制器可以实现目标路径的设置,以确保该目标路径为该车辆的SD卡对应的路径,以保证该车载日志的导出效率。此外,控制器还可以通过调用AEE的函数接口,实现异常捕获机制的开启,从而实现将车载系统崩溃时的异常信息保存在目标路径下的效果。

在上述各是实施例的基础上,如图4所示,辆的车载系统可以运行于控制器中,以控制器为执行主体,本实施例的一种实现方式具体可以包括如下步骤:

S301、车辆的车机上电启动。该车辆的车机即为上述实施例中的执行主体控制器。该车机启动后,该车辆的车载系统被启动。车载系统启动后,该车辆的日志管理进程运行。该日志管理进程用于导出、保存、清理维护日志。

S302、控制器可以通过该日志管理进程检查当前是否为第一次启动。如果是第一次启动,则控制器更新日志数据的目标路径。该目标路径为外部sd卡中的路径。该目标路径为最终的日志保存路径。该目标路径可以通过设置代码中的一个全局变量实现设置。或者,该目标路径还可以通过设置本地配置文件中的一个全局变量实现设置。完成该目标路径的设置后,该控制器可以继续运行。否则,如果不是第一次启动,则控制器直接执行下述步骤。

S303、控制器可以通过该日志管理进程获取AEE库中的函数接口。控制器可以通过该日志管理进程实现该AEE库中函数接口的调用,实现AEE机制开关的开启。当该AEE机制开启后,该控制器可以在出现内存错误等的问题时触发AEE机制保存日志的功能。

S304、控制器可以通过该日志管理进程读取车机的安卓系统的本地配置文件。控制器可以获取该配置文件中设置的日志使能开关、各个类型的日志文件的预设文件大小、目标路径下的预设目录大小、日志过滤等级、启动模式等信息。控制器可以在读取这些信息后,将这些信息保存到代码中的多个全局变量或者一个全局结构体中。在后续代码执行过程中,控制器可以通过这些全局变量或者这个全局结构体,实现这些信息获取和使用。具体可以包括,控制器根据这些信息确定创建的日志文件的目录、确定日志文件的名称、设置日志文件的大小限制。

S305、控制器可以通过该日志管理进程创建服务端socket,以及服务端监听线程wait_client。控制器可以通过该服务端监听线程wait_client来监听服务端socket。控制器还可以通过socket通信保存服务端实时的日志数据到本地,防止系统重启后无法查看之前的日志信息。控制器还可以通过该日志管理进程在后续创建多个的线程完成不同的日志保存任务。例如,控制器可以创建线程1用于收集数据、线程2用不保存管理数据。控制器可以通过该多个线程的写作来完成了应用层日志数据的保存。

S306、控制器可以根据全局结构体中保存的信息,配置本地日志临时保存文件名,以及日志文件保存路径。控制器还可以根据全局结构体中保存的信息创建file tree。该file tree中通过日志文件名和保存路径实现该树结构的构建。技术人员可以通过该树结构可以更加直观的查看日志分类。

S307、控制器可以通过该日志管理进程创建日志读取线程。该日志读取线程采用了logcat的底层实现原理logdr socket。

S308、控制器可以通过该日志读取线程,监听logdr socket实现logcat中各个缓冲区的监控。

S309、控制器可以通过该日志读取线程中的监听logdr socket(即服务端socket)读取logcat中各个缓冲区中保存的不同类型的日志数据。该日志数据可以包括内核日志、应用层日志等。

S310、控制器可以通过该日志读取线程,将读取到的logcat类型的日志数据传输给服务端socket。

S311、控制器可以通过该日志管理进程创建日志写入线程。

S312、控制器可以通过该日志写入线程,判断当前单个日志文件大小是否超过配置文件中设置的预设文件大小。若超出,则执行S313。否则,直接执行S314。

S313、若超出,则控制器可以通过该日志写入线程创建新的日志文件。该新的日志文件的文件名中可以包含日志类型及时间。

S314、控制器可以通过该日志写入线程将通过socket获取到的日志数据写入在SD卡目录创建的日志文件中。在该日志数据的写入过程中,该日志写入线程可以通过IO将该日志数据写入该日志文件中。

D317、在将日志数据写入日志文件之前,控制器的日志写入线程会对目标路径下的日志文件进行管理。该日志写入线程可以获取该目标路径下的全部日志的总文件大小。该日志线程还可以使用该总文件大小与预设目录大小进行比较。如果该总文件大小超过预设目录大小,则执行S318。否则,直接执行S314。

S318、如果总文件大小超出配置文件中设置的预设目录大小的限制,则会删除部分最旧的预设数量个日志文件。该预设数量可以由技术人员在该配置文件中设置。或者,该预设数量还可以由技术人员直接写入到执行代码中。当完成该日志文件的删除后,控制器将继续执行S314。

S315、当车载系统发生内核崩溃、应用程序内存错误等系统级严重错误时,控制器可以在系统崩溃重启前触发AEE机制。

S316、该AEE机制可以将proc、sys、kernel message等日志工具的定位的问题的关键性信息在打包压缩之后存储到目标路径下。

图5示出了本申请一实施例提供的一种车载日志记录装置的结构示意图,如图5所示,本实施例的车载日志记录装置10用于实现上述任一方法实施例中对应于控制器的操作,本实施例的车载日志记录装置10包括:

读取模块11,用于监听车载系统中用于存储日志数据的各个目标缓冲区,并实时从各个目标缓冲区中读取新增日志数据;

写入模块12,用于根据本地配置文件,将新增日志数据写入本地配置文件中预设的目标路径下的当前日志文件中。

可选地,本地配置文件中包括预设文件大小、预设命名规则、目标路径,写入模块12,具体用于:

根据新增日志数据的数据大小、当前日志文件的大小和预设文件大小,判断当前日志文件中是否存在足够空间写入新增日志数据;

若是,则在当前日志文件中写入新增日志数据;

若否,则根据预设命名规则在目标路径中创建新日志文件,并将新增日志数据写入新日志文件。

可选地,本地配置文件中包括预设目录大小,判断当前日志文件中是否存在足够空间写入新增日志数据之前,写入模块12,还用于:

根据预设目录大小和目标路径中各个日志文件的大小总和,判断目标路径中各个日志文件的大小总和是否超过预设目录大小;

若是,则删除创建时间最久的日志文件。

可选地,读取模块11,具体用于:

通过socket通信监听线程,监听车载系统中用于存储日志数据的各个目标缓冲区;

通过socket通信协议实现各个目标缓冲区中新增日志数据的读取和传输。

可选地,监听车载系统中用于存储日志数据的各个目标缓冲区之前,读取模块11,还用于:

在车辆上电后,运行日志管理进程,并通过日志管理进程读取本地配置文件;

根据本地配置文件中的运行参数,判断日志管理进程是否第一次运行;

若是,则在本地配置文件中设置目标路径。

可选地,写入模块12,还用于:

获取异常捕获和调试信息生成机制库中的函数接口,并通过函数接口开启异常捕获机制;

当车辆的车载系统发生崩溃时,通过异常捕获机制获取车辆的异常信息,并将异常信息生成压缩包后存放到目标路径下。

本申请实施例提供的车载日志记录装置10,可执行上述方法实施例,其具体实现原理和技术效果,可参见上述方法实施例,本实施例此处不再赘述。

图6示出了本申请实施例提供的一种控制器的硬件结构示意图。如图6所示,该控制器20,用于实现上述任一方法实施例中对应于控制器的操作,本实施例的控制器20可以包括:存储器21和处理器22。

存储器21,用于存储计算机程序。该存储器21可能包含高速随机存取存储器(Random Access Memory,RAM),也可能还包括非易失性存储(Non-Volatile Memory,NVM),例如至少一个磁盘存储器,还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。

处理器22,用于执行存储器存储的计算机程序,以实现上述实施例中的车载日志记录方法。具体可以参见前述方法实施例中的相关描述。该处理器22可以是中央处理单元(Central Processing Unit,CPU),还可以是其他通用处理器、数字信号处理器(DigitalSignal Processor,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成,或者用处理器中的硬件及软件模块组合执行完成。

可选地,存储器21既可以是独立的,也可以跟处理器22集成在一起。

当存储器21是独立于处理器22之外的器件时,控制器20还可以包括总线23。该总线23用于连接存储器21和处理器22。该总线23可以是工业标准体系结构(IndustryStandard Architecture,ISA)总线、外部设备互连(Peripheral ComponentInterconnect,PCI)总线或扩展工业标准体系结构(Extended Industry StandardArchitecture,EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示,本申请附图中的总线并不限定仅有一根总线或一种类型的总线。

本实施例提供的控制器可用于执行上述的车载日志记录方法,其实现方式和技术效果类似,本实施例此处不再赘述。

本申请还提供一种计算机可读存储介质,计算机可读存储介质中存储有计算机程序,计算机程序被处理器执行时用于实现上述的各种实施方式提供的方法。

其中,计算机可读存储介质可以是计算机存储介质,也可以是通信介质。通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。计算机存储介质可以是通用或专用计算机能够存取的任何可用介质。例如,计算机可读存储介质耦合至处理器,从而使处理器能够从该计算机可读存储介质读取信息,且可向该计算机可读存储介质写入信息。当然,计算机可读存储介质也可以是处理器的组成部分。处理器和计算机可读存储介质可以位于专用集成电路(Application Specific Integrated Circuits,ASIC)中。另外,该ASIC可以位于用户设备中。当然,处理器和计算机可读存储介质也可以作为分立组件存在于通信设备中。

具体地,该计算机可读存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现,如静态随机存取存储器(Static Random-Access Memory,SRAM),电可擦除可编程只读存储器(Electrically-Erasable Programmable Read-Only Memory,EEPROM),可擦除可编程只读存储器(Erasable Programmable Read Only Memory,EPROM),可编程只读存储器(Programmable read-only memory,PROM),只读存储器(Read-OnlyMemory,ROM),磁存储器,快闪存储器,磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。

本申请还提供一种计算机程序产品,该计算机程序产品包括计算机程序,该计算机程序存储在计算机可读存储介质中。设备的至少一个处理器可以从计算机可读存储介质中读取该计算机程序,至少一个处理器执行该计算机程序使得设备实施上述的各种实施方式提供的方法。

本申请实施例还提供一种芯片,该芯片包括存储器和处理器,存储器用于存储计算机程序,处理器用于从存储器中调用并运行计算机程序,使得安装有芯片的设备执行如上各种可能的实施方式中的方法。

在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅是示意性的,例如,模块的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个模块可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或模块的间接耦合或通信连接,可以是电性,机械或其它的形式。

其中,各个模块可以是物理上分开的,例如安装于一个的设备的不同位置,或者安装于不同的设备上,或者分布到多个网络单元上,或者分布到多个处理器上。各个模块也可以是集成在一起的,例如,安装于同一个设备中,或者,集成在一套代码中。各个模块可以以硬件的形式存在,或者也可以以软件的形式存在,或者也可以采用软件加硬件的形式实现。本申请可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

当各个模块以软件功能模块的形式实现的集成的模块,可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)或处理器执行本申请各个实施例方法的部分步骤。

应该理解的是,虽然上述实施例中的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

最后应说明的是:以上各实施例仅用以说明本申请的技术方案,而非对其限制。尽管参照前述各实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分或者全部技术特征进行等同替换。而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

技术分类

06120115632291