WO2021244535A1 - 车辆软件故障检测方法、装置、设备及存储介质 - Google Patents

车辆软件故障检测方法、装置、设备及存储介质 Download PDF

Info

Publication number
WO2021244535A1
WO2021244535A1 PCT/CN2021/097709 CN2021097709W WO2021244535A1 WO 2021244535 A1 WO2021244535 A1 WO 2021244535A1 CN 2021097709 W CN2021097709 W CN 2021097709W WO 2021244535 A1 WO2021244535 A1 WO 2021244535A1
Authority
WO
WIPO (PCT)
Prior art keywords
software function
detected
software
detection
result
Prior art date
Application number
PCT/CN2021/097709
Other languages
English (en)
French (fr)
Inventor
孙忠刚
张晓谦
姜珊
于鑫
许凯程
Original Assignee
中国第一汽车股份有限公司
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by 中国第一汽车股份有限公司 filed Critical 中国第一汽车股份有限公司
Publication of WO2021244535A1 publication Critical patent/WO2021244535A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0736—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function
    • G06F11/0739—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in functional embedded systems, i.e. in a data processing system designed as a combination of hardware and software dedicated to performing a certain function in a data processing system embedded in automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3013—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is an embedded system, i.e. a combination of hardware and software dedicated to perform a certain function in mobile devices, printers, automotive or aircraft systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/20—Administration of product repair or maintenance

Definitions

  • the embodiments of the present application relate to vehicle technology, for example, to a method, device, device, and storage medium for detecting vehicle software failures.
  • a vehicle is a complex mechanical system, which is composed of thousands of parts and components with complex functions.
  • the software logic is used to detect whether the multiple software functions of the vehicle are normal.
  • the legality check of the parameters and the operating cycle of the monitoring software function are often used to determine whether the software malfunctions during the operation.
  • the detection function of this detection method is limited. If there is no error in the software logic itself during the detection process, but the data that the software logic depends on has been tampered with or the data output by a component that it depends on is wrong, if the software logic is still used to detect the vehicle The software function is prone to misdetection of the software function, which affects the location of the fault point and subsequent maintenance.
  • the embodiments of the present application provide a vehicle software failure detection method, device, equipment, and storage medium, so as to accurately detect the failure of the vehicle software function, thereby facilitating accurate location of the failure point and subsequent maintenance.
  • the embodiment of the present application provides a vehicle software fault detection method, including: acquiring a detection identifier of a software function to be detected, determining the detection logic corresponding to the software function to be detected according to the detection identifier; The software function to be tested is tested, and the current test result is output; the current test result is compared with the predetermined theoretical result of the software function to be tested, and the actual test result of the software function to be tested is determined according to the comparison result.
  • An embodiment of the present application also provides a vehicle software failure detection device, including: a detection logic determination module configured to obtain a detection identifier of the software function to be detected, and determine the detection logic corresponding to the software function to be detected according to the detection identifier;
  • the software function detection module is configured to detect the software function to be detected based on the detection logic and output the current detection result;
  • the detection result determination module is configured to compare the current detection result with the predetermined software function to be detected The theoretical results of the functions are compared, and the actual test results of the software functions to be tested are determined according to the comparison results.
  • the embodiment of the present application also provides a vehicle software failure detection device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor.
  • the processor implements any of the foregoing when the computer program is executed.
  • the embodiment of the present application also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, implement the vehicle software failure detection method described in any one of the above.
  • FIG. 1 is a schematic flowchart of a method for detecting vehicle software failures according to Embodiment 1 of this application;
  • FIG. 2 is a schematic diagram of the detection logic of the communication function of the engine control system provided in the first embodiment of the application;
  • FIG. 3 is a schematic structural diagram of a vehicle software fault detection device provided in the second embodiment of the application.
  • FIG. 4 is a schematic structural diagram of a vehicle software fault detection device provided in Embodiment 3 of the application.
  • FIG. 1 is a schematic flow chart of a method for detecting a vehicle software fault according to Embodiment 1 of the application.
  • This embodiment can be applied to determine the detection result of the software function to be detected based on the current detection result and theoretical result of the software function to be detected.
  • the method can be executed by a vehicle software failure detection device, which can be implemented by software and/or hardware, and is generally integrated in a terminal or a vehicle software failure detection device. As shown in Fig. 1, the method may include the following steps.
  • S110 Obtain a detection flag of the software function to be detected, and determine the detection logic corresponding to the software function to be detected according to the detection flag.
  • the vehicle software has at least one software function, and each software function that requires fault detection in the vehicle software may be a software function to be detected.
  • the number of the software function to be detected is at least one, and the at least one software function to be detected includes at least one of a communication function, a brake function, a throttle speed control function, and a coasting function.
  • a detection flag can be set for each software function of the vehicle, and the corresponding detection logic can be written for each software function, and the detection flag and detection logic can be stored corresponding to each software function.
  • the detection identifier is determined in advance according to the hardware device corresponding to the software function to be detected.
  • the detection logic may include operation cycle judgment logic or operating condition information judgment logic for running each software function.
  • S120 Detect the software function to be detected based on the detection logic, and output the current detection result.
  • the running start time or operating condition information of the software function to be tested can be read, and the running start time or operating condition information can be used as the current test result.
  • the running cycle required for the running of the software function to be tested can be determined according to the running cycle judgment logic, or the working condition information during the running process of the software function to be tested can be determined according to the working condition information judgment logic. Get the current test result.
  • the software function to be detected is the communication function of the engine control system.
  • the time required to activate the communication function of the engine control system and multiple time points of the communication function are determined
  • the sampling value of the communication status, the time required for startup and the sampling value of the communication status at multiple time points are used as the current detection result of the communication function of the engine control system, so as to determine the function of the function according to the current detection result of the communication function of the engine control system Test results.
  • the method for determining the detection result may include the following steps: if it is determined that the current detection result is within the threshold range of the theoretical result, it is determined that the software function to be detected does not have a functional failure; if the current detection result is determined If it is not within the threshold range of the theoretical result, it is determined that the software function to be detected has a functional failure.
  • the current test results of multiple dimensions can be obtained.
  • the current test results of each dimension need to be compared with the corresponding theoretical results, and the actual test results of the software functions to be tested are determined based on the comparison results of all dimensions. .
  • FIG. 2 is a schematic diagram of the detection logic of the communication function of the engine control system.
  • the system start-up time can be obtained first.
  • the theoretical test result of the system start-up time is determined in advance as 10s. If the system start-up time is greater than 10s, the communication function is obtained five times in a row. Sampling value (such as voltage value), compare the acquired sampling value of the communication function with the expected value, if the sampling value of the communication function is not equal to the expected value, it is determined that the communication function of the engine control system is malfunctioning, then the communication function of the engine control system is malfunctioning state.
  • Sampling value such as voltage value
  • the current test result is determined according to the operating cycle or working condition information required for the operation of the software function to be tested, and the current test result can be determined by comparing the current test result with the theoretical result.
  • the actual test result of the software function Compared with the related technology, the software function to be tested does not need to be tested according to the software logic of the software, so there is no need to test the software function according to the data on which the software logic depends or the output data of the corresponding hardware, thereby improving the software to be tested The detection accuracy of the function.
  • the fault point of the software function to be tested can also be located according to the functional failure and the fault information of the fault point is determined, and the restart instruction of the software function to be tested is generated based on the failure information, and the software to be tested is restarted according to the restart instruction Features.
  • the software function to be tested is the communication function of the engine control system
  • the communication function fails, locate the fault point of the communication function and the fault information of the fault point, and generate a restart command, and restart the related link of the communication function according to the restart command To realize the repair of communication function failures.
  • the software function to be tested after restarting can be tested based on the detection logic, and the retest result is obtained. If the retest result is within the threshold range of the theoretical result, it is determined that the software function to be tested after restarting does not appear Functional failure.
  • the current test result can be determined again according to the test logic of the software function to be tested, the current test result determined again is compared with the theoretical result, and the result is determined again according to the comparison result The actual test results until the restart of the software function to be tested are not obstructed. If the function of the software to be tested still fails after restarting, a prompt message can be issued so that the vehicle technician can repair the vehicle according to the prompt message.
  • the at least two software functions to be detected are detected in a parallel detection manner.
  • the detection logic corresponding to the software functions to be tested which can improve the entire vehicle The detection efficiency of the software function.
  • the technical solution provided in this embodiment obtains the detection identification of the software function to be detected, determines the detection logic corresponding to the software function to be detected based on the detection identification, detects the software function to be detected based on the detection logic, outputs the current detection result, and then calculates the current detection result. It is compared with the predetermined theoretical result of the software function to be tested, and the actual test result of the software function to be tested is determined according to the comparison result.
  • This method solves the problem that the software function to be detected is prone to false detection due to the need to detect the software function to be detected according to the data on which the software logic depends or the output data of the corresponding hardware in the related technology, and achieves the effect of improving the detection accuracy rate of the software function to be detected At the same time, the method does not require hardware participation, is easy to implement, and facilitates vehicle maintenance.
  • FIG. 3 is a schematic structural diagram of a vehicle software fault detection device provided in the second embodiment of the application.
  • the device includes: a detection logic determination module 31, a software function detection module 32, and a detection result determination module 33.
  • the detection logic determination module 31 is configured to obtain the detection identification of the software function to be detected, and determine the detection logic corresponding to the software function to be detected according to the detection identification; the software function detection module 32 is configured to perform the The software function to be tested is tested, and the current test result is output; the test result determination module 33 is configured to compare the current test result with the predetermined theoretical result of the software function to be tested, and determine the test result according to the comparison result. The actual test result of the software function.
  • the detection result determination module 33 is configured to determine the actual detection result of the software function to be tested according to the comparison result in the following manner: if it is determined that the current detection result is within the theoretical result Within the threshold range, it is determined that the software function to be detected does not have a functional failure; if it is determined that the current detection result is not within the threshold range of the theoretical result, it is determined that the software function to be detected has a functional failure.
  • the software function detection module 32 is configured to run the software function to be detected based on the detection logic, read the operating start time or working condition information of the software function to be detected, and The operation start time or the operating condition information is used as the current detection result.
  • the device further includes: a restart module; wherein the restart module is configured to locate the fault point of the software function to be detected and determine the fault information of the fault point according to the function fault; A restart instruction of the software function to be checked is generated according to the fault information, and the software function to be checked is restarted according to the restart instruction.
  • the device further includes: a re-detection module; wherein the re-detection module is configured to detect the software function to be checked after restarting based on the detection logic, and obtain the re-detection result, if The detection result is within the threshold range of the theoretical result, and it is determined that the software function to be detected after restarting has no functional failure.
  • a re-detection module configured to detect the software function to be checked after restarting based on the detection logic, and obtain the re-detection result, if The detection result is within the threshold range of the theoretical result, and it is determined that the software function to be detected after restarting has no functional failure.
  • the number of the software function to be detected is at least one, and the at least one software function to be detected includes at least one of a communication function, a brake function, a throttle speed control function, and a coasting function,
  • the detection identifier of each software function to be detected is determined in advance according to the hardware device corresponding to each software function to be detected.
  • the device further includes: a parallel detection module; wherein the parallel detection module is configured to perform a parallel detection method if the number of functions of the software to be detected is at least two. At least two software functions to be tested are tested.
  • the technical solution provided in this embodiment obtains the detection identification of the software function to be detected, determines the detection logic corresponding to the software function to be detected based on the detection identification, detects the software function to be detected based on the detection logic, outputs the current detection result, and then calculates the current detection result. It is compared with the predetermined theoretical result of the software function to be tested, and the actual test result of the software function to be tested is determined according to the comparison result.
  • This method solves the problem that the software function to be detected is prone to false detection due to the need to detect the software function to be detected according to the data on which the software logic depends or the output data of the corresponding hardware in the related technology, and achieves the effect of improving the detection accuracy rate of the software function to be detected At the same time, the method does not require hardware participation, is easy to implement, and facilitates vehicle maintenance.
  • FIG. 4 is a schematic structural diagram of a vehicle software fault detection device provided in Embodiment 3 of the application.
  • FIG. 4 shows a block diagram of an exemplary vehicle software failure detection device 12 suitable for implementing the embodiments of the present application.
  • the vehicle software fault detection device 12 shown in FIG. 4 is only an example, and should not bring any limitation to the function and scope of use of the embodiments of the present application.
  • the vehicle software fault detection device 12 is represented in the form of a general-purpose computing device.
  • the components of the vehicle software fault detection device 12 may include, but are not limited to: one or more processors or processing units 16, a system memory 28, and a bus 18 connecting different system components (including the system memory 28 and the processing unit 16).
  • the bus 18 represents one or more of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any bus structure among multiple bus structures.
  • these architectures include but are not limited to Industrial Standard Architecture (ISA) bus, Micro-Channel Architecture (MCA) bus, enhanced ISA bus, Video Electronics Standards Association (Video Electronics) Standards Association (VESA) local bus and Peripheral Component Interconnect (PCI) bus.
  • the vehicle software failure detection device 12 includes a variety of computer system readable media. These media may be any available media that can be accessed by the vehicle software failure detection device 12, including volatile and non-volatile media, removable and non-removable media.
  • the system memory 28 may include a computer system readable medium in the form of a volatile memory, such as a random access memory (RAM) 30 and/or a cache memory 32.
  • the vehicle software failure detection device 12 may include other removable/non-removable, volatile/nonvolatile computer system storage media.
  • the storage system 34 may be configured to read and write a non-removable, non-volatile magnetic medium (not shown in FIG. 4, usually referred to as a "hard drive").
  • the storage system 34 may provide a disk drive configured to read and write a removable non-volatile disk (such as a "floppy disk"), and a removable non-volatile disk (such as a portable compact disk).
  • each drive can be connected to the bus 18 through one or more data media interfaces.
  • the memory 28 may include at least one program product.
  • the program product has a set of (for example, the detection logic determination module 31 of the vehicle software fault detection device, the software function detection module 32, and the detection result determination module 33) program modules, which are configured to Perform functions of multiple embodiments of this application.
  • a program/utility tool 44 having a set of program modules 46 can be stored in the memory 28, such a program
  • the module 46 includes, but is not limited to, an operating system, one or more application programs, other program modules, and program data. Each or a certain combination of these examples may include the implementation of a network environment.
  • the program module 46 usually executes the functions and/or methods in the embodiments described in this application.
  • the vehicle software failure detection device 12 may also communicate with one or more external devices 14 (such as keyboards, pointing devices, displays 24, etc.), and may also communicate with one or more devices that enable users to interact with the vehicle software failure detection device 12 Communicate, and/or communicate with any device (such as a network card, modem, etc.) that enables the vehicle software fault detection device 12 to communicate with one or more other computing devices. This communication can be performed through an input/output (Input/Output, I/O) interface 22.
  • the vehicle software failure detection device 12 may also communicate with one or more networks (for example, a local area network (LAN), a wide area network (WAN), and/or a public network, such as the Internet) through the network adapter 20.
  • LAN local area network
  • WAN wide area network
  • public network such as the Internet
  • the network adapter 20 communicates with other modules of the vehicle software failure detection device 12 through the bus 18.
  • vehicle software failure detection device 12 includes but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, disks Arrays (Redundant Arrays of Independent Disks, RAID) systems, tape drives, data backup storage systems, etc.
  • the processing unit 16 executes a variety of functional applications and data processing by running programs stored in the system memory 28, for example, to implement a vehicle software failure detection method provided by an embodiment of the present application, the method includes: obtaining software functions to be detected According to the detection flag, the detection logic corresponding to the software function to be detected is determined according to the detection flag; the software function to be detected is detected based on the detection logic, and the current detection result is output; the current detection result is compared with the predetermined all The theoretical results of the software functions to be tested are compared, and the actual test results of the software functions to be tested are determined according to the comparison results.
  • the processing unit 16 executes a variety of functional applications and data processing by running a program stored in the system memory 28, for example, to implement a vehicle software failure detection method provided in an embodiment of the present application.
  • processor can also implement the technical solution of a vehicle software fault detection method provided by any embodiment of the present application.
  • the fourth embodiment of the present application also provides a computer-readable storage medium on which a computer program is stored.
  • the method for detecting a vehicle software fault as provided in the embodiment of the present application is implemented, and the method includes : Obtain the detection flag of the software function to be detected, and determine the detection logic corresponding to the software function to be detected based on the detection flag; detect the software function to be detected based on the detection logic, and output the current detection result; The current detection result is compared with the predetermined theoretical result of the software function to be detected, and the actual detection result of the software function to be detected is determined according to the comparison result.
  • the computer-readable storage medium provided by the embodiment of the present application and the computer program stored thereon is not limited to the above method operations, and can also execute the vehicle software failure detection method provided by any embodiment of the present application. Related operations.
  • the computer storage medium of the embodiment of the present application may adopt any combination of one or more computer-readable media.
  • the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium.
  • the computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or a combination of any of the above.
  • Examples of computer-readable storage media include: electrical connections with one or more wires, portable computer disks, hard disks, RAM, read-only memory (Read-Only Memory, ROM), erasable Erasable Programmable Read-Only-Memory (EPROM) or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the above.
  • the computer-readable storage medium can be any tangible medium that contains or stores a program, and the program can be used by or in combination with an instruction execution system, system, or device.
  • the computer-readable signal medium may be included in a current detection result, a theoretical result, an actual detection result, etc., or a data signal propagated as a part of a carrier wave, which carries a computer-readable program code. This kind of transmitted data signal can take the form of current detection result, theoretical result, actual detection result, etc.
  • the computer-readable signal medium may also be any computer-readable medium other than the computer-readable storage medium.
  • the computer-readable medium may send, propagate, or transmit the program for use by or in combination with the instruction execution system, system, or device .
  • the program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.
  • suitable medium including but not limited to wireless, wire, optical cable, radio frequency (RF), etc., or any suitable combination of the foregoing.
  • the computer program code used to perform the operations of this application can be written in one or more programming languages or a combination thereof.
  • the programming languages include object-oriented programming languages—such as Java, Smalltalk, C++, and also conventional procedural programming languages. Programming language-such as "C" language or similar programming language.
  • the program code can be executed entirely on the user's computer, partly on the user's computer, executed as an independent software package, partly on the user's computer and partly executed on a remote computer, or entirely executed on the remote computer or server.
  • the remote computer may be connected to the user's computer through any kind of network including LAN or WAN, or may be connected to an external computer (for example, using an Internet service provider to connect through the Internet).
  • the multiple modules included are only divided according to the functional logic, but are not limited to the above division, as long as the corresponding function can be realized; in addition, The names of multiple functional units are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Tourism & Hospitality (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Mathematical Physics (AREA)
  • Debugging And Monitoring (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)
  • Stored Programmes (AREA)

Abstract

一种车辆软件故障检测方法、装置、设备及存储介质，方法包括：获取待检测软件功能的检测标识，根据检测标识确定待检测软件功能对应的检测逻辑（S110），基于检测逻辑对待检测软件功能进行检测，输出当前检测结果（S120），将当前检测结果与预先确定的待检测软件功能的理论结果进行比较，根据比较结果确定待检测软件功能的实际检测结果（S130）。

Description

车辆软件故障检测方法、装置、设备及存储介质
本申请要求在2020年06月05日提交中国专利局、申请号为202010506892.8的中国专利申请的优先权，该申请的全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及车辆技术，例如涉及一种车辆软件故障检测方法、装置、设备及存储介质。
背景技术
车辆是一个复杂的机械系统，它由数千种零部件构成，功能复杂。在车辆开发和使用阶段，通过使用软件逻辑检测车辆的多个软件功能是否正常。
相关技术中，对车辆的软件功能进行故障检测时，多采用对参数的合法性检查以及监控软件功能的运行周期等，以判断软件在运行过程中是否出现故障。但是这种检测方式检测功能有限，如果在检测过程中，软件逻辑本身没有出现错误，然而软件逻辑所依赖的数据被篡改或者依赖的一个零部件输出的数据错误，如果仍采用该软件逻辑检测车辆的软件功能，容易出现软件功能误检测的情况，进而影响故障点的定位以及后续维修。
发明内容
本申请实施例提供了一种车辆软件故障检测方法、装置、设备及存储介质，以实现准确检测车辆的软件功能的故障，进而有利于准确定位故障点以及后续维修。
本申请实施例提供了一种车辆软件故障检测方法，包括：获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
本申请实施例还提供了一种车辆软件故障检测装置，包括：检测逻辑确定模块，设置为获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；软件功能检测模块，设置为基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；检测结果确定模块，设置为将所述当前检测结果与预先确定的所述待检测软件的功能的理论结果进行 比较，根据比较结果确定所述待检测软件功能的实际检测结果。
本申请实施例还提供了一种车辆软件故障检测设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述任一项所述的车辆软件故障检测方法。
本申请实施例还提供了一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时实现上述任一项所述的车辆软件故障检测方法。
附图说明
图1为本申请实施例一提供的一种车辆软件故障检测方法的流程示意图；
图2为本申请实施例一提供的发动机控制系统的通信功能的检测逻辑示意图；
图3为本申请实施例二提供的一种车辆软件故障检测装置的结构示意图；
图4为本申请实施例三提供的一种车辆软件故障检测设备的结构示意图。
具体实施方式
下面结合附图和实施例对本申请进行说明。可以理解的是，此处所描述的实施例仅仅用于解释本申请，而非对本申请的限定。为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。
实施例一
图1为本申请实施例一提供的一种车辆软件故障检测方法的流程示意图，本实施例可适用根据待检测软件功能的当前检测结果和理论结果，确定待检测软件功能的检测结果的情况。该方法可以由车辆软件故障检测装置来执行，该装置可由软件和/或硬件实现，并一般集成在终端或车辆软件故障检测设备中。参见图1所示，该方法可以包括如下步骤。
S110，获取待检测软件功能的检测标识，根据检测标识确定待检测软件功能对应的检测逻辑。
可选的，车辆软件具有至少一个软件功能，车辆软件中每个需要故障检测的软件功能可以是一个待检测软件功能。
所述待检测软件功能的数量为至少一个，所述至少一个待检测软件功能包括通讯功能、刹车功能、油门控速功能以及滑行功能中的至少一种。在对待检测软件功能进行检测之前，可以为车辆的每个软件功能均设置检测标识，并对 每个软件功能编写对应的检测逻辑，将检测标识和检测逻辑分别与每个软件功能对应存储。可选地，所述检测标识预先根据所述待检测软件功能对应的硬件设备确定。所述检测逻辑可以包括运行每个软件功能的运行周期判断逻辑或工况信息判断逻辑。
S120，基于检测逻辑对待检测软件功能进行检测，输出当前检测结果。
可选地，可以通过基于检测逻辑运行待检测软件功能，读取待检测软件功能的运行启动时间或工况信息，将运行启动时间或工况信息作为当前检测结果。
通过检测逻辑对待检测软件功能进行检测时，可以根据运行周期判断逻辑确定待检测软件功能运行所需要的运行周期，或根据工况信息判断逻辑确定待检测软件功能运行过程中的工况信息，以得到当前检测结果。示例性地，待检测软件功能是发动机控制系统的通信功能，将检测逻辑在发动机控制系统的通信功能上运行时，确定发动机控制系统的通信功能启动所需的时间和通信功能的多个时间点通讯状态的采样值，将启动所需的时间和多个时间点通讯状态的采样值作为发动机控制系统的通信功能的当前检测结果，以根据发动机控制系统的通信功能的当前检测结果确定该功能的检测结果。
S130，将当前检测结果与预先确定的待检测软件功能的理论结果进行比较，根据比较结果确定待检测软件功能的实际检测结果。
可选地，检测结果的确定方式可以包括如下步骤：如果确定所述当前检测结果处于所述理论结果的阈值范围内，确定所述待检测软件功能未出现功能故障；如果确定所述当前检测结果未处于所述理论结果的阈值范围内，确定所述待检测软件功能出现功能故障。
对待检测软件功能进行检测时，可以获取到多个维度的当前检测结果，需要将每个维度的当前检测结果与对应的理论结果比较，根据所有维度的比较结果确定待检测软件功能的实际检测结果。
示例性地，如图2所示为发动机控制系统的通信功能的检测逻辑示意图。结合图2，对发动机控制系统的通信功能进行功能检测时，可以先获取系统启动时间，预先确定系统启动时间的理论检测结果为10s，如果系统启动时间大于10s，则连续5次获取通讯功能的采样值(例如电压值)，将获取的通讯功能的采样值与期望值进行比较，如果通讯功能的采样值与期望值不相等，确定发动机控制系统的通信功能障碍，则发动机控制系统的通信功能为故障状态。
通过上述描述可知，本实施例对待检测软件功能进行测试的过程中，根据待检测软件功能运行所需要的运行周期或工况信息确定当前检测结果，将当前检测结果与理论结果比较可以确定待检测软件功能的实际检测结果。相比于相 关技术对待检测软件功能进行检测过程中，不需要根据该软件的软件逻辑，因而不需要根据软件逻辑所依赖的数据或对应的硬件的输出数据检测该软件功能，进而提高待检测软件功能的检测准确率。
如果确定待检测软件功能出现功能故障，还可以根据功能故障定位待检测软件功能的故障点以及确定故障点的故障信息，根据故障信息生成待检测软件功能的重启指令，根据重启指令重启待检测软件功能。例如，如果待检测软件功能是发动机控制系统的通信功能，如果该通信功能故障，定位该通信功能的故障点和该故障点的故障信息，以及生成重启指令，根据重启指令重启通信功能的相关链路，实现通信功能故障修复。
在重启待检测软件功能之后，可以基于检测逻辑对重启后的待检测软件功能进行检测，得到再次检测结果，如果再次检测结果处于理论结果的阈值范围内，确定重启后的待检测软件功能未出现功能故障。可选地，对重启后的待检测软件功能进行检测时，可以重新根据该待检测软件功能的检测逻辑再次确定当前检测结果，将再次确定的当前检测结果与理论结果比较，根据比较结果再次确定实际检测结果，直至重启后的待检测软件功能未发生障碍。如果重启后的待检测软件功能依然发生障碍，可以发出提示信息，以使车辆技术人员根据提示信息维修车辆。
可选地，如果所述待检测软件功能的数量为至少两个，按照并行检测的方式对所述至少两个待检测软件功能进行检测。例如，对发动机控制系统的通信功能、刹车功能以及油门控速功能进行检测时，可以通过根据多个待检测软件功能对应的检测逻辑对多个待检测软件功能并行检测，这样，可以提高整个车辆的软件功能的检测效率。
本实施例提供的技术方案，通过获取待检测软件功能的检测标识，根据检测标识确定待检测软件功能对应的检测逻辑，基于检测逻辑对待检测软件功能进行检测，输出当前检测结果，将当前检测结果与预先确定的待检测软件功能的理论结果进行比较，根据比较结果确定待检测软件功能的实际检测结果。该方法解决了相关技术中因需要根据软件逻辑所依赖的数据或对应的硬件的输出数据检测待检测软件功能，而导致容易出现误检测的问题，实现提高待检测软件功能的检测准确率的效果，同时，该方法不需要硬件参与易于实现，并便于对车辆维修。
实施例二
图3为本申请实施例二提供的一种车辆软件故障检测装置的结构示意图。参见图3所示，该装置包括：检测逻辑确定模块31、软件功能检测模块32以及检测结果确定模块33。
检测逻辑确定模块31，设置为获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；软件功能检测模块32，设置为基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；检测结果确定模块33，设置为将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
在上述多个技术方案的基础上，检测结果确定模块33是设置为，通过如下方式根据比较结果确定所述待检测软件功能的实际检测结果：如果确定所述当前检测结果处于所述理论结果的阈值范围内，确定所述待检测软件功能未出现功能故障；如果确定所述当前检测结果未处于所述理论结果的阈值范围内，确定所述待检测软件功能出现功能故障。
在上述多个技术方案的基础上，软件功能检测模块32是设置为，基于所述检测逻辑运行所述待检测软件功能，读取所述待检测软件功能的运行启动时间或工况信息，将所述运行启动时间或所述工况信息作为所述当前检测结果。
在上述多个技术方案的基础上，该装置还包括：重启模块；其中，重启模块，设置为根据所述功能故障定位所述待检测软件功能的故障点以及确定所述故障点的故障信息；根据所述故障信息生成所述待检测软件功能的重启指令，根据所述重启指令重启所述待检测软件功能。
在上述多个技术方案的基础上，该装置还包括：重新检测模块；其中，重新检测模块，设置为基于所述检测逻辑对重启后的待检测软件功能进行检测，得到再次检测结果，如果再次检测结果处于所述理论结果的阈值范围内，确定重启后的待检测软件功能未出现功能故障。
在上述多个技术方案的基础上，所述待检测软件功能的数量为至少一个，所述至少一个待检测软件功能包括通讯功能、刹车功能、油门控速功能以及滑行功能中的至少一种，每个待检测软件功能的检测标识预先根据所述每个待检测软件功能对应的硬件设备确定。
在上述多个技术方案的基础上，该装置还包括：并行检测模块；其中，并行检测模块，设置为如果所述待检测软件的功能的数量为至少两个，按照并行检测的方式对所述至少两个待检测软件功能进行检测。
本实施例提供的技术方案，通过获取待检测软件功能的检测标识，根据检测标识确定待检测软件功能对应的检测逻辑，基于检测逻辑对待检测软件功能进行检测，输出当前检测结果，将当前检测结果与预先确定的待检测软件功能的理论结果进行比较，根据比较结果确定待检测软件功能的实际检测结果。该 方法解决了相关技术中因需要根据软件逻辑所依赖的数据或对应的硬件的输出数据检测待检测软件功能，而导致容易出现误检测的问题，实现提高待检测软件功能的检测准确率的效果，同时，该方法不需要硬件参与易于实现，并便于对车辆维修。
实施例三
图4为本申请实施例三提供的一种车辆软件故障检测设备的结构示意图。图4示出了适于用来实现本申请实施方式的示例性车辆软件故障检测设备12的框图。图4显示的车辆软件故障检测设备12仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
如图4所示，车辆软件故障检测设备12以通用计算设备的形式表现。车辆软件故障检测设备12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。
总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(Industrial Standard Architecture，ISA)总线，微通道体系结构(Micro-Channel Architecture，MCA)总线，增强型ISA总线、视频电子标准协会(Video Electronics Standards Association，VESA)局域总线以及外围组件互连(Peripheral Component Interconnect，PCI)总线。
车辆软件故障检测设备12包括多种计算机系统可读介质。这些介质可以是任何能够被车辆软件故障检测设备12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(Random Access Memory，RAM)30和/或高速缓存存储器32。车辆软件故障检测设备12可以包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以设置为读写不可移动的、非易失性磁介质(图4未显示，通常称为“硬盘驱动器”)。尽管图4中未示出，存储系统34可以提供设置为对可移动非易失性磁盘(例如“软盘”)进行读写的磁盘驱动器，以及对可移动非易失性光盘(例如便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM),数字视盘只读存储器(Digital Video Disc Read-Only Memory，DVD-ROM)或者其它光介质)进行读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。存储器28可以包括至少一个程序产品，该程序产品具有一组(例 如车辆软件故障检测装置的检测逻辑确定模块31、软件功能检测模块32以及检测结果确定模块33)程序模块，这些程序模块被配置以执行本申请多个实施例的功能。
具有一组(例如车辆软件故障检测装置的检测逻辑确定模块31、软件功能检测模块32以及检测结果确定模块33)程序模块46的程序/实用工具44，可以存储在例如存储器28中，这样的程序模块46包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块46通常执行本申请所描述的实施例中的功能和/或方法。
车辆软件故障检测设备12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该车辆软件故障检测设备12交互的设备通信，和/或与使得该车辆软件故障检测设备12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(Input/Output，I/O)接口22进行。并且，车辆软件故障检测设备12还可以通过网络适配器20与一个或者多个网络(例如局域网(Local Area Network，LAN)，广域网(Wide Area Network，WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与车辆软件故障检测设备12的其它模块通信。应当明白，尽管图中4未示出，可以结合车辆软件故障检测设备12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、磁盘阵列(Redundant Arrays of Independent Disks，RAID)系统、磁带驱动器以及数据备份存储系统等。
处理单元16通过运行存储在系统存储器28中的程序，从而执行多种功能应用以及数据处理，例如实现本申请实施例所提供的一种车辆软件故障检测方法，该方法包括：获取待检测软件功能的检测标识，根据所述检测标识确定待检测软件功能对应的检测逻辑；基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
处理单元16通过运行存储在系统存储器28中的程序，从而执行多种功能应用以及数据处理，例如实现本申请实施例所提供的一种车辆软件故障检测方法。
当然，本领域技术人员可以理解，处理器还可以实现本申请任意实施例所提供的一种车辆软件故障检测方法的技术方案。
实施例四
本申请实施例四还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请实施例所提供的一种车辆软件故障检测方法，该方法包括：获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
当然，本申请实施例所提供的一种计算机可读存储介质，其上存储的计算机程序不限于如上的方法操作，还可以执行本申请任意实施例所提供的一种车辆软件故障检测方法中的相关操作。
本申请实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、系统或器件，或者任意以上的组合。计算机可读存储介质的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、RAM、只读存储器(Read-Only Memory，ROM)、可擦式可编程只读存储器(Erasable Programmable Read-Only-Memory，EPROM)或闪存、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、系统或者器件使用或者与其结合使用。
计算机可读的信号介质可以包括在当前检测结果、理论结果、实际检测结果等中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用当前检测结果、理论结果、实际检测结果等形式。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、系统或者器件使用或者与其结合使用的程序。
计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于无线、电线、光缆、射频(Radio Frequency，RF)等，或者上述的任意合适的组合。
可以以一种或多种程序设计语言或其组合来编写用于执行本申请操作的计算机程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如”C”语言或类似的 程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括LAN或WAN—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
值得注意的是，上述车辆软件故障检测装置的实施例中，所包括的多个模块只是按照功能逻辑进行划分的，但并不局限于上述的划分，只要能够实现相应的功能即可；另外，多个功能单元的名称也只是为了便于相互区分，并不用于限制本申请的保护范围。

Claims (10)

  1. 一种车辆软件故障检测方法，包括：
    获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；
    基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；
    将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
  2. 根据权利要求1所述的方法，其中，所述将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果，包括：
    响应于所述当前检测结果处于所述理论结果的阈值范围内的确定结果，确定所述待检测软件功能未出现功能故障；
    响应于所述当前检测结果未处于所述理论结果的阈值范围内的确定结果，确定所述待检测软件功能出现功能故障。
  3. 根据权利要求1所述的方法，其中，所述基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果，包括：
    基于所述检测逻辑运行所述待检测软件功能，读取所述待检测软件功能的运行启动时间或工况信息，将所述运行启动时间或所述工况信息作为所述当前检测结果。
  4. 根据权利要求2所述的方法，在确定所述待检测软件功能出现功能故障的情况下，还包括：
    根据所述功能故障定位所述待检测软件功能的故障点以及确定所述故障点的故障信息；
    根据所述故障信息生成所述待检测软件功能的重启指令，根据所述重启指令重启所述待检测软件功能。
  5. 根据权利要求4所述的方法，还包括：
    基于所述检测逻辑对重启后的待检测软件功能进行检测，得到再次检测结果，在所述再次检测结果处于所述理论结果的阈值范围内的情况下，确定所述重启后的待检测软件功能未出现所述功能故障。
  6. 根据权利要求1所述的方法，其中，所述待检测软件功能的数量为至少一个，所述至少一个待检测软件功能包括通讯功能、刹车功能、油门控速功能以及滑行功能中的至少一种，每个待检测软件功能的检测标识预先根据所述每 个待检测软件功能对应的硬件设备确定。
  7. 根据权利要求1所述的方法，在所述待检测软件功能的数量为至少两个的情况下，按照并行检测的方式对所述至少两个待检测软件功能进行检测。
  8. 一种车辆软件故障检测装置，包括：
    检测逻辑确定模块，设置为获取待检测软件功能的检测标识，根据所述检测标识确定所述待检测软件功能对应的检测逻辑；
    软件功能检测模块，设置为基于所述检测逻辑对所述待检测软件功能进行检测，输出当前检测结果；
    检测结果确定模块，设置为将所述当前检测结果与预先确定的所述待检测软件功能的理论结果进行比较，根据比较结果确定所述待检测软件功能的实际检测结果。
  9. 一种车辆软件故障检测设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述计算机程序时实现如权利要求1-7中任一项所述的车辆软件故障检测方法。
  10. 一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时实现如权利要求1-7中任一项所述的车辆软件故障检测方法。
PCT/CN2021/097709 2020-06-05 2021-06-01 车辆软件故障检测方法、装置、设备及存储介质 WO2021244535A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010506892.8 2020-06-05
CN202010506892.8A CN111694687A (zh) 2020-06-05 2020-06-05 一种车辆软件故障检测方法、装置、设备及存储介质

Publications (1)

Publication Number Publication Date
WO2021244535A1 true WO2021244535A1 (zh) 2021-12-09

Family

ID=72479570

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/097709 WO2021244535A1 (zh) 2020-06-05 2021-06-01 车辆软件故障检测方法、装置、设备及存储介质

Country Status (2)

Country Link
CN (1) CN111694687A (zh)
WO (1) WO2021244535A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114397124A (zh) * 2022-01-11 2022-04-26 厦门安科科技有限公司 拆楼机中各机构的交互检测方法及检测装置

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111694687A (zh) * 2020-06-05 2020-09-22 中国第一汽车股份有限公司 一种车辆软件故障检测方法、装置、设备及存储介质
CN112254983A (zh) * 2020-10-16 2021-01-22 中国第一汽车股份有限公司 一种车辆检测方法、装置、设备及存储介质
CN112731875B (zh) * 2020-12-21 2022-09-13 珠海格力电器股份有限公司 目标设备控制方法及装置、非易失性存储介质和处理器
CN114740825A (zh) * 2022-04-13 2022-07-12 中国第一汽车股份有限公司 数据测量标定方法、装置、车用控制器、车辆及介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108763076A (zh) * 2018-05-22 2018-11-06 深圳乐信软件技术有限公司 一种软件自动测试方法、装置、设备及介质
CN109887125A (zh) * 2019-02-02 2019-06-14 北京主线科技有限公司 故障检测方法及装置
CN110764993A (zh) * 2019-09-02 2020-02-07 深圳壹账通智能科技有限公司 自动化测试方法及终端设备
CN111694687A (zh) * 2020-06-05 2020-09-22 中国第一汽车股份有限公司 一种车辆软件故障检测方法、装置、设备及存储介质

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000328916A (ja) * 1999-05-19 2000-11-28 Honda Motor Co Ltd エンジンの潤滑制御装置
CN101895540B (zh) * 2010-07-12 2015-08-12 中兴通讯股份有限公司 用于应用服务进程守护的系统和方法
CN104216810A (zh) * 2013-09-13 2014-12-17 上海炬力集成电路设计有限公司 一种智能手持设备的硬件故障的检测方法及检测装置
CN104932978B (zh) * 2015-06-29 2018-04-13 北京宇航时代科技发展有限公司 一种系统运行故障自检测及自修复的方法和系统
CN110134540A (zh) * 2019-05-21 2019-08-16 苏州浪潮智能科技有限公司 一种日志信息收集方法、装置、设备及可读存储介质
CN111007827A (zh) * 2020-03-11 2020-04-14 天津美腾科技股份有限公司 一种设备的报警方法、设备及计算机可读存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108763076A (zh) * 2018-05-22 2018-11-06 深圳乐信软件技术有限公司 一种软件自动测试方法、装置、设备及介质
CN109887125A (zh) * 2019-02-02 2019-06-14 北京主线科技有限公司 故障检测方法及装置
CN110764993A (zh) * 2019-09-02 2020-02-07 深圳壹账通智能科技有限公司 自动化测试方法及终端设备
CN111694687A (zh) * 2020-06-05 2020-09-22 中国第一汽车股份有限公司 一种车辆软件故障检测方法、装置、设备及存储介质

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114397124A (zh) * 2022-01-11 2022-04-26 厦门安科科技有限公司 拆楼机中各机构的交互检测方法及检测装置

Also Published As

Publication number Publication date
CN111694687A (zh) 2020-09-22

Similar Documents

Publication Publication Date Title
WO2021244535A1 (zh) 车辆软件故障检测方法、装置、设备及存储介质
US11509505B2 (en) Method and apparatus for operating smart network interface card
CN114168222B (zh) 一种启动耗时的获取方法、装置、终端设备和存储介质
CN110083146B (zh) 自动驾驶车辆的故障确定方法及装置、设备及存储介质
CN108874441B (zh) 一种板卡配置方法、装置、服务器和存储介质
CN108572895B (zh) 一种Linux下自动检查软硬件配置的稳定性测试方法
CN107590017B (zh) 一种电子设备的检测方法和装置
CN114253864A (zh) 一种业务测试方法、装置、电子设备及存储介质
CN111694684B (zh) 存储设备的异常构造方法、装置、电子设备及存储介质
CN112713964B (zh) 数据校验加速方法、装置、计算机设备及存储介质
CN111274130A (zh) 一种自动化测试方法、装置、设备及存储介质
TWI393003B (zh) 遠距硬體檢測系統及方法
US8954932B2 (en) Crash notification between debuggers
CN114553663A (zh) 一种异常检测方法、装置、设备和存储介质
JP6217086B2 (ja) 情報処理装置、エラー検出機能診断方法およびコンピュータプログラム
CN116820946B (zh) 一种对目标软件兼容性进行自动化测试的方法和装置
US20200174875A1 (en) Secure forking of error telemetry data to independent processing units
CN113760696A (zh) 一种程序问题定位方法、装置、电子设备和存储介质
CN114546745B (zh) 一种能在可信启动的过程中辨别故障程序段的方法
CN112000579B (zh) 一种软件接口测试方法、系统、设备及介质
CN113094221B (zh) 故障注入方法、装置、计算机设备以及可读存储介质
CN111290920B (zh) 基于peci总线测试cpu温度的系统、方法及存储介质
CN112256554B (zh) 一种基于场景测试用例进行测试的方法及设备
CN108415788B (zh) 用于对无响应处理电路作出响应的数据处理设备和方法
CN118093235A (zh) 一种芯片cpu异常诊断方法和装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21817449

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21817449

Country of ref document: EP

Kind code of ref document: A1