CN115657639A - 用于监控车载芯片功能的系统、方法、设备及存储介质 - Google Patents

Abstract

本披露公开了一种用于监控车载芯片功能的系统、方法、设备及存储介质。根据本披露实施例的系统，通过控制单元对诊断服务单元进行注册，并根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，可以实现根据用户需求或实际状况进行不同诊断服务单元的动态注册，有利于提高诊断测试服务的可扩展性。

Description

用于监控车载芯片功能的系统、方法、设备及存储介质

技术领域

本披露一般涉及车载芯片技术领域。更具体地，本披露涉及一种用于监控车载芯片功能的系统、方法、设备及存储介质。

背景技术

随着传统汽车向智能化、电动化、网联化的发展，汽车的车载芯片也迎来了天翻地覆的改变。传统汽车更关注于性能、动力、油耗等维度，而智能汽车更关注于汽车和人之间的交互。为了适应于智能汽车的发展需求，在智能汽车中引入了更多数量且功能更强大的芯片。

传统的汽车车载芯片监控系统是通过故障注入或者静态信号检测来对车载芯片的某些功能进行测试。然而，这些检测方案通常是预先设置的，因此存在检测方式固定、扩展性低等问题，使得车企难以根据自身需要或者实际应用状况进行定制，从而无法满足智能汽车的发展趋势。

有鉴于此，亟需相应的技术方案，来解决汽车车载芯片监控系统扩展性低的问题。

发明内容

为了至少解决如上所提到的一个或多个技术问题，本披露在多个方面中提出了一种用于监控车载芯片功能的系统、方法、设备及存储介质。

在第一方面中，本披露提供一种用于监控车载芯片功能的系统，包括：控制单元，其配置用于：对诊断服务单元进行注册；根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，以监控所述待测功能的功能状态；以及诊断服务单元，其配置用于在所述控制单元的控制下，对所述车载芯片中待测功能进行诊断测试，并返回诊断结果。

在第二方面中，本披露提供一种用于监控车载芯片功能的方法，包括：对诊断服务单元进行注册；以及根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，以监控所述待测功能的功能状态。

在第三方面中，本披露提供一种用于监控车载芯片功能的设备，包括：处理器；以及存储器，其中存储有用于监控车载芯片功能的程序指令，当所述程序指令由所述处理器执行时，使得所述设备实现根据本披露在第二方面中的任意一项所述的方法。

在第四方面中，本披露提供一种计算机可读存储介质，其中存储有用于监控车载芯片功能的程序指令，当所述程序指令由处理器执行时，使得实现根据本披露在第二方面中的任意一项所述的方法。

通过如上所提供的用于监控车载芯片功能的系统和方法，本披露的方案通过可对诊断服务单元进行注册，可以实现根据用户需求或实际状况进行不同诊断服务单元的动态注册，以在诊断服务单元注册后提供相应功能的诊断测试服务，从而无需预先设置固定的诊断检测方案，有利于提高诊断测试服务的可扩展性。在一些实施例中，通过设置策略模块来根据车辆的运行状态进行安全等级判断策略的动态配置，可以实现在车辆的不同运行状态下，设置不同的安全等级判断策略，从而可以有利于提高安全等级判断策略的适用性和灵活性。

附图说明

通过参考附图阅读下文的详细描述，本披露示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本披露的若干实施方式，并且相同或对应的标号表示相同或对应的部分，其中：

图1示出了根据本披露实施例的用于监控车载芯片功能的系统的示意性框图；

图2示出了根据本披露实施例的包括策略单元的系统的示意性框图；

图3示出了根据本披露实施例的包括配置单元的系统的示意性框图；

图4示出了根据本披露实施例的包括通信单元的系统的示意性框图；以及

图5示出了根据本披露实施例的用于监控车载芯片功能的方法流程图。

具体实施方式

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

应当理解，本披露的说明书和权利要求书中使用的术语“包括”和“包含”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。

还应当理解，在此本披露说明书中所使用的术语仅仅是出于描述特定实施例的目的，而并不意在限定本披露。如在本披露说明书和权利要求书中所使用的那样，除非上下文清楚地指明其它情况，否则单数形式的“一”、“一个”及“该”意在包括复数形式。还应当进一步理解，在本披露说明书和权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。

如在本说明书和权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。

下面结合附图来详细描述本披露的具体实施方式。

图1示出了根据本披露实施例的用于监控车载芯片功能的系统的示意性框图。如图1中所示，系统100可以包括控制单元110和诊断服务单元120，其中控制单元110可以配置用于：对诊断服务单元120进行注册；以及根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元120进行诊断测试，以监控待测功能的功能状态。诊断服务单元120可以配置用于在控制单元110的控制下，对车载芯片中待测功能进行诊断测试，并返回诊断结果。

车载芯片是用于汽车上的芯片，即车规级芯片，属于汽车元件的一种。车规级是适用于汽车电子元件的规格标准。在一些实施例中，不同类型的车载芯片负责不同的功能。例如，对于负责算力和数据处理的车载芯片，其可以具有对发动机、底盘和/或车身等汽车部件的控制功能。对于传感类芯片，其具有对雷达、气囊或胎压等进行检测的功能；还例如，对于显示类芯片，其具有显示倒车影像或者导航影像等显示功能。通过检测车载芯片的功能状态，可以监控与之关联的硬件设备或者软件功能的状态。

本文中所述的待测功能可以包括车载芯片所负责的一种或多种功能(例如上述的控制功能、检测功能和显示功能等)，或者可以包括与车载芯片相关的功能。与车载芯片相关的功能可以包括例如车载芯片的I2C接口、串行外设接口(即SPI接口)、传输控制协议/网际协议(即TCP/IP协议)、寄存器和网络通信等功能中的一种或多种。根据本披露实施例的系统可以用于对一个或多个车载芯片进行功能监控。

在另一些实施例中，对于车载芯片的不同类型的功能，或者对于不同类型的车载芯片，可以设置能够提供相应诊断功能的诊断服务单元120，以提供针对性的诊断测试服务。相应诊断功能的诊断服务单元120，是具有对相应类型的待测功能进行诊断测试服务的诊断服务单元。例如，当待测功能为车载芯片的寄存器类的功能时，可以设置能够用于检测寄存器的例如读写功能的诊断服务单元120，以对寄存器进行读写功能的测试服务。在又一些实施例中，可以动态设置一个或多个诊断服务单元120，以在每个诊断服务单元120注册到系统100中时，能够在控制单元110的控制下执行其相应的诊断测试服务。

在一些实施例中，在对诊断服务单元120进行注册中，控制单元110可以进一步配置用于：响应于接收到诊断服务单元120的诊断注册请求，可以通过调用控制单元110上预设的注册接口实现与诊断服务单元120的注册连接。在另一些实施例中，控制模块110可以具有主动诊断功能，即可以通过主动触发诊断服务，例如向具有相应诊断功能的诊断服务单元120发送诊断测试指令，以控制相应的诊断服务单元120对车载芯片的功能状态进行诊断测试。

在又一些实施例中，诊断服务单元120进行诊断测试可以为动态检测。例如，对于寄存器类的功能诊断，具有相应诊断功能的诊断服务单元120可以动态写入相关的诊断测试用例，然后将读取的结果返回给控制单元110。还例如，对于车载芯片管脚功能的诊断，具有相应诊断功能的诊断服务单元120可以对该管脚进行测试操作，以获得管脚的功能状态。比如：如果针对是GPIO管脚进行测试操作，可以测试拉高、拉低，PWM波形。如果是SPI这种通信功能的管脚测试，在不同速率下，可以测试数据的接收、发送，数据正确性校验等。在一些实施例中，诊断服务单元120返回到控制单元110的诊断结果可以包括待测功能的功能状态、功能参数等信息。相比于传统的车载芯片监控系统中故障注入或者仅检测例如温度等静态信号，动态检测有助于真实的反映待测功能的工作时的功能状态。

在另一些实施例中，每个诊断服务单元120可以包括一个或多个诊断测试用例，每个诊断测试用例可以用于对车载芯片的一个子功能的诊断测试服务。例如，假设某诊断服务单元120用于对I2C接口的功能进行诊断，其包括的一个诊断测试用例可以用于对I2C接口的传输速度进行诊断，其另一个诊断测试用例可以用于对I2C接口的连接状态进行诊断。

在又一些实施例中，每个诊断服务单元120可以具有相应的一个服务标识，每个诊断测试用例可以具有相应的一个用例标识。在一些应用场景中，可以通过调用相应服务标识对应的诊断服务单元120进行相应功能的诊断，也可以通过调用相应用例标识对应的诊断测试用例进行相应子功能的诊断。在另一些应用场景中，当有对诊断服务单元120进行升级的需求时，可以通过识别服务标识来对相应的单个或者多个诊断服务单元120进行独立升级。

在一些实施例中，控制单元110不仅具有触发主动诊断的功能，还可以具有被动触发诊断的功能，例如可以接收来自系统内的其他单元或者系统外的外部单元发出的诊断请求，以控制诊断服务单元120执行相应的诊断功能。在另一些应用场景中，当车载芯片在运行过程中发生了新的故障或者错误信息，可以根据该新的故障或者错误信息设计具有相应检测功能的诊断服务单元120，并通过对该诊断服务单元120的注册，使得根据本披露实施例的系统具有监控该新的故障或者错误信息的能力。根据这样的设置，能够解决传统芯片监控系统通过预先设定的测试而无法及时发现某些隐藏故障的问题。

以上结合图1对根据本披露实施例的系统进行了示例性的描述，可以理解的是，根据本披露实施例的系统，可以在需要添加任一诊断测试服务时，能够通过注册的方式便捷的实现对所需诊断测试服务的控制和个性化设置，有利于提高诊断测试服务的灵活性和可扩展性。还可以理解的是，上面的描述是示例性的而非限制性地，例如在一些实施例中，控制单元110还可以配置用于对诊断服务单元120的解注册，即在不需要相应诊断服务时解除与诊断服务单元120的注册连接，从而有利于进一步提高诊断测试服务的灵活性。还例如，根据本披露实施例的系统可以不限于仅包括图示中的控制单元和诊断服务单元，在另一些实施例中，根据本披露实施例的系统还可以包括例如策略单元，以提供相应的安全等级判断策略。下面将结合图2进行示例性的描述。

图2示出了根据本披露实施例的包括策略单元的系统的示意性框图。如图2中所示，该系统200可以包括控制单元110、诊断服务单元120和策略单元210，其中策略单元210可以配置用于：根据车辆的运行状态，确定该运行状态下与待测功能对应的安全等级判断策略；以及根据安全等级判断策略，对诊断结果进行判断，以确定诊断结果中待测功能的功能状态所属的安全等级。控制单元110还可以配置用于根据该安全等级，执行相应的安全操作。

在一些实施例中，运行状态可以包括静止状态或行驶状态。在另一些实施例中，行驶状态可以包括向前行驶状态或者向后行驶状态(即倒车状态)。在又一些实施例中，不同的运行状态下可以设置不同的安全等级判断策略。在每种运行状态下，可以针对每种待测功能分别设置相应的安全等级判断策略。例如，对于倒车影像功能，其在车辆的静止状态和行驶状态下，可以分别设置不同的安全等级判断策略。

策略单元210可以用于导入不同待测功能的安全等级判断策略，以对待测功能的安全等级进行判断。安全等级判断策略可以包括车载芯片的功能状态与安全等级的对应关系。安全等级判断策略可以根据需要预先设置，也可以根据车辆的实际状况实时添加。在一些实施例中，安全等级可以包括多级别的错误等级(或称故障等级)，例如低级别错误、中级别错误和高级别错误，其对应的芯片安全性逐级降低。在另一些实施例中，安全等级可以包括安全级别和错误等级，其中安全级别可以用于表示待测功能为正常状态，即芯片的安全性较高。

根据在车辆的运行状态下确定的安全等级判断策略，对该运行状态下针对待测功能测试得到的诊断结果进行判断，可以确定诊断结果中待测功能的功能状态所属的安全等级。例如，在一些应用场景中，响应于检测到车辆当前的运行状态为静止状态，且假设待测功能为倒车影像的显示功能，则可以根据策略单元210中静止状态下倒车影像功能对应的安全等级判断策略，对诊断结果进行判断。在另一些应用场景中，响应于检测到车辆当前的运行状态为行驶状态，且假设待测功能为倒车影像的显示功能，则可以根据策略单元210中行驶状态下倒车影像功能对应的安全等级判断策略，对诊断结果进行判断。

以倒车影像为例，由于对于倒车影像的功能状态而言，其在车辆的静止状态和行驶状态下的重要程度不同，其发生功能错误时的影响也不同，因此可以根据车辆的运行状态设置针对倒车影像功能的不同安全等级判断策略，例如在车辆的静止状态下，倒车影像出现某一故障时所属的安全等级可以为低级别错误；在车辆的行驶状态下，倒车影像出现相同故障时所属的安全等级可以为高级别错误。根据这样的设置，有利于实现根据车辆的实际状况动态导入不同的策略，从而能够实现策略的动态化配置。

如图2中进一步示出的，策略单元210可以与控制单元110进行信息交互。具体地，控制单元110可以将诊断服务单元120对车载芯片进行诊断测试的诊断结果发送至策略单元210，策略单元210可以根据用户需求(例如汽车厂商的需求)或者车辆当前的运行状态，导入相应的安全等级判断策略，并依照确定的安全等级判断策略对诊断结果进行判断，以获得安全等级的结果。进一步地，策略单元210可以将判断得到的安全等级结果反馈至控制单元110，以便控制单元110能够根据该安全等级的结果来执行相应的安全操作。

在一些实施例中，控制单元110可以直接将诊断结果发送至策略单元210进行判断，也可以仅当诊断结果中的功能状态存在异常时，才将诊断结果发送至策略单元210。在另一些实施例中，控制单元110执行的相应的安全操作可以包括发出预警信号、进行信息上报、发出重启芯片的控制信号和发出控制车辆停止行驶的控制信号等中的至少一种。

为了便于理解，仍以上述倒车影像功能为例，在车辆的静止状态下，策略单元210判断倒车影像出现显示故障时所属的安全等级可以为低级别错误，此时控制单元110可以发出预警信号；在车辆的行驶状态下，策略单元210判断倒车影像出现显示故障时所属的安全等级可以为高级别错误，此时控制单元110可以进行信息上报或者发出控制车辆停止行驶的控制信号。

在另一些实施例中，策略单元210还可以配置用于：过滤针对同一待测功能在第一预设时长内获得的多个相同安全等级；和/或响应于在第二预设时长内获得针对同一待测功能的多个相同级别的错误等级，提升该相同级别的错误等级的级别并进行信息上报。第一预设时长可以根据需要进行设置。第二预设时长可以根据需要进行设置。第一预设时长和第二预设时长可以根据需要设置的相同或者不同。多个相同安全等级的数量阈值可以根据需要进行设置。多个相同级别的错误等级的数量阈值也可以根据需要进行设置。

在一些应用场景中，针对同一待测功能，可能存在短时间内获得多个相同的安全等级的结果，可以对该多个相同的安全等级进行过滤，例如仅保留一个结果反馈给控制单元110，可以避免频繁的重复性信息交互，也可以有利于降低控制单元110频繁的重复性安全操作。

在另一些应用场景中，当针对同一待测功能，策略单元210在短时间内获得多个相同的错误等级(即发生了相同级别的故障)，可以对该相同的错误等级进行升级上报。例如，当策略单元210在短时间内获得针对同一待测功能的多个低级别错误，可以将该多个低级别错误升级为中级别错误并进行上报，以便控制单元110执行中级别错误对应的安全操作。根据这样的设置，能够有效提高系统对于短时间内获得多个相同的错误等级的情况的敏感性，有利于更加准确的发现车载芯片中可能存在的易被忽视的潜在问题。

以上结合图2对根据本披露实施例的包括策略单元210的系统进行了示例性的描述，可以理解的是，相比于预先固定设置好的故障等级划分策略，根据本披露实施例的策略单元210能够根据车辆的不同状态动态配置不同的判断策略，从而能够更加真实且准确的反映出当前故障可能造成的真实影响，同时策略单元的可配置性也便于用户根据需求对策略进行调整和修改。还可以理解的是，上面的描述是示例性的而非限制性的，例如根据本披露实施例的系统可以不限于仅包括图示中的控制单元、诊断服务单元和策略单元，还可以根据需要设置其他功能单元，例如配置单元和/或上层监控单元等。下面将结合图3进行示例性的描述。

图3示出了根据本披露实施例的包括配置单元的系统的示意性框图。如图3中所示，该系统300可以包括控制单元110、诊断服务单元120、策略单元210和配置单元310，其中配置单元310可以配置用于：向控制单元110导入配置信息，其中该配置信息可以包括以下中的至少一项：诊断服务单元120的主动诊断周期；诊断服务单元120进行单次诊断测试的执行时间上限；以及心跳信号周期。

在一些应用场景中，当控制单元110启动时，配置单元310可以在控制单元110的控制下，导入(或称载入)配置信息。在一些实施例中，针对不同的诊断服务单元120，可以相应配置不同的主动诊断周期。主动诊断周期可以是控制诊断服务单元120定期诊断的时间间隔。

执行时间上限即为诊断服务单元120执行诊断测试用例的最坏情况下的执行时间，超过该执行时间，说明车载芯片可能存在着异常状态。执行时间上限可以根据需要进行设置。例如，在另一些应用场景中，当控制单元110控制某一诊断服务单元120对待测功能执行诊断测试，超过执行时间上限仍未返回诊断结果，说明诊断服务单元120的诊断测试过程中可能存在问题；或者超过执行时间上限返回了诊断结果，即使返回的诊断结果正常，也难以保证诊断测试过程或者待测功能的功能状态完全正常。因此，通过设置执行时间上限能够对诊断服务单元120的诊断测试时间进行合理的限制，以便于系统300能够发现可能不易被发现的芯片问题。

上文中所述的心跳信号周期可以为定期发送用于表示系统300正常运行的信号的时间间隔。在一些实施例中，心跳信号周期可以由配置单元310导入，并由控制单元110触发产生心跳信号。在另一些实施例中，控制单元110触发产生的心跳信号可以上报至上层监控单元320，以便上层监控单元320对控制单元110及整个系统300进行监控。下面将对上层监控单元320进行具体描述。

如图3中进一步示出的，根据本披露实施例的系统300还可以包括上层监控单元320，其可以配置用于接收上报信息，并根据该上报信息中的安全等级，对车载芯片和/或车辆执行相应的控制操作。上层监控单元320可以与控制单元110直接通信或者间接通信，以接收控制单元110上报的信息，或者可以经由控制单元110接收其他单元上报的信息。

在一些实施例中，控制单元110执行的安全操作可以包括进行信息上报，即可以将包括诊断结果和策略判断结果的信息上报至上层监控单元320。上层监控单元320可以根据上报信息中策略判断得到的待测功能的安全等级，执行作用于车辆本身和/或车载芯片上的高级别的控制操作，即执行比安全操作更高级别的动作，例如当上报信息中的安全等级为高级别错误时，可以控制车载芯片重新启动、和/或控制车辆进入安全状态(例如制动以进入静止状态)等。

以上结合图3对根据本披露实施例的包括配置单元和/或上层监控单元的系统进行了示例性的说明，可以理解的是，上面的描述是示例性的而非限制性的，例如上层监控单元320可以不限于包含在本披露实施例的系统300中，也可以设置于系统300之外(例如上层监控单元320可以为车辆或者车辆芯片上已有的控制装置)，并通过控制单元110与上层监控单元320之间的通信连接实现系统300与上层监控单元320之间的通信。还可以理解的是，本披露实施例的系统可以不限于仅能够与上层监控单元320进行信息交互，也可以与其他外部单元实现信息交互。下面将结合图4进行示例性的说明。

图4示出了根据本披露实施例的包括通信单元的系统的示意性框图。如图4中所示，该系统400可以包括控制单元110、诊断服务单元120、策略单元210、配置单元310和通信单元420，其中诊断服务单元120、策略单元210和配置单元310可以根据需要进行设置，并且已经在前文中结合图1-图3进行了详细描述，此处将不再赘述。通信单元420可以连接于控制单元110与外部单元之间，并可以配置用于对控制单元110与外部单元之间的信息进行传输，其中外部单元可以包括例如图示中的应用单元410(虚线框示出)和/或上层监控单元320(虚线框示出)。

通信单元420可以支持串行外设接口SPI、进程间通信IPC、超文本传输协议HTTP等多种方式的通信功能。在一些实施例中，为了信息的安全性和方便性，可以按照预设的数据包格式对信息进行打包，并可以将打包后的信息通过通信单元420在本系统400中进行传输。在另一些实施例中，通信单元420可以包括通信接口，以与外部单元进行通信连接。外部单元可以为设置于系统400外的功能单元，例如上层监控单元320，该上层监控单元320的功能已经在前文中结合图3进行了描述，此处不再赘述。

应用单元410可以包括车载应用(或称车载APP)和/或智能终端应用(例如手机APP)等。在一些实施例中，应用单元410可以包括例如倒车影像APP、导航APP、行车记录仪APP等中的一种或多种。在另一些实施例中，控制单元110还可以配置用于：对应用单元410进行注册；以及根据应用单元410的诊断请求，控制具有相应诊断功能的诊断服务单元120进行诊断测试。

应用单元410的数量可以为一个或多个。在另一些实施例中，控制单元110还可以进一步配置用于：响应于接收到应用单元410的应用注册请求，对该应用单元410进行注册；响应于接收到已注册的应用单元410的解注册请求，解除应用单元410的注册。根据这样的设置，可以实现每个应用单元410的动态注册。在另一些实施例中，控制单元110可以经由通信单元420接收应用单元410的应用注册请求等。

在另一些实施例中，应用单元410可以主动触发诊断测试服务，即通过向控制单元110发送诊断请求，通过控制单元110控制与诊断请求中请求进行诊断的待测功能相应的诊断服务单元120进行诊断测试，并可以经由通信单元420及时接收诊断服务单元120返回到诊断结果。

在一些应用场景中，控制单元110可以接收主动诊断请求，该主动诊断请求可以来自于配置单元310导入的主动诊断周期触发，也可以是来自于应用单元410的诊断请求，或者还可以来自于上层监控单元320的诊断请求。这里来自于应用单元410和/或上层监控单元320的主动诊断请求可以通过通信单元420传递给控制单元110。控制单元110在接收到主动诊断请求时，可以对该主动诊断请求进行解析，然后启动具有相应诊断功能的诊断服务单元120执行诊断测试服务。

接着，诊断服务单元120负责执行诊断测试用例，并将测试得到的诊断结果上报给控制单元110。进一步地，控制单元110可以将诊断结果传给策略单元210，然后由策略单元210结合当前的策略(即根据车辆的当前运行状态确定的安全等级判断策略)对当前诊断结果进行判断，以获得待测功能的当前安全等级。控制单元110将会根据当前安全等级，特别是判断出错误等级时，及时执行相应级别的安全操作。根据这样的设置，本披露实施例的系统可以实现对车载芯片的待测功能的及时检测和判断，以及根据实时变化的车辆运行状态获得更符合实际情况的安全等级，以便执行更准确的安全操作。

在又一些实施例中，控制单元110还可以配置用于以下中的至少一项：接收应用单元410上报的其在运行过程中产生的功能安全问题；和/或根据应用单元410的订阅请求，订阅应用单元410感兴趣的待测功能的功能状态。

例如，在一些应用场景中，假设应用单元410为倒车影像应用，其可以上报与倒车影像功能相关的功能安全问题。在另一些应用场景中，假设应用单元410为导航应用，其可以上报与导航功能相关的功能安全问题。在又一些实施例中，控制单元110在接收到任一应用单元410上报的功能安全问题时，可以将该功能安全问题发送到策略单元210进行安全等级判断，也可以发出预警信号或者进行信息上报等安全操作，例如将该功能安全问题上报到上层控制单元320。

根据这样的设置，能够及时发现车载芯片中软件层面可能存在的问题，并能够结合该软件层面的信息上报功能实现对车载芯片的功能安全状态的更有效的监控。相比于传统汽车监控更关注于硬件故障，对于智能汽车而言，软件的重要性越来越大，因此实现软件层面的监控具有重要的意义。

上文中所述的订阅请求可以是对目标车载芯片的感兴趣的待测功能进行定期主动诊断的定制化请求。在一些实施例中，订阅请求中可以包括目标车载芯片、感兴趣的待测功能和主动诊断周期等订阅信息中的一种或多种。根据应用单元410触发的主动诊断的订阅请求，控制单元110可以定期控制诊断服务单元120进行诊断测试，并可以将诊断结果及时反馈至应用单元410，使得应用单元410能够及时获取目标车载芯片当前的功能安全状态。

以上结合图4对根据本披露实施例的应用单元和通信单元进行了示例性的描述，可以理解的是，通过系统400与应用单元410之间的信息交互，使得系统400还能够配合软件实现信息显示和信息处理等功能。进一步地，每个应用单元410可以根据用户的实际需要进行独立的设计、开发和应用层面的扩展，有利于进一步扩展系统400的检测功能以及提高系统在应用层面的可扩展性。进一步地，可以理解的是，应用单元410可以不限于设置于系统400外，还可以根据需要设置在系统400内。

相应地，本披露实施例还提供了一种用于监控车载芯片功能的方法，下面将结合图5进行描述。

图5示出了根据本披露实施例的用于监控车载芯片功能的方法流程图。如图5中所示，方法500可以包括：在步骤501中，可以对诊断服务单元进行注册；以及在步骤502中，可以根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，以监控该待测功能的功能状态。

在一些实施例中，方法500还可以包括：根据车辆的运行状态，确定运行状态下与待测功能对应的安全等级判断策略；根据安全等级判断策略，对诊断测试的诊断结果进行判断，以确定诊断结果中待测功能的功能状态所属的安全等级；以及根据安全等级，执行相应的安全操作。

在另一些实施例中，安全等级可以包括多级别的错误等级，方法500还可以包括：过滤针对同一待测功能在第一预设时长内获得的多个相同安全等级；和/或响应于在第二预设时长内获得针对同一待测功能的多个相同级别的错误等级，提升该相同级别的错误等级的级别并进行信息上报。

在又一些实施例中，安全操作可以包括发出预警信号和/或进行信息上报。

在一些实施例中，方法500还可以包括：对应用单元进行注册；以及根据应用单元的诊断请求，控制具有相应诊断功能的诊断服务单元进行诊断测试。

在另一些实施例中，方法500还可以包括以下中的至少一项：接收应用单元上报的其在运行过程中产生的功能安全问题；根据应用单元的订阅请求，订阅应用单元感兴趣的待测功能的功能状态。

在又一些实施例中，方法500还可以包括配置以下信息中的至少一项：诊断服务单元的主动诊断周期；诊断服务单元进行单次诊断测试的执行时间上限；以及心跳信号周期。

可以理解，根据本披露实施例的用于监控车载芯片功能的方法已经在前文中结合系统中各单元的功能进行了详细的描述，因此此处不再赘述。同样地，本披露一些实施例还提供了一种用于监控车载芯片功能的设备，可以包括：处理器；以及存储器，其中存储有用于监控车载芯片功能的程序指令，当程序指令由处理器执行时，使得设备实现前文中结合图5描述的任意一个实施例所述的方法，相应的特征已经在前文中结合本披露实施例的系统和方法进行了描述，此处不再重复。进一步地，本披露一些实施例还提供了实施用于监控车载芯片功能的方法的计算机程序产品，其可以包含前面描述的对应特征，此处不再重复。

需要说明的是，为了简明的目的，本披露将一些方法及其实施例表述为一系列的动作及其组合，但是本领域技术人员可以理解本披露的方案并不受所描述的动作的顺序限制。因此，依据本披露的公开或教导，本领域技术人员可以理解其中的某些步骤可以采用其他顺序来执行或者同时执行。进一步，本领域技术人员可以理解本披露所描述的实施例可以视为可选实施例，即其中所涉及的动作或模块对于本披露某个或某些方案的实现并不一定是必需的。另外，根据方案的不同，本披露对一些实施例的描述也各有侧重。鉴于此，本领域技术人员可以理解本披露某个实施例中没有详述的部分，也可以参见其他实施例的相关描述。

本领域技术人员知道，本披露的实施方式可以实现为一种系统、方法或计算机程序产品。因此，本披露可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式，本文一般称为“电路”、“模块”、“单元”或“系统”等。此外，在一些实施例中，本披露还可以实现为在一个或多个计算机可读介质中的计算机程序产品的形式，该计算机可读介质中包含计算机可读的程序代码。

可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是，但不限于，电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举示例)例如可以包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、RF等等，或者上述的任意合适的组合。可以以一种或多种程序设计语言或其组合来编写用于执行本披露操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络(包括局域网(LAN)或广域网(WAN))连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

通过结合上述多个实施例对本披露实施例的用于监控车载芯片功能的方案进行了详细的描述，可以理解的是，通过对诊断服务单元的可注册操作，能够实现具有不同诊断功能的诊断服务单元的动态配置(或称可插拔配置)，从而有利于提高用于监控车载芯片功能的系统的诊断功能的可扩展性，更符合现代智能汽车的发展趋势。

在一些实施例中，通过策略单元对安全等级判断策略的可配置性和对不同状态的适配性，使得其提供的判断策略能够更加符合车载芯片发生故障时对车辆安全的实际影响程度，进而能够控制车辆采取更加高效和准确的安全操作。进一步地，在另一些实施例中，通过对应用单元的可注册操作，能够实现不同应用单元的可插拔配置，进而有利于系统实现应用层面的功能安全检测和提高应用层面的可扩展能力。

虽然本文已经示出和描述了本披露的多个实施例，但对于本领域技术人员显而易见的是，这样的实施例只是以示例的方式来提供。本领域技术人员可以在不偏离本披露思想和精神的情况下想到许多更改、改变和替代的方式。应当理解的是在实践本披露的过程中，可以采用对本文所描述的本披露实施例的各种替代方案。所附权利要求书旨在限定本披露的保护范围，并因此覆盖这些权利要求范围内的等同或替代方案。

Claims (17)

1.一种用于监控车载芯片功能的系统，包括：

控制单元，其配置用于：

对诊断服务单元进行注册；

根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，以监控所述待测功能的功能状态；以及

诊断服务单元，其配置用于在所述控制单元的控制下，对所述车载芯片中待测功能进行诊断测试，并返回诊断结果。

2.根据权利要求1中所述的系统，还包括：

策略单元，其配置用于：

根据车辆的运行状态，确定所述运行状态下与所述待测功能对应的安全等级判断策略；

根据所述安全等级判断策略，对所述诊断结果进行判断，以确定所述诊断结果中待测功能的功能状态所属的安全等级；以及

所述控制单元还配置用于根据所述安全等级，执行相应的安全操作。

3.根据权利要求2所述的系统，其中所述安全等级包括多级别的错误等级，并且所述策略单元还配置用于：

过滤针对同一待测功能在第一预设时长内获得的多个相同安全等级；和/或

响应于在第二预设时长内获得针对同一待测功能的多个相同级别的错误等级，提升所述相同级别的错误等级的级别并进行信息上报。

4.根据权利要求2或3所述的系统，其中所述安全操作包括发出预警信号和/或进行信息上报；

所述系统还包括：

上层监控单元，其配置用于接收上报信息，根据所述上报信息中的安全等级，对所述车载芯片和/或所述车辆执行相应的控制操作。

5.根据权利要求1-4任一所述的系统，其中所述控制单元还配置用于：

对应用单元进行注册；以及

根据应用单元的诊断请求，控制具有相应诊断功能的诊断服务单元进行诊断测试。

6.根据权利要求5所述的系统，其中所述控制单元还配置用于以下中的至少一项：

接收所述应用单元上报的其在运行过程中产生的功能安全问题；

根据所述应用单元的订阅请求，订阅所述应用单元感兴趣的待测功能的功能状态。

7.根据权利要求1-6任一所述的系统，还包括：

配置单元，其配置用于向所述控制单元导入配置信息，其中所述配置信息包括以下中的至少一项：

诊断服务单元的主动诊断周期；

诊断服务单元进行单次诊断测试的执行时间上限；以及

心跳信号周期。

8.根据权利要求4-6任一所述的系统，还包括：

通信单元，其连接于所述控制单元与外部单元之间，并配置用于对所述控制单元与所述外部单元之间的信息进行传输，其中所述外部单元包括应用单元和/或上层监控单元。

9.一种用于监控车载芯片功能的方法，包括：

对诊断服务单元进行注册；以及

根据车载芯片中待测功能的类型，控制具有相应诊断功能的诊断服务单元进行诊断测试，以监控所述待测功能的功能状态。

10.根据权利要求9所述的方法，还包括：

根据车辆的运行状态，确定所述运行状态下与所述待测功能对应的安全等级判断策略；

根据所述安全等级判断策略，对所述诊断测试的诊断结果进行判断，以确定所述诊断结果中待测功能的功能状态所属的安全等级；以及

根据所述安全等级，执行相应的安全操作。

11.根据权利要求10所述的方法，所述安全等级包括多级别的错误等级，所述方法还包括：

过滤针对同一待测功能在第一预设时长内获得的多个相同安全等级；和/或

响应于在第二预设时长内获得针对同一待测功能的多个相同级别的错误等级，提升所述相同级别的错误等级的级别并进行信息上报。

12.根据权利要求10或11所述的方法，其中所述安全操作包括发出预警信号和/或进行信息上报。

13.根据权利要求9-12任一所述的方法，还包括：

对应用单元进行注册；以及

根据应用单元的诊断请求，控制具有相应诊断功能的诊断服务单元进行诊断测试。

14.根据权利要求13所述的方法，还包括以下中的至少一项：

接收所述应用单元上报的其在运行过程中产生的功能安全问题；

根据所述应用单元的订阅请求，订阅所述应用单元感兴趣的待测功能的功能状态。

15.根据权利要求9-14任一所述的方法，还包括配置以下信息中的至少一项：

诊断服务单元的主动诊断周期；

诊断服务单元进行单次诊断测试的执行时间上限；以及

心跳信号周期。

16.一种用于监控车载芯片功能的设备，包括：

处理器；以及

存储器，其中存储有用于监控车载芯片功能的程序指令，当所述程序指令由所述处理器执行时，使得所述设备实现根据权利要求9-15的任意一项所述的方法。

17.一种计算机可读存储介质，其中存储有用于监控车载芯片功能的程序指令，当所述程序指令由处理器执行时，使得实现根据权利要求9-15的任意一项所述的方法。

Images