CN118012653A - 一种故障确认与故障数据清除方法、电子设备和存储介质 - Google Patents

Abstract

本申请公开了一种故障确认与故障数据清除方法、电子设备和存储介质，该方法包括：获取诊断协议；在目标系统架构下，根据诊断协议，对故障确认与故障数据清除进行模型实现；对目标系统架构进行配置，生成目标系统架构的代码文件和接口文件。

Description

一种故障确认与故障数据清除方法、电子设备和存储介质

技术领域

本申请涉及汽车电子控制技术领域，尤其涉及一种故障确认与故障数据清除方法、电子设备和存储介质。

背景技术

目前汽车企业采用汽车开放系统架构(AUTomotive Open System Architecture，AUTOSAR)定义控制软件已经是主要趋势。另外，汽车故障诊断软件组件主要实现故障确认及故障数据清除，其主要应用于汽车4S店售后工作中的故障码确认及故障码清除，是汽车控制器不可缺少的功能。

因为传统架构控制器开发经验的影响，大部分开发商选择手写代码实现故障确认及故障数据清除功能，但在基于AUTOSAR的汽车软件开发模式下，手动代码开发这一软件组件面临着频繁的ARXML维护、代码维护，难度大，且容易出错。

发明内容

本申请提供了一种故障确认与故障数据清除方法、电子设备和存储介质。

第一方面，本申请实施例提供了一种故障确认与故障数据清除方法，所述方法包括：

获取诊断协议；

在目标系统架构下，根据所述诊断协议，对故障确认与故障数据清除进行模型实现；

对所述目标系统架构进行配置，生成所述目标系统架构的代码文件和接口文件。

在一些实施例中，所述对故障确认与故障数据清除进行模型实现，包括：

根据预设周期，周期性进行所述故障确认；以及，

当满足预设触发条件时，进行所述故障数据清除。

在一些实施例中，所述对所述目标系统架构进行配置，包括：

根据所述目标系统架构的工具箱，进行代码生成设置、所述目标系统架构的软件组件元素和属性配置和所述目标系统架构的软件组件映射。

在一些实施例中，所述对故障确认与故障数据清除进行模型实现，还包括：

当进行所述故障确认时，应用层请求底层响应，应用软件作为客户端，底层作为服务器端；

当进行所述故障数据清除时，底层请求应用层响应，所述应用软件作为所述服务器端，所述底层作为所述客户端。

在一些实施例中，所述代码生成设置包括求解器和系统目标文件设置；

其中，将所述求解器设置为定步长和离散型。

在一些实施例中，所述目标系统架构的软件组件元素和属性配置包括发送-接收接口配置、客户端-服务端接口配置和运行实体配置。

在一些实施例中，所述当满足预设触发条件时，进行所述故障数据清除，包括：

被上位机发送的诊断命令触发时，进行所述故障数据清除。

在一些实施例中，所述目标系统架构为汽车开放系统架构AUTOSAR。

第二方面，本申请实施例提供了一种电子设备，所述电子设备包括存储器和处理器，其中：

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如第一方面中任一项所述的方法。

第三方面，本申请实施例提供了一种存储介质，所述存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如第一方面中任一项所述的方法。

本申请实施例提供了一种故障确认与故障数据清除方法、电子设备和存储介质，该方法包括：获取诊断协议；在目标系统架构下，根据诊断协议，对故障确认与故障数据清除进行模型实现；对目标系统架构进行配置，生成目标系统架构的代码文件和接口文件。这样，在目标系统架构下，对故障确认与故障数据清除进行模型实现，并且对目标系统架构进行配置，这种基于模型设计的开发方式可以降低开发难度，减少维护成本，使开发过程更加高效和有效。

附图说明

图1为本申请实施例提供的一种故障确认与故障数据清除方法的流程示意图一；

图2为本申请实施例提供的一种故障确认与故障数据清除方法的流程示意图二；

图3为本申请实施例提供的一种故障确认与故障数据清除实现模型框架示意图；

图4为本申请实施例提供的一种故障确认模型框架实现示意图；

图5为本申请实施例提供的一种故障数据清除模型框架实现示意图；

图6为本申请实施例提供的一种AUTOSAR代码生成设置示意图；

图7为本申请实施例提供的一种故障确认接口AUTOSAR配置示意图；

图8为本申请实施例提供的一种故障数据清除接口AUTOSAR配置示意图；

图9为本申请实施例提供的一种AUTOSAR运行实体配置示意图；

图10为本申请实施例提供的一种电子设备的组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

近年来，随着软件定义汽车趋势的发展，汽车中软件的作用及占比急剧增加，软硬件解耦的需求越来越强。为了解决这些问题，汽车行业的领头企业携手合作，提出了一个开放性、标准化的软件架构，即汽车开放系统架构AUTOSAR。目前汽车企业采用AUTOSAR标准架构定义控制软件已经是主要趋势。

汽车故障诊断软件组件主要实现故障确认及故障数据清除(也可以称为初始化)，其主要应用于汽车4S店售后工作中的故障码确认和故障码清除，是汽车控制器不可缺少的功能。在这里，汽车故障诊断软件组件可以为车载自动诊断系统(On-Board Diagnostics，OBD)，该系统将从发动机的运行状况随时监控汽车是否尾气超标，一旦超标，会马上发出警示。OBD是通过各种与排放有关的部件信息，连接到电子控制单元(简称电控单元)，电控单元具备检测和分析与排放相关故障的功能；当出现排放故障时，电控单元记录故障信息和相关代码，并通过故障灯发出警告，告知驾驶员。

因为传统架构控制器开发经验的影响，大部分开发商选择手写代码实现这一功能，具体地，以手动编码方式的实现或者使用(电子电气)架构设计工具实现故障确认与故障数据清除，但是手动编码软件开发即耗时又容易出错，并且架构设计工具使用相对困难，以及在基于AUTOSAR的汽车软件开发模式下，手动代码开发这一软件组件面临着频繁的ARXML维护、代码维护，难度大，且容易出错。在这里，ARXML是一种用于描述汽车电子系统的XML格式，它是AUTOSAR标准的一部分，被广泛用于汽车电控单元的开发，其主要描述了汽车电子系统的各种元素，包括硬件、软件、通信、系统配置等。

基于此，本申请实施例提供了一种故障确认与故障数据清除方法，该方法包括：获取诊断协议；在目标系统架构下，根据诊断协议，对故障确认与故障数据清除进行模型实现；对目标系统架构进行配置，生成目标系统架构的代码文件和接口文件。这样，在目标系统架构下，对故障确认与故障数据清除进行模型实现，并且对目标系统架构进行配置，这种基于模型设计的开发方式可以降低开发难度，减少维护成本，使开发过程更加高效和有效。

下面将结合附图对本申请各实施例进行详细说明。

本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种故障确认与故障数据清除方法的流程示意图一。如图1所示，该方法可以包括：

S101、获取诊断协议。

需要说明的是，本申请实施例涉及汽车电子控制和OBD技术领域，具体提供了一种AUTOSAR下的基于模型的设计(Model Based Design，MBD)的故障确认及故障数据清除软件组件实现方法。其中，该方法可以应用于电子设备。在这里，电子设备可以是诸如计算机、服务器等等，本申请实施例不作具体限定。

还需要说明的是，可以通过工程师获取诊断协议，诊断协议是上游给下游的需求，因此在这里，诊断协议也可以称为相关需求。具体地，诊断协议是一个文本、规范和标准。

S102、在目标系统架构下，根据诊断协议，对故障确认与故障数据清除进行模型实现。

在这里，目标系统架构可以为AUTOSAR。

需要说明的是，故障确认与故障数据清除的模型实现过程主要包括两部分：故障确认和故障数据清除。具体地，根据相关需求，分别对故障确认与故障数据清除进行基于MBD的模型实现；其中，MBD是一种通过建模自动生成代码的开发方式，MBD允许工程师模拟和验证在开发过程早期的设计，从模型自动生成结构化代码避免了由于手动编码而导致的错误。

还需要说明的是，故障确认与故障数据清除具体是指故障码确认和故障码清除。现在的汽车里面分布了各种各样的传感器，将汽车各部位的工作信息随时传给汽车的控制单元，如果没有接收到信息或接收到错误的信息，控制单元就会将该信息存储起来，这就是故障码。另外，故障码的产生有许多原因，可能是传感器传递的信号错误，这种情况一般是传感器自身故障或线路故障；也可能是控制逻辑错误，即控制单元接收到的信息互相冲突，无法执行，这时也会存储故障码，对此均不作具体限定。

还需要说明的是，本申请实施例中的软件组件位于控制器(也称为控制单元)内部，控制器具有故障确认与故障数据清除功能。另外，可以使用汽车诊断仪进行故障码确认和故障码清除，也可以使用其他方法，对此不作具体限定。

S103、对目标系统架构进行配置，生成目标系统架构的代码文件和接口文件。

也就是说，对AUTOSAR进行配置，最后进行代码生成，将生成故障确认与故障数据清除功能的代码文件和AUTOSAR接口文件(也可以称为AUTOSAR软件组件)。

本申请实施例提供了一种故障确认与故障数据清除方法，在目标系统架构下，对故障确认与故障数据清除进行模型实现，并且对目标系统架构进行配置，这种基于模型设计的开发方式可以降低开发难度，减少维护成本，使开发过程更加高效和有效。

本申请的另一实施例中，参见图2，其示出了本申请实施例提供的一种故障确认与故障数据清除方法的流程示意图二。如图2所示，该方法可以包括：

S201、获取诊断协议。

S202、在目标系统架构下，根据诊断协议，根据预设周期，周期性进行故障确认；以及，当满足预设触发条件时，进行故障数据清除。

S203、根据目标系统架构的工具箱，进行代码生成设置、目标系统架构的软件组件元素和属性配置和目标系统架构的软件组件映射，生成目标系统架构的代码文件和接口文件。

需要说明的是，在本申请实施例中，步骤S201分别与前述实施例中的步骤S101相对应，为了简洁，在此不再赘述。另外，步骤S202和S203是分别针对前述实施例中的步骤S102和S103的一种具体实施方式，下面将对其分别进行详细描述。

对于步骤S202来说，故障确认以周期性进行，具体判断规则根据诊断协议要求进行，涵盖所有故障码。示例性地，预设周期为100毫秒(millisecond，ms)，当控制器开始运行，每隔100ms进行一次故障确认；其中，预设周期为100ms可以满足速度也可以满足时效性，但是预设周期也可以为其他数值，对此不作具体限定。

需要说明的是，进行预设次数的故障确认后停止进行故障确认。每个故障码单独进行故障确认，一个故障码需要进行一次故障确认，当达到预设次数、涵盖所有故障码时，停止确认故障码；其中，预设次数可以根据经验进行设定。

还需要说明的是，清除故障码可以有多种方法，例如故障排除、汽车诊断仪发出指令清除故障码和断开电池等等，对此不作具体限定。

在一些实施例中，当满足预设触发条件时，进行故障数据清除，包括：

被上位机发送的诊断命令触发时，进行故障数据清除。

需要说明的是，示例性地，可以是上位机发送一个诊断命令，清除所有的故障码；或者，也可以是上位机发送一个诊断命令，清除一个故障码，多个故障码分别需要上位机发送多个诊断命令，对此不作具体限定。

还需要说明的是，上位机是指与下位机或设备进行通信和控制的计算机或系统，其通常是一个独立的计算机，用于监控、配置、控制和管理下位机或设备的操作。

综上所述，故障确认是周期性的，而故障数据清除是触发类的。故障数据清除仅在被上位机发送的诊断命令触发时运行，每个故障码对应一个故障数据清除操作。预设周期设定在控制器软件中，当控制器开始运行就会间隔预设周期进行故障确认；而当接收到新的触发条件，例如上位机发送诊断命令时才会进行故障数据清除。

具体地，参见图3，其示出了本申请实施例提供的一种故障确认与故障数据清除实现模型框架示意图。如图3所示，“Runable_XXXX_100ms”代表每间隔100ms，进行一次故障确认；故障数据清除的函数原型为：

ERR＝CBInitEvt_XxxxXxxx_InitMonitorForEvent(InitMonitorReason)

进一步地，在一些实施例中，对故障确认与故障数据清除进行模型实现，还包括：

当进行故障确认时，应用层请求底层响应，应用软件作为客户端，底层作为服务器端；

当进行故障数据清除时，底层请求应用层响应，应用软件作为服务器端，底层作为客户端。

需要说明的是，应用层是计算机网络中负责为用户提供各种网络服务的协议层，它位于网络协议栈的最高层；应用层协议定义了传输数据的格式和规则、数据的交互方式以及错误处理等。与应用层相对应的是底层，底层是计算机网络协议栈中的较低层次，用于处理底层的网络传输和数据包转发。

对于故障确认功能，在进行故障码确认动作时，应用层请求底层响应，故应用软件作为客户端(Client)，通过函数调用，对底层服务器端(Server)提出故障码确认请求，所以模型层面以Function Caller实现。

另外，参见图4，其示出了本申请实施例提供的一种故障确认模型框架实现示意图。如图4所示，根据AUTOSAR标准及底层定义，故障码确认Function Caller的函数原型为：

ERR＝Event_XxxxXxxx_SetEventStatus(EventStatus)，其中XxxxXxxx为故障描述(所有故障码类似)。

需要说明的是，“ERR＝Event_XxxxXxxx_SetEventStatus(EventStatus)”是“Runable_XXXX_100ms”运行时其中的函数，并且可以根据输入参数和输出参数确定数据类型和数据构成，具体地，确定数据构成是一个量还是数组。

对于故障数据清除功能，在进行故障数据清除时，底层请求应用层响应，故应用软件作为服务器端，应答底层客户端请求，并进行相应故障数据清除动作，所以模型层面以Simulink Function实现。

另外，参见图5，其示出了本申请实施例提供的一种故障数据清除模型框架实现示意图。如图5所示，根据AUTOSAR标准及底层定义，故障数据清除Simulink Function的函数原型为：

ERR＝CBInitEvt_XxxxXxxx_InitMonitorForEvent(InitMonitorReason)(所有故障码类似)，其中XxxxXxxx为故障描述(所有故障码类似)。

需要说明的是，在进行故障数据清除时，当故障数据清除动作完成，会生成“返回值”来确认故障码是否被清除。具体地，“返回值”共有“OK”和“NOK”两种可能性，当“返回值”为“OK”时，代表执行了故障数据清除动作；当“返回值”为“NOK”时，代表没有执行故障数据清除动作。

对于步骤S203来说，目标系统架构的工具箱为AUTOSAR Blockset工具箱。也就是说，使用AUTOSAR Blockset工具箱进行AUTOSAR配置，包括代码生成设置、AUTOSAR软件组件元素和属性配置和AUTOSAR软件组件映射。

需要说明的是，AUTOSAR Blockset工具箱为开发人员提供了灵活的方法来设计和实现遵循AUTOSAR标准的汽车软件，它提供了AUTOSAR标准定义的软件组件模型、接口标准、通信机制和代码生成等功能，方便开发人员进行汽车软件建模和验证。

在一些实施例中，参见图6，其示出了本申请实施例提供的一种AUTOSAR代码生成设置示意图。如图6所示，代码生成设置包括求解器和系统目标文件设置；

其中，将求解器设置为定步长(Fixed-step)和离散型(discrete)。

另外，将系统目标文件设置为autosar.tlc。其中，系统目标文件控制编译过程的代码生成阶段，其是目标语言编译器(TLC)文件。

在一些实施例中，目标系统架构的软件组件元素和属性配置包括发送-接收接口配置、客户端-服务端接口配置和运行实体配置。

也就是说，AUTOSAR软件组件元素和属性配置包括S-R接口(发送-接收接口)配置、C-S接口(客户端-服务端接口)配置、Runnable(运行实体)配置。

在这里，运行实体是AUTOSAR应用软件组件中的基本执行单元，它们是一组操作的集合，可以在特定的事件触发时被执行，其主要用于处理不同的事件和周期性任务。

需要说明的是，根据最终模型实现，新增S-R接口和发送-接收端口(即输入端口Inport和输出端口Outport)，并对接口和端口进行相应映射。

还需要说明的是，AUTOSAR中组件间所有的通信通过组件端口(Port)进行，而组件端口由AUTOSAR接口(Interface)定义。另外，N个端口对应一个接口，接口和端口的相应映射是指一个端口可以对应到一个接口。

进一步地，参见图7，其示出了本申请实施例提供的一种故障确认接口AUTOSAR配置示意图。如图7所示，进行AUTOSAR中的C-S接口配置，新增Client接口：DiagnosticMonitor，且根据AUTOSAR标准及底层定义，其函数原型为：

ERR＝SetEventStatus(EventStatus)，即函数名称为SetEventStatus，参数EventStatus，方向为IN；参数ERR，方向为Error。为确保和底层引用的是同一个函数，统一路径为/AUTOSAR_Dem/PortInterfaces。根据模型，新增相应的服务端口(Server Port)：Event_XxxxXxxx_SetEventStatus，每个故障码确认实现Function Caller对应一个客户端口(Client Port)。最后，对端口和接口进行相应映射，所有故障码确认端口映射到同一个接口上。

需要说明的是，函数的方向可以为输入IN，也可以为输出OUT；“Error”代表没有方向，该函数是个返回值。

还需要说明的是，上述“路径”具体可以为存储路径，即将函数存储在该路径，也从该路径调用函数。

更进一步地，参见图8，其示出了本申请实施例提供的一种故障数据清除接口AUTOSAR配置示意图。如图8所示，进行AUTOSAR中的C-S接口配置，新增server接口：CBInitEvt_XxxxXxxx_InitMonitorForEvent，以此类推，对每个故障数据(即故障码)清除实现Simulink Function新建一个C-S接口，且根据AUTOSAR标准及底层定义，其函数原型均为：

ERR＝InitMonitorForEvent(InitMonitorReason)，即函数名称为InitMonitorForEvent，参数InitMonitorReason，方向为IN；参数ERR，方向为Error。为确保和底层引用的是同一个函数，统一路径为/AUTOSAR_Dem/PortInterfaces。根据模型，新增相应的服务端口：CBInitEvt_XxxxXxxx_InitMonitorForEvent，每个故障数据清除实现Simulink Function对应一个服务端口。最后，对端口和接口进行相应映射。

另外，参见图9，其示出了本申请实施例提供的一种AUTOSAR运行实体配置示意图。如图9所示，进行运行实体配置，新增Runnable：CBInitEvt_XxxxXxxx_InitMonitorForEvent、Runable_XXXX_100ms，并分别为其添加如下事件类型：OperationInvokedEvent(函数调用事件)和TimingEvent(周期性事件)。

需要说明的是，每个故障数据清除实现Simulink Function对应一个运行实体。

在一些实施例中，目标系统架构为汽车开放系统架构AUTOSAR。

汽车开放系统架构AUTOSAR是一家致力于制定汽车电子软件标准的联盟，其定义了一套支持分布式的、功能驱动的汽车电子软件开发方法和电子控制单元上的软件架构标准化方案，以便应用于不同的汽车和平台，提高软件复用、降低开发成本。

AUTOSAR是全球汽车行业主要原始设备制造商、供应商及工具和软件服务商的开发合作联盟。AUTOSAR旨在简化汽车电子软件的联合开发，降低成本和加速产品面市时间，提高软件质量，并提供安全系统设计所需的机制。AUTOSAR重新定义了嵌入式汽车软件的编写方式，从而实现了对软件组件的重复使用、交换、升级和整合，过程十分简便

本申请实施例提供了一种故障确认与故障数据清除方法，具体是一种AUTOSAR下基于MBD的故障确认及故障数据清除软件组件实现方法，包括故障码确认和故障数据清除。首先根据诊断协议，对故障码确认和故障数据清零(即清除)功能进行基于MBD的模型实现；然后使用AUTOSAR Blockset工具箱进行AUTOSAR配置，包括代码生成设置、AUTOSAR软件组件元素和属性配置及AUTOSAR软件组件映射，以生成AUTOSAR接口文件和相关代码(即代码文件)。

本申请的再一实施例中，参见图10，其示出了本申请实施例提供的一种电子设备的组成结构示意图。如图10所示，电子设备30可以包括：通信接口301、存储器302和处理器303；各个组件通过总线系统304耦合在一起。可理解，总线系统304用于实现这些组件之间的连接通信。总线系统304除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图10中将各种总线都标为总线系统304。其中，通信接口301，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器302，用于存储能够在处理器303上运行的计算机程序；

处理器303，用于在运行所述计算机程序时，执行：

获取诊断协议；

在目标系统架构下，根据诊断协议，对故障确认与故障数据清除进行模型实现；

对目标系统架构进行配置，生成目标系统架构的代码文件和接口文件。

可以理解，本申请实施例中的存储器302可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本文描述的系统和方法的存储器302旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器303可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器303中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器303可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器302，处理器303读取存储器302中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器303还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法。

本申请实施例还提供了一种存储介质，该存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现前述实施例中任一项所述故障确认与故障数据清除方法的步骤。

在本申请实施例中，对于电子设备30而言，可以降低开发难度，减少维护成本，使开发过程更加高效和有效。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种故障确认与故障数据清除方法，其特征在于，所述方法包括：

获取诊断协议；

在目标系统架构下，根据所述诊断协议，对故障确认与故障数据清除进行模型实现；

对所述目标系统架构进行配置，生成所述目标系统架构的代码文件和接口文件。

2.根据权利要求1所述的方法，其特征在于，所述对故障确认与故障数据清除进行模型实现，包括：

根据预设周期，周期性进行所述故障确认；以及，

当满足预设触发条件时，进行所述故障数据清除。

3.根据权利要求1所述的方法，其特征在于，所述对所述目标系统架构进行配置，包括：

根据所述目标系统架构的工具箱，进行代码生成设置、所述目标系统架构的软件组件元素和属性配置和所述目标系统架构的软件组件映射。

4.根据权利要求2所述的方法，其特征在于，所述对故障确认与故障数据清除进行模型实现，还包括：

当进行所述故障确认时，应用层请求底层响应，应用软件作为客户端，底层作为服务器端；

当进行所述故障数据清除时，底层请求应用层响应，所述应用软件作为所述服务器端，所述底层作为所述客户端。

5.根据权利要求3所述的方法，其特征在于，所述代码生成设置包括求解器和系统目标文件设置；

其中，将所述求解器设置为定步长和离散型。

6.根据权利要求3所述的方法，其特征在于，所述目标系统架构的软件组件元素和属性配置包括发送-接收接口配置、客户端-服务端接口配置和运行实体配置。

7.根据权利要求2所述的方法，其特征在于，所述当满足预设触发条件时，进行所述故障数据清除，包括：

被上位机发送的诊断命令触发时，进行所述故障数据清除。

8.根据权利要求1至7中任一项所述的方法，其特征在于，所述目标系统架构为汽车开放系统架构AUTOSAR。

9.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，其中：

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至7中任一项所述的方法。

10.一种存储介质，其特征在于，所述存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至7中任一项所述的方法。