Vehicle fault processing device and method, medium and equipment

Abstract

The invention relates to a vehicle fault processing device and method, a medium and equipment. The vehicle fault processing device comprises an application layer which comprises at least one piece of application software; the base layer comprises at least one piece of base software; the middle layer comprises a diagnosis component and at least one proxy service, and the proxy service comprises an S / R interface corresponding to the application software and a C / S interface corresponding to the diagnosis component; the proxy service is used for acquiring a diagnosis fault code and a processing demand of application software of the application layer through the S / R interface, compiling the diagnosis fault code and the processing demand according to a preset format, and sending the compiled diagnosis fault code and the compiled processing demand to the diagnosis component through the C / S interface; and the diagnosis component is used for determining basic software of the corresponding basic layer from the preset questionnaire according to the compiled diagnosis fault code and the processing requirement, and calling the basic software to carry out parameter setting or parameter acquisition. According to the technical scheme, the technical problem that BSW software development difficulty is large is solved.

Description

Technical Field

[0001] The present disclosure relates to the field of automotive technologies, and particularly to a vehicle fault handling device, method, medium and equipment. Background Art

[0002] In recent years, with the continuous development of automotive technologies and the improvement of economic levels, automobiles, as major consumer goods, have entered thousands of households. When purchasing an automobile, users not only care about the price, appearance and performance of the automobile, but also the safety of the automobile is a major factor for users to consider when making a purchase.

[0003] During the operation of a vehicle, some faults will inevitably occur. To ensure driving safety, the fault lamp on the vehicle or a diagnostic instrument is connected through the full-name on-board diagnostic system (On-Board Diagnostics, abbreviated as OBD) interface on the vehicle during maintenance to read the fault code, so as to further locate more specific fault components. Automotive Open System Architecture (abbreviated as AUTOSAR) is a set of standard protocols and software architectures. Automotive application software developed according to this standard has good scalability and portability. In the current AUTOSAR fault diagnosis implementation solution, the application software (Application software, abbreviated as ASW) of AUTOSAR calls the interface of the basic software (Basic software, abbreviated as BSW) through the real-time environment (RealTime Environment, abbreviated as RTE) to send a diagnostic trouble code (Diagnostic Trouble Code, abbreviated as DTC) to the BSW. The BSW reads the DTC and performs debounce processing based on the anti-shake detection period read from the DTC to achieve the purpose of setting and obtaining.

[0004] For different DTCs, the ASW will call different BSW interfaces, and each DTC has at least two interfaces (set and get). When developing software, for each interface of the newly added DTC, corresponding development and design of the BSW are required for the ASW to call. Therefore, the decoupling between the ASW and the BSW is poor, and it highly depends on the timeliness and correctness of the input file. This requires the developers of the BSW software to be very familiar with the configuration tool and a large amount of communication work is needed. In the case of multi-core scenarios, when it is required to configure the fault diagnosis module satellite (dem satellite), it is easy to make mistakes in interacting and starting with other modules. If new DTCs need to be added or deleted, or the mapping relationship (across cores or other ASWs) needs to be changed, the BSW needs to be re-integrated and released, resulting in a slow change response. New functions need to be re-customized and are basically not reusable, leading to the inability to accumulate achievement experience and poor portability. Because different interfaces are called, it is difficult to add new functions and the scalability is poor. For example, when adding a new logging function, the inconsistent interfaces make it difficult to implement. Therefore, the prior art has the technical problem of relatively high development difficulty of the BSW software. Summary of the Invention

[0005] To solve the above technical problems, the present disclosure provides a vehicle fault processing device, method, medium and equipment to solve the technical problem of relatively high development difficulty of the BSW software existing in the prior art.

[0006] The present disclosure provides a vehicle fault processing device, including:

[0007] An application layer, including at least one application software;

[0008] A basic layer, including at least one basic software;

[0009] An intermediate layer, including a diagnosis component and at least one proxy service, where the proxy service includes an S / R interface corresponding to the application software and a C / S interface corresponding to the diagnosis component;

[0010] The proxy service is configured to obtain the diagnostic trouble codes and processing requirements of the application software in the application layer through the S / R interface, compile the diagnostic trouble codes and the processing requirements according to a preset format, and send the compiled diagnostic trouble codes and the processing requirements to the diagnosis component through the C / S interface;

[0011] The diagnosis component is configured to determine the corresponding basic software in the basic layer from a preset questionnaire according to the compiled diagnostic trouble codes and the processing requirements, and call the basic software to perform parameter setting or parameter acquisition.

[0012] In some embodiments, the diagnosis component is specifically configured to:

[0013] Determine the diagnosed fault code and the processing requirement that meet the processing conditions;

[0014] According to the diagnosed fault code and the processing requirement that meet the processing conditions, determine the basic software of the corresponding basic layer from a preset questionnaire;

[0015] Call the corresponding basic software to set or obtain parameters;

[0016] Send the status of parameter setting or the value obtained from parameter acquisition to the proxy service through the C / S interface.

[0017] In some embodiments, after the diagnosis component determines the diagnosed fault code and the processing requirement that meet the processing conditions, it is further configured to:

[0018] Read the type of setting parameter of the processing requirement that meets the processing conditions, and adjust the setting parameter status from direct setting fault to debounce setting fault.

[0019] In some embodiments, after the diagnosis component reads the type of setting parameter of the processing requirement and adjusts the setting parameter status from direct setting fault to debounce setting fault, it is further configured to:

[0020] Output the adjusted setting parameter status through a medium.

[0021] In some embodiments, when the diagnosis component calls the corresponding basic software to set parameters, it specifically includes:

[0022] The diagnosis component traverses the processing requirements to be processed and obtains the debounce detection period of each processing requirement;

[0023] For the processing requirements whose debounce detection period meets the setting conditions, call the corresponding basic software to set parameters.

[0024] In some embodiments, the preset questionnaire includes a display code, a diagnosed fault code, a fault type, an enabling condition, a setting condition, and a recovery condition.

[0025] In some embodiments, there are multiple proxy services, and the multiple proxy services are respectively set in multiple cores of AUTOSAR.

[0026] The present disclosure also provides a vehicle fault processing method, which is applied to the above vehicle fault processing device, and the method includes:

[0027] The proxy service obtains the diagnosed fault code and the processing requirement of the application software in the application layer through the S / R interface, compiles the diagnosed fault code and the processing requirement according to a preset format, and sends the compiled diagnosed fault code and the processing requirement to the diagnosis component through the C / S interface;

[0028] The diagnostic component determines the corresponding basic software at the basic layer from a preset questionnaire according to the compiled diagnostic trouble code and the processing requirements, and calls the basic software to set or obtain parameters.

[0029] The present disclosure also provides a computer-readable storage medium storing a program or instructions, and the program or instructions cause a computer to execute the steps of any of the above methods.

[0030] The present disclosure also provides an electronic device, including:

[0031] One or more processors;

[0032] A memory for storing one or more programs or instructions;

[0033] The processor is configured to execute the steps of any of the above methods by calling the programs or instructions stored in the memory.

[0034] The technical solution provided by the embodiments of the present disclosure has the following advantages compared with the prior art:

[0035] The technical solution provided by the embodiments of the present disclosure can be applied to AUTOSAR. The application layer of AUTOSAR includes at least one application software (ASW); the basic layer includes at least one basic software (BSW); the middle layer includes a diagnostic component and at least one proxy service. The proxy service includes an S / R interface corresponding to the ASW and a C / S interface corresponding to the diagnostic component. The proxy service obtains the diagnostic trouble code and processing requirements of the ASW in the application layer through the S / R interface, compiles the diagnostic trouble code and processing requirements in a preset format, and then sends the compiled diagnostic trouble code and processing requirements to the diagnostic component through the C / S interface. The diagnostic component determines the corresponding BSW in the basic layer from a preset questionnaire according to the compiled trouble code and processing requirements, and calls the BSW to set or obtain parameters. The embodiments of the present disclosure realize the downward call of the BSW, reducing the dependence of fault handling on the BSW. The proxy service uses the S / R interface to obtain the diagnostic trouble code and processing requirements of the ASW and compiles the diagnostic trouble code and processing requirements in a preset format. Therefore, the compiled diagnostic trouble code and processing requirements can be sent to the diagnostic component through the C / S interface, realizing the unified setting and obtaining of the status of the DTC, avoiding direct communication between the ASW and the BSW through a large number of different types of RTE interfaces, realizing the decoupling of the BSW and the ASW, not requiring different RTE interfaces to obtain the status of each DTC, and software developers not needing to be familiar with the call interfaces of the BSW, solving the technical problem of high software development difficulty. Description of the Drawings

[0036] The accompanying drawings here are incorporated into the specification and form a part of this specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure.

[0037] To more clearly illustrate the technical solutions in the embodiments of the present disclosure or in the prior art, the following will briefly introduce the accompanying drawings required for use in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, without creative efforts, other drawings can also be obtained based on these drawings.

[0038] Figure 1 The structural block diagram of a vehicle fault handling device provided for an embodiment of the present disclosure;

[0039] Figure 2 The flowchart of a vehicle fault handling method provided for an embodiment of the present disclosure;

[0040] Figure 3 The flowchart of Function 1 of the diagnostic component in an embodiment of the present disclosure;

[0041] Figure 4 The flowchart of Function 2 of the diagnostic component in an embodiment of the present disclosure;

[0042] Figure 5 The flowchart of Function 3 of the diagnostic component in an embodiment of the present disclosure;

[0043] Figure 6 The structural schematic diagram of an electronic device provided for an embodiment of the present disclosure. Detailed implementation manners

[0044] In order to be able to more clearly understand the above objects, features, and advantages of the present disclosure, the following will further describe the solutions of the present disclosure. It should be noted that, without conflict, the embodiments of the present disclosure and the features in the embodiments can be combined with each other.

[0045] Many specific details are set forth in the following description to fully understand the present disclosure, but the present disclosure can also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all the embodiments.

[0046] Figure 1 The structural block diagram of a vehicle fault handling device provided for an embodiment of the present disclosure, and this device can be applied to the fault diagnosis and handling of intelligent vehicles.

[0047] This vehicle fault handling device can be applied to AUTOSAR, such as Figure 2As shown in the figure, AUTOSAR includes an application layer, an intermediate layer, and a basic layer. The vehicle fault handling device provided in the embodiments of the present disclosure belongs to the intermediate layer between the application layer and the basic layer. The application layer includes at least one ASW, which is distributed on different cores. In the embodiments of the present disclosure, ASW0, ASW1, and ASW2 are respectively distributed on core1, core2, and core3. The intermediate layer includes a diagnostic component Diag_SWC and at least one proxy service. For example, Diag_Proxy0, Diag_Proxy1, and Diag_Proxy2 represent the proxy services on each core. They use the send / reciever (S / R) interface to receive the setting requirements and acquisition requirements of each core and count them all into Diag_Proxy0, which can reduce the load. Diag_Proxy0 calls the Client / Server (C / S) interface to access the services of the diagnostic component Diag_SWC and transfer the setting parameters and acquisition parameters. The basic layer includes at least one basic software. For example, the basic layer includes the basic software Diag_BSW and other software Other_BSW. The basic software is used to perform setting processing on faults, and the other software represents collecting the setting requirements of other modules of BSW, such as drivers, operating systems, communications, networks, etc.

[0048] Diag_Proxy0, Diag_Proxy1, Diag_Proxy2: They are the proxy services on each core. They receive the setting requirements and acquisition requirements of each core through the S / R interface and count them all into Diag_Proxy0. Diag_Proxy0 calls the C / S interface to access the services of the diagnostic component Diag_SWC and transfer the setting parameters and acquisition parameters.

[0049] Diag_SWC: It is a software component in AUTOSAR, that is, a diagnostic component, which is used to call the basic software of the basic layer to perform parameter setting or parameter acquisition.

[0050] The proxy service Diag_Proxy0 obtains the diagnostic fault codes and processing requirements of ASW0, ASW1, and ASW2 in the application layer through the S / R interface, compiles the diagnostic fault codes and processing requirements in a preset format, and then sends the compiled diagnostic fault codes and processing requirements to the diagnostic component Diag_SWC through the C / S interface. The diagnostic component Diag_SWC determines the corresponding BSW in the basic layer from a preset questionnaire according to the compiled fault codes and processing requirements, and calls the BSW to perform parameter setting or parameter acquisition.

[0051] The vehicle fault handling device provided by the embodiments of the present disclosure realizes downward BSW calls, reducing the dependence of fault handling on BSW. The proxy service uses the S / R interface to obtain the diagnostic fault codes and processing requirements of the ASW, and compiles the diagnostic fault codes and processing requirements according to a preset format. Therefore, the compiled diagnostic fault codes and processing requirements can be sent to the diagnostic component through the C / S interface, realizing the unified setting and acquisition of the status of DTCs, avoiding direct communication between the ASW and the BSW through a large number of different types of RTE interfaces, realizing the decoupling of the BSW and the ASW, and not requiring different RTE interfaces to obtain the status of each DTC. Software developers do not need to be familiar with the call interfaces of the BSW, solving the technical problem of relatively high software development difficulty.

[0052] As Figure 2 shown, the embodiments of the present disclosure also provide a vehicle fault handling method, which is applied to the above vehicle fault handling device. The method includes the following steps:

[0053] S110. The proxy service obtains the diagnostic fault codes and processing requirements of the application software in the application layer through the S / R interface, compiles the diagnostic fault codes and processing requirements according to a preset format, and sends the compiled diagnostic fault codes and processing requirements to the diagnostic component through the C / S interface.

[0054] For example, when ASW1 in the application layer wants to set the overcurrent fault of the right front lamp, the proxy service Diag_Proxy1 will obtain the diagnostic fault codes and processing requirements of ASW1 through the S / R interface and forward them to the proxy service Diag_Proxy0. Another example is that when ASW0 in the application layer wants to set the BCM node loss fault, the proxy service Diag_Proxy0 will obtain the diagnostic fault codes and processing requirements of ASW0 through the S / R interface.

[0055] The proxy service Diag_Proxy0 counts all the obtained diagnostic fault codes and processing requirements received by all Diag_Proxys, compiles the diagnostic fault codes and processing requirements according to a preset format, and sends the compiled diagnostic fault codes and processing requirements to the diagnostic component Diag_SWC through the C / S interface.

[0056] S120. The diagnostic component determines the corresponding basic software in the basic layer from a preset questionnaire according to the compiled diagnostic fault codes and processing requirements, and calls the basic software to set or obtain parameters.

[0057] The diagnostic component Diag_SWC is a software component in AUTOSAR and is the core component of diagnostic processing. In some embodiments, the diagnostic component Diag_SWC is specifically used for:

[0058] Determine the diagnostic trouble codes and processing requirements that meet the processing conditions;

[0059] Based on the diagnostic trouble codes and processing requirements that meet the processing conditions, determine the corresponding basic software at the basic layer from the preset questionnaire;

[0060] Call the corresponding basic software to set or obtain parameters;

[0061] Send the status of parameter setting or the value obtained by parameter acquisition to the proxy service through the C / S interface.

[0062] The specific diagnostic processing method of the diagnostic component Diag_SWC is mainly implemented through the following three functions:

[0063] Function 1: Used to judge and record the received parameters and return the status.

[0064] Function 2: Used to process the parameters and finally call the basic software Diag_BSW for setting.

[0065] Function 3: Used to judge and record the received parameters and return the request result of the get operation.

[0066] As Figure 3 shown, Function 1 mainly includes five steps, which perform the following operations respectively:

[0067] Condition judgment: Diag_BSW reads the diagnostic trouble codes and processing requirements, and judges the diagnostic trouble codes and processing requirements that meet the processing conditions based on the preset questionnaire. Then, based on the diagnostic trouble codes and processing requirements that meet the processing conditions, determine the corresponding basic software at the basic layer from the preset questionnaire.

[0068] This step uses the proxy service for condition judgment. For each input parameter (diagnostic trouble code and processing requirement), judge whether it meets the processing conditions, such as whether it is enabled, whether the input parameter exceeds the limit, whether it is in the calibration or test state, etc., and can be judged based on the preset questionnaire. The preset questionnaire is an input questionnaire required for any diagnostic development, with various forms but must contain the necessary information. The embodiments of the present disclosure carry out development work based on this necessary information.

[0069] In some embodiments, the preset questionnaire includes display codes, diagnostic trouble codes, fault types, enabling conditions, setting conditions, and recovery conditions. The common form of the preset questionnaire content is as follows. There will be 20 - 500 faults according to the project complexity. The following table only exemplarily lists 3 faults.

[0070]

[0071] In some embodiments, Diag_Proxy0 determines whether the condition of "right front headlight overcurrent fault" is met, whether the fault enabling conditions such as "normal power supply voltage (9 - 16V)" are met, whether the vehicle model meets the requirements, whether it is not in the fault clearing state, and whether the input parameters exceed the limit. If any of the above is not met, the process will end.

[0072] The input parameter exceeding the limit means that the input parameter exceeds the system setting limit. For example, if the current system only supports 5 faults and the input parameter is to set the 6th fault, it is judged as exceeding the limit. Another example is that if the supported fault status is only to restore the fault and set the fault, but the input parameter is to clear the fault, it is judged as exceeding the limit.

[0073] In some embodiments, the fault of "right front headlight overcurrent fault" does not belong to the lost type of fault, and the processing steps are directly executed; in some embodiments, if it is a lost type of fault, such as "BCM node lost", the pre - processing steps need to be executed.

[0074] Then, according to the diagnostic trouble code and processing requirements that meet the processing conditions, the corresponding enabling conditions, setting conditions, and recovery conditions are determined from the preset questionnaire, and then the corresponding basic software at the basic layer is determined.

[0075] Pre - processing: Read the type of setting parameter of the processing requirement that meets the processing conditions, and change the setting parameter status from directly setting the fault to debouncing the setting of the fault. According to whether the fault enabling condition is met for the first time, change the transmitted parameter. If it is not the first time to be met, change from the original directly setting the fault (FAILED) to the setting that needs debouncing (PREFAILED). If it is the first time to be met, the pre - processing steps can be skipped.

[0076] Processing: Call the corresponding basic software to set the parameter or obtain the parameter.

[0077] According to the data logic judgment of the input parameter, write the input parameter into the data structure, change the data in the system, and provide the call of Function 2.

[0078] If the pre - processing steps have been carried out, the post - processing steps need to be carried out; if the pre - processing steps have not been carried out before, the return status steps are directly carried out.

[0079] Post - processing: Judge according to the requirements whether to convert the input parameter status, whether there is a printing requirement, etc.

[0080] Convert back to directly setting the fault (FAILED). If the requested setting status is inconsistent with the previous time, the adjusted setting parameter status will be output through the medium, call the printing interface, print this information, and send this information through a certain medium (such as message, serial port, etc.). This step can assist in code debugging and error troubleshooting and avoid frequent printing.

[0081] Return status: Return the diagnostic processing result to the proxy service through the C / S interface, including the status of parameter setting or the value obtained for parameter acquisition.

[0082] If any one of the preprocessing step, processing step, and postprocessing step has an exception, return the corresponding step number and corresponding status, such as failure / busy / overrun (not_ok / busy / overrun), etc.; if there is no exception, return the final status, such as success (ok).

[0083] As Figure 4 shown, in some embodiments, Function 2 called in the above processing step, which is the processing step in Function 1 above, specifically includes the following steps:

[0084] The diagnostic component traverses the processing requirements to be processed and obtains the anti-shake detection period for each processing requirement. For example, it cyclically determines whether there is a setting requirement for all DTCs with a period of 10 ms, that is, traverses and reads the input parameters written in the above processing step to determine whether processing is required. Those that do not require processing can be ignored; those that require processing are classified according to their anti-shake detection period (such as the period of the setting condition in the preset questionnaire), divided into 10 ms, 20 ms, 50 ms, etc., and then calculated and processed according to their anti-shake type (such as processing based on the number of times or processing based on time).

[0085] For the processing requirements whose anti-shake detection period meets the setting condition, call the corresponding basic software to set the parameters.

[0086] According to the anti-shake calculation rule that conforms to ISO-14229, finally, according to whether the anti-shake condition meets the setting condition, call the corresponding Diag_BSW interface for setting, and count the finally debounced result into Diag_BSW for subsequent processing of the occurred faults.

[0087] As Figure 5 shown, in some embodiments, the function three of the diagnostic component Diag_SWC includes five steps. The first four steps are similar to Function 1, including the condition judgment step, preprocessing step, processing step, and postprocessing step. The fifth step is the return value step, which returns the status result of the DTC. That is, if the input parameter of AWS is a setting requirement or a recovery requirement, the diagnostic component enables Function 1; if the input parameter of AWS is an acquisition requirement, the diagnostic component enables Function 3.

[0088] The embodiments of the present disclosure use the fault diagnosis middle layer to process data by itself, the setting and processing are asynchronous, the C / S interface is used to uniformly set and obtain the DTC status, and the cross-core is implemented by means of a proxy service, which has at least the following advantages:

[0089] 1. Unified interface. During the setup phase, the fault handling of ASW and BSW is unified, facilitating problem troubleshooting, function optimization, log addition, etc. During the acquisition phase, instead of obtaining the status of each DTC based on different RTE interfaces (e.g., rte_0xf00013_getUDSeventStatus, rte_0xf00014_getUDSeventStatus, etc.), the status is obtained based on different input parameters without passing through the BSW, so the response is rapid.

[0090] 2. Integrated conveniently. It is only connected to the ASW through two C / S interfaces, and the function decoupling and integration are fast and convenient.

[0091] 3. Strong scalability. It is convenient to add new functions, such as the status of the anti-shake accumulation times and the internal state machine information.

[0092] 4. Strong decoupling. The BSW and ASW are truly decoupled, each performing its own functions, which is convenient for quickly troubleshooting and locating problems.

[0093] 5. Strong reusability. It is convenient for the transplantation and reuse of functions on different platforms.

[0094] 6. Support for multi-core scenarios.

[0095] The proxy service Diag_Proxy in the embodiments of the present disclosure has the following advantages:

[0096] 1. As an intermediate layer, it manages the ASW calls upward: meeting the unified interface, supporting the one-to-many interface form, and multi-core requirements, etc.

[0097] 2. As an intermediate layer, it makes good interface calls to the BSW downward, collects enabling conditions, sets the BSW setting interface, and reduces the dependence on the BSW, etc.

[0098] 3. As an intermediate layer, it independently implements statistical anti-shake, distinguishes between time-based and counter-based, distinguishes different detection cycles, and meets the compatibility of unified diagnostic services (UDS) instructions, etc.

[0099] 4. Meet the reliability of special scenarios: frequent changes in input parameters, combination of enabling conditions and setting operations, etc.

[0100] 5. Meet other requirements: control the impact on the load rate.

[0101] The embodiments of the present disclosure also provide a computer-readable storage medium, and the computer-readable storage medium stores programs or instructions, and the programs or instructions cause the computer to execute the steps of any one of the above methods.

[0102] Optionally, when the computer-executable instructions are executed by a computer processor, they can also be used to execute the technical solutions of any of the above vehicle fault handling methods provided by the embodiments of the present disclosure, achieving corresponding beneficial effects.

[0103] From the above description of the embodiments, those skilled in the art can clearly understand that the embodiments of the present disclosure can be implemented by means of software and the necessary general-purpose hardware. Of course, it can also be implemented by hardware, but in many cases, the former is a better implementation. Based on this understanding, the technical solutions of the embodiments of the present disclosure, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as a floppy disk, read-only memory (ROM), random access memory (RAM), flash memory (FLASH), hard disk, or optical disc of a computer, etc., including several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments of the present disclosure.

[0104] The embodiments of the present disclosure also provide an electronic device, including: one or more processors; a memory for storing one or more programs or instructions; the processor is configured to execute the steps of any of the above methods by calling the programs or instructions stored in the memory, achieving corresponding beneficial effects.

[0105] Figure 6 It is a schematic diagram of the hardware structure of the electronic device provided by the embodiments of the present disclosure. As Figure 6 shown, the electronic device includes one or more processors 601 and a memory 602.

[0106] The processor 601 can be a central processing unit (CPU) or other forms of processing units with data processing capabilities and / or instruction execution capabilities, and can control other components in the electronic device to execute the desired functions.

[0107] The memory 602 may include one or more computer program products, and the computer program products may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory, etc. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage media, and the processor 601 may run the program instructions to implement the vehicle fault handling method of the embodiments of the present disclosure described above, and / or other desired functions. Various contents such as input signals, signal components, noise components, etc. may also be stored in the computer-readable storage media.

[0108] In one example, the electronic device may further include: an input device 603 and an output device 604, and these components are interconnected through a bus system and / or other forms of connection mechanisms (not shown).

[0109] In addition, the input device 603 may further include, for example, a keyboard, a mouse, and so on.

[0110] The output device 604 may output various information to the outside, including the determined distance information, direction information, etc. The output device 604 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0111] Of course, for simplicity, Figure 6 only some of the components related to the present disclosure in the electronic device are shown, and components such as buses, input / output interfaces, etc. are omitted. In addition, according to specific application scenarios, the electronic device may further include any other appropriate components.

[0112] It should be noted that in this article, the term "include", "comprise" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements not only includes those elements, but also includes other elements not expressly listed, or further includes elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "including one..." does not exclude the existence of another identical element in the process, method, article or device including the element.

[0113] The above are only specific embodiments of the present disclosure, enabling those skilled in the art to understand or implement the present disclosure. Various modifications to these embodiments will be obvious to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure will not be limited to these embodiments described herein, but rather will be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A vehicle fault handling device, characterized in that, Comprising: An application layer, including at least one application software; A basic layer, including at least one basic software; An intermediate layer, including a diagnosis component and at least one proxy service, where the proxy service includes an S / R interface corresponding to the application software and a C / S interface corresponding to the diagnosis component; The proxy service is used to obtain the diagnostic trouble codes and processing requirements of the application software in the application layer through the S / R interface, compile the diagnostic trouble codes and the processing requirements according to a preset format, and send the compiled diagnostic trouble codes and the processing requirements to the diagnosis component through the C / S interface; The diagnosis component is used to determine the corresponding basic software in the basic layer from a preset questionnaire according to the compiled diagnostic trouble codes and the processing requirements, and call the basic software to perform parameter setting or parameter acquisition.

2. The device according to claim 1, characterized in that, Specifically, the diagnosis component is used for: Judging the diagnostic trouble codes and the processing requirements that meet the processing conditions; Determining the corresponding basic software in the basic layer from a preset questionnaire according to the diagnostic trouble codes and the processing requirements that meet the processing conditions; Calling the corresponding basic software to perform parameter setting or parameter acquisition; Sending the status of parameter setting or the value of parameter acquisition to the proxy service through the C / S interface.

3. The device according to claim 2, characterized in that After the diagnosis component judges the diagnostic trouble codes and the processing requirements that meet the processing conditions, it is further used for: Reading the setting parameter type of the processing requirements that meet the processing conditions, and adjusting the setting parameter status from direct setting fault to debounce setting fault.

4. The device according to claim 3, characterized in that, After the diagnosis component reads the setting parameter type of the processing requirements and adjusts the setting parameter status from direct setting fault to debounce setting fault, it is further used for: Performing media output on the adjusted setting parameter status.

5. The device according to claim 2, characterized in that When the diagnosis component calls the corresponding basic software to perform parameter setting, it specifically includes: The diagnosis component traverses the processing requirements to be processed and obtains the debounce detection period of each processing requirement; For the processing requirements whose debounce detection period meets the setting conditions, call the corresponding basic software to perform parameter setting.

6. The device according to claim 2, characterized in that The preset questionnaire includes display codes, diagnostic trouble codes, fault types, enabling conditions, setting conditions, and recovery conditions.

7. The device according to claim 1, wherein There are multiple proxy services, and the multiple proxy services are respectively arranged in multiple cores of AUTOSAR.

8. A vehicle fault handling method, characterized in that, Applied to the vehicle fault processing device according to any one of claims 1 to 7, the method includes: The proxy service obtains the diagnostic trouble codes and the processing requirements of the application software in the application layer through the S / R interface, compiles the diagnostic trouble codes and the processing requirements according to a preset format, and sends the compiled diagnostic trouble codes and the processing requirements to the diagnosis component through the C / S interface; The diagnosis component determines the corresponding basic software in the basic layer from a preset questionnaire according to the compiled diagnostic trouble codes and the processing requirements, and calls the basic software to perform parameter setting or parameter acquisition.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program or instructions, and the program or instructions cause the computer to execute the steps of the method according to claim 8.

10. An electronic device, characterized in that, Comprising: One or more processors; A memory for storing one or more programs or instructions; The processor is configured to execute the steps of the method according to claim 8 by calling the programs or instructions stored in the memory.

Images