A bottom-layer software fault analysis method, device and medium of a vehicle control unit

Abstract

The embodiment of the specification discloses a kind of bottom software fault analysis method, equipment and medium of whole vehicle controller, involve vehicle software control technical field, method includes: obtaining the open loop test environment of hardware-in-the-loop that is built in advance, to facilitate under the operation trigger instruction, communication verification is carried out, communication state is judged;When normal communication state, control whole vehicle controller is hibernation state, and in preset time interval, control the key switch of whole vehicle controller to be in the open state, to determine power-on time;Determine whether there is the fault of bottom software acquisition at power-on time, if there is fault, obtain the multiple fault messages corresponding to the fault in preset time interval;According to the fault identifier and fault signal quantity of multiple fault messages, multiple fault messages in preset time interval are integrated, and integrated fault message in preset time interval is generated;Integrated fault message is sent to CAN bus, to carry out fault analysis, determine fault information.

Description

Technical Field

[0001] This specification relates to the field of vehicle software control technology, and in particular to a method, device and medium for analyzing the underlying software faults of a vehicle controller. Background Technology

[0002] With economic and social development and the continuous improvement of living standards, the number of vehicles on the road has been increasing year by year. In recent years, the growing awareness of environmental protection has further promoted the development of new energy vehicles. The Vehicle Control Unit (VCU), as one of the three core electronic control systems of new energy vehicles, directly affects the safety of the entire vehicle if damaged. Therefore, during the development of the VCU, it is necessary to verify the VCU under real-vehicle fault conditions to ensure that the VCU meets the design requirements.

[0003] Currently, to verify the actual vehicle fault status of the VCU, a Hardware-in-the-Loop (HIL) test system is typically used for VCU fault testing. However, during actual R&D, it was discovered that during high-voltage power-on / off debugging in a HIL test environment, some underlying software automatically stops data recording during VCU power-down, such as the INCA calibration software. Therefore, fault data from the VCU's power-down to sleep and then power-on process cannot be collected. In other words, when the VCU application layer software is debugged under high voltage power-on / off conditions in a HIL test system, there is a drawback: underlying faults cannot be collected by the INCA calibration software, resulting in incomplete fault data and affecting the effectiveness of fault analysis. Summary of the Invention

[0004] This specification provides one or more embodiments of a method, device, and medium for analyzing the underlying software faults of a vehicle controller, which is used to solve the following technical problem: When the VCU application layer software is debugged under high voltage power-on and power-off in the HIL test system, there is a drawback that the underlying faults cannot be collected by the INCA calibration software, resulting in a lack of comprehensiveness in the collected fault data, which in turn affects the fault analysis effect.

[0005] One or more embodiments of this specification employ the following technical solutions:

[0006] This specification provides one or more embodiments of a method for analyzing the underlying software faults of a vehicle controller. The method includes: acquiring a pre-built hardware-in-the-loop (HIL) open-loop test environment to perform communication verification between the HIL open-loop test environment and the vehicle controller under a trigger command, and determining the communication status between the vehicle controller and the HIL open-loop test environment; when the vehicle controller and the HIL open-loop test environment are in a normal communication state, controlling the vehicle controller to enter a sleep state, and controlling the key switch of the vehicle controller to be in an on state within a preset time interval to determine the power-on time; and determining the fault status of the vehicle controller through the vehicle controller. If a fault is detected by the underlying software at the power-on time, and if such a fault exists, multiple fault messages corresponding to the fault within the preset time interval are obtained, wherein each fault message includes a fault identifier and a fault semaphore; based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval; the integrated fault message is sent to the CAN bus to facilitate fault analysis based on the integrated fault message and to determine fault information, wherein the fault information includes fault time information, fault signal information, and fault type information.

[0007] Furthermore, under the trigger command, communication verification is performed on the hardware-in-the-loop open-loop test environment and the vehicle controller to determine the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment. Specifically, this includes: setting the key switch to the on state in the hardware-in-the-loop open-loop test environment to simulate the vehicle's operating state; collecting calibration signals collected by calibration software within a first preset time period in the vehicle's operating state; and determining whether the calibration software is in a normal acquisition state based on the calibration signals and the key switch state. When the calibration software is in a normal acquisition state, the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment is determined to be a normal communication state.

[0008] Furthermore, before acquiring the calibration CAN signal collected by the calibration software within the first preset time period under the vehicle operating state, the method further includes: acquiring multiple historical setting times for historically setting the key switch state, and the historical signal reception time of the historical calibration switch signal corresponding to each historical setting time; determining multiple signal reception periods based on each historical setting time and the historical signal reception time corresponding to each historical setting time, wherein the signal reception period is the reception duration; and determining the specified signal reception period with the longest reception duration among the multiple signal reception periods as the first preset time period.

[0009] Further, based on the fault identifiers and fault semaphores of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. Specifically, this includes: determining the fault type corresponding to each fault message based on the fault identifier of each fault message and a pre-written corresponding file, wherein the fault type is used to identify the vehicle component in the vehicle that has malfunctioned; grouping at least one specified fault message belonging to the same type based on the fault type corresponding to each fault message to obtain multiple type message groups; and grouping the fault semaphores corresponding to the same type of signal based on the fault semaphore of each specified fault message in each type message group to generate multiple signal message subgroups, wherein the fault signal... The quantity includes at least one type of fault signal, and the type of fault signal includes any one or more of voltage signals, current signals, speed signals, displacement signals, and switching signals; obtain the priority order of the fault signals corresponding to each fault type in a preset manner, and determine the fault type corresponding to each of the signal message subgroups, so as to sequentially combine the fault signal quantities of multiple signal message subgroups according to the preset priority order of the fault signals corresponding to each fault type, to obtain a fault signal combination sub-message corresponding to each fault type; obtain the preset priority order of the fault types, and based on the priority order of the fault types and the fault signal combination sub-message corresponding to each fault type, sequentially combine the multiple type message groups to obtain the integrated fault message within the preset time interval.

[0010] Furthermore, after determining whether there is a fault in the underlying software data acquisition at the power-on time, the method further includes: using the power-on time as the starting point to start timing and generate a timing period; when the timing period is greater than the preset time interval, controlling the vehicle controller to perform a stop data acquisition action.

[0011] Furthermore, after determining whether there is a fault in the underlying software acquisition at the power-on time, the method further includes: obtaining the acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software, wherein the acquisition data attributes include the historical acquisition time and the historical data size, and the calibration signal attributes include the historical calibration signal acquisition time and the historical signal size; determining the upload data size within the minimum time interval based on the acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software; obtaining the current data storage capacity of the hardware in the loop-on-loop test environment, and generating a preset time interval based on the current data storage capacity and the upload data size within the minimum time interval.

[0012] Furthermore, before acquiring the pre-built hardware-in-the-loop open-loop test environment, the method further includes: acquiring the pre-set pin definitions of the vehicle controller; determining a hardware-in-the-loop configuration interface list corresponding to the vehicle controller based on the pin definitions, and determining hardware-in-the-loop connection relationships based on the hardware-in-the-loop configuration interface list; acquiring the vehicle environment corresponding to the vehicle controller, and building a vehicle model based on the vehicle environment; acquiring multiple calibration signals to be calibrated, and building a vehicle power-on / off calibration environment in the calibration software based on the multiple calibration signals; and building the hardware-in-the-loop open-loop test environment through the hardware-in-the-loop connection relationships, the vehicle model, and the vehicle power-on / off calibration environment.

[0013] Furthermore, before obtaining the pre-set priority order of fault types, the method further includes: obtaining historical fault test data of the whole vehicle and market fault repair data of the corresponding model of the whole vehicle, wherein the historical fault test data includes historical fault types and historical test fault counts, and the market fault repair data includes vehicle repair fault types and fault counts; based on the historical fault test data and the market fault repair data, performing statistical analysis on the fault counts of each fault type to obtain the total fault counts corresponding to each fault type; and generating a priority order of fault types according to the total fault counts corresponding to each fault type in descending order.

[0014] This specification provides one or more embodiments of a low-level software fault analysis device for a vehicle controller, including:

[0015] At least one processor; and,

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to:

[0018] A pre-built hardware-in-the-loop open-loop test environment is acquired to facilitate communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller under a trigger command, determining the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment. When the vehicle controller and the hardware-in-the-loop open-loop test environment are in normal communication status, the vehicle controller is controlled to enter a sleep state, and within a preset time interval, the key switch of the vehicle controller is controlled to be in the on state to determine the power-on time. Through the vehicle controller, it is determined whether there is a fault collected by the underlying software at the power-on time. If the fault exists, multiple fault messages corresponding to the fault within the preset time interval are acquired, wherein the fault message includes a fault identifier and a fault semaphore. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis based on the integrated fault message and determine the fault information, wherein the fault information includes fault time information, fault signal information, and fault type information.

[0019] This specification provides one or more embodiments of a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0020] A pre-built hardware-in-the-loop open-loop test environment is acquired to facilitate communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller under a trigger command, determining the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment. When the vehicle controller and the hardware-in-the-loop open-loop test environment are in normal communication status, the vehicle controller is controlled to enter a sleep state, and within a preset time interval, the key switch of the vehicle controller is controlled to be in the on state to determine the power-on time. Through the vehicle controller, it is determined whether there is a fault collected by the underlying software at the power-on time. If the fault exists, multiple fault messages corresponding to the fault within the preset time interval are acquired, wherein the fault message includes a fault identifier and a fault semaphore. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis based on the integrated fault message and determine the fault information, wherein the fault information includes fault time information, fault signal information, and fault type information.

[0021] The above-mentioned at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: Through the above technical solution, communication verification is performed on the hardware-in-the-loop open-loop test environment and the vehicle controller, the communication status is determined to be normal, and the vehicle controller is controlled to be in sleep mode before power-on operation. Under the condition that the VCU communication is normal, by controlling the vehicle controller to be in sleep mode and controlling the key switch of the vehicle controller to be in the open state, the power-on and power-off process from VCU power-off to sleep mode until power-on again is simulated, providing a simulated state scenario for subsequent steps; the faults collected by the underlying software at the time of power-on are integrated to generate an integrated fault message in the power-on and power-off process from VCU power-off to sleep mode until power-on again. After the fault data is integrated, it is sent to the CAN bus, realizing the collection of fault data in the power-on and power-off process from VCU power-off to sleep mode until power-on again, ensuring the comprehensiveness of fault data, and improving the comprehensiveness and accuracy of fault analysis. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0023] Figure 1 A flowchart illustrating a method for analyzing the underlying software faults of a vehicle controller, as provided in an embodiment of this specification.

[0024] Figure 2 A flowchart illustrating another method for analyzing the underlying software faults of a vehicle controller provided in an embodiment of this specification;

[0025] Figure 3 This is a schematic diagram of the structure of a low-level software fault analysis device for a vehicle controller provided in an embodiment of this specification. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0027] With economic and social development and the continuous improvement of living standards, the number of vehicles on the road has been increasing year by year. In recent years, the growing awareness of environmental protection has further promoted the development of new energy vehicles. The Vehicle Control Unit (VCU), as one of the three core electronic control systems of new energy vehicles, directly affects the safety of the entire vehicle if damaged. Therefore, during the development of the VCU, it is necessary to verify the VCU under real-vehicle fault conditions to ensure that the VCU meets the design requirements.

[0028] Currently, to verify the actual vehicle fault status of the VCU, a Hardware-in-the-Loop (HIL) test system is typically used for VCU fault testing. However, during actual R&D, it was discovered that during high-voltage power-on / off debugging in a HIL test environment, some underlying software automatically stops data recording during VCU power-down, such as the INCA calibration software. Therefore, fault data from the VCU's power-down to sleep and then power-on process cannot be collected. In other words, when the VCU application layer software is debugged under high voltage power-on / off conditions in a HIL test system, there is a drawback: underlying faults cannot be collected by the INCA calibration software, resulting in incomplete fault data and affecting the effectiveness of fault analysis.

[0029] This specification provides a method for analyzing the underlying software faults of a vehicle controller. It should be noted that the execution entity in this specification can be a server or any device with data processing capabilities. Figure 1 This is a flowchart illustrating a method for analyzing the underlying software faults of a vehicle controller, as provided in an embodiment of this specification. Figure 1 As shown, the main steps include the following:

[0030] Step S101: Obtain the pre-built hardware-in-the-loop open-loop test environment so that communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller can be performed under the running trigger command, and the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment can be determined.

[0031] Before obtaining the pre-built hardware-in-the-loop open-loop test environment, the method further includes: obtaining the pre-set pin definitions of the vehicle controller; determining the hardware-in-the-loop configuration interface list corresponding to the vehicle controller based on the pin definitions, and determining the hardware-in-the-loop connection relationship based on the hardware-in-the-loop configuration interface list; obtaining the vehicle environment corresponding to the vehicle controller, and building a vehicle model based on the vehicle environment; obtaining multiple calibration signals to be calibrated, and building a vehicle power-on / off calibration environment in the calibration software based on the multiple calibration signals; and building the hardware-in-the-loop open-loop test environment through the hardware-in-the-loop connection relationship, the vehicle model, and the vehicle power-on / off calibration environment.

[0032] In one embodiment of this specification, the pin definitions of the pre-set vehicle controller are obtained; based on the pin definitions, a hardware-in-the-loop configuration interface list matching the vehicle controller is compiled, i.e., the HIL configuration IO list; based on the hardware-in-the-loop configuration interface list, the hardware-in-the-loop connection relationship is determined; the HIL and controller connection harness and load box are fabricated, and the wiring is performed according to the HIL configuration IO to determine the hardware-in-the-loop connection relationship; and the IO pins of the VCU are configured using Configuration Desk software.

[0033] The process involves acquiring the vehicle environment corresponding to the vehicle controller, building a vehicle model using Simulink based on this environment, and compiling it to generate an SDF file. This SDF file stores engineering information as a database file, including configuration files for various components within the vehicle. Multiple calibration signals to be calibrated are acquired. These calibration signals include various signal types such as voltage, current, speed, and displacement. Based on these multiple calibration signals, a vehicle power-on / off calibration environment is built in the calibration software, configuring the signals to be calibrated. An open-loop hardware-in-the-loop test environment is then built using the hardware-in-the-loop connections, the vehicle model, and the vehicle power-on / off calibration environment. Furthermore, to facilitate user testing, the ControlDesk software interface is configured, and key vehicle power-on / off parameters and CAN data monitoring interfaces are displayed within the ControlDesk software interface.

[0034] Under the trigger command, communication verification is performed between the hardware-in-the-loop open-loop test environment and the vehicle controller to determine the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment. Specifically, this includes: setting the key switch to the open state in the hardware-in-the-loop open-loop test environment to simulate the vehicle's operating state; collecting calibration signals collected by calibration software within a first preset time period in the vehicle's operating state; and determining whether the calibration software is in a normal acquisition state based on the calibration signals and the key switch state. If the calibration software is in a normal acquisition state, the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment is determined to be a normal communication state.

[0035] In one embodiment of this specification, a vehicle power-on / off environment built in INCA is run. In the ControlDesk interface, the key switch state is set to the ON state to simulate the vehicle's operating state as the power-on state, i.e., the T15 key switch is set to ON, and the CAN data monitoring interface starts recording. If the calibration signal of the T15 key switch being closed is normally collected in the INCA interface within a first preset time period, it indicates that the VCU communication is normal. It should be noted that the calibration signal of the key switch being closed here is a switch signal. If the switch signal collected by the INCA interface is consistent with the T15 key switch being open, it indicates that the communication between the vehicle controller and the hardware in the loop-in / loop-out test environment is normal.

[0036] Before acquiring the calibration CAN signal collected by the calibration software within the first preset time period under the vehicle's operating state, the method further includes: acquiring multiple historical setting times for setting the key switch state, and the historical signal reception time of the historical calibration switch signal corresponding to each historical setting time; determining multiple signal reception periods based on each historical setting time and the historical signal reception time corresponding to each historical setting time, wherein the signal reception period is the reception duration; and determining the specified signal reception period with the longest reception duration among the multiple signal reception periods as the first preset time period.

[0037] In one embodiment of this specification, a first preset time period needs to be preset, typically 10 seconds. This can be calculated as follows: First, acquire multiple historical setting times for the key switch state, i.e., the times when the key switch change is triggered (e.g., the time when the user clicks the switch button on the software interface). Then, acquire the historical signal reception time of the historical calibration switch signal corresponding to each historical setting time. Here, the historical signal reception time refers to the historical signal reception time when the switch signal is collected on the INCA interface. The time interval between each historical setting time and its corresponding historical signal reception time is used as the signal reception period, where the signal reception period is the reception duration. This yields multiple signal reception periods corresponding to different historical setting times. The signal reception period with the longest reception duration among these multiple signal reception periods is then selected as the first preset time period. By setting the first preset time period to the signal reception period with the longest reception duration, the comprehensiveness of the acquired switch calibration signals is ensured, avoiding communication status abnormalities caused by unsuccessful transmission of switch calibration signals due to insufficient duration settings, thus improving the accuracy of communication status determination.

[0038] Step S102: When the vehicle controller and the hardware are in normal communication state in the loop-on / loop-off test environment, the vehicle controller is controlled to enter sleep state, and the key switch of the vehicle controller is controlled to enter the on state within a preset time interval to determine the power-on time.

[0039] In one embodiment of this specification, under normal communication conditions between the vehicle controller and the hardware in a loop-in / open-loop test environment, the T15 key switch is set to OFF in the ControlDesk interface, i.e., the key is off, waiting for the VCU to enter sleep mode. Whether sleep mode has been entered can be determined by abnormal data display on the INCA interface (e.g., "-") or by the CAN data monitoring interface in the ControlDesk software stopping refresh. When the vehicle controller is not in sleep mode, the T15 key switch is set to ON again in the ControlDesk interface, controlling the vehicle controller's key switch to the on state to determine the power-on time. This power-on time is the time when the key switch is set to the on state. Through the above technical solution, while ensuring normal VCU communication, by controlling the vehicle controller to sleep mode and controlling the vehicle controller's key switch to the on state, the power-on and power-off process from VCU power-off to sleep mode and then to power-on again is simulated, providing a simulated state scenario for subsequent steps.

[0040] Step S103: The vehicle controller determines whether there is a fault collected by the underlying software at the time of power-on. If a fault exists, multiple fault messages corresponding to the fault are obtained within a preset time interval.

[0041] In one embodiment of this specification, at the instant of power-on (i.e., the power-on moment), the VCU collects fault data from the DSM fault diagnosis module in the underlying software. This DSM module is used to collect fault data. At the moment of power-on, it determines whether a fault collected by the underlying software exists. If a fault is detected, it acquires multiple fault messages corresponding to the fault within a preset time interval. These fault messages include a fault identifier and a fault semaphore. It should be noted that the preset time interval is related to the time interval for stopping data recording, which in turn is related to the data storage capacity corresponding to the CAN data monitoring interface.

[0042] Step S104: Based on the fault identifiers and fault semaphores of multiple fault messages, integrate the multiple fault messages within a preset time interval to generate an integrated fault message within the preset time interval.

[0043] Based on the fault identifiers and fault semaphores of the multiple fault messages, the multiple fault messages within a preset time interval are integrated to generate an integrated fault message within the preset time interval. Specifically, this includes: determining the fault type corresponding to each fault message based on its fault identifier and a pre-written corresponding file, wherein the fault type is used to identify the vehicle component experiencing the fault; grouping at least one specified fault message belonging to the same type based on the fault type corresponding to each fault message to obtain multiple type message groups; and grouping the fault semaphores corresponding to the same type of signal based on the fault semaphore of each specified fault message in each type message group to generate multiple signal message subgroups, wherein the fault semaphore includes at least... A fault signal of a certain type, including any one or more of voltage signals, current signals, speed signals, displacement signals, and switching signals; obtaining the priority order of fault signals corresponding to each fault type in a pre-set manner, and determining the fault type corresponding to each subgroup of the signal message, so as to sequentially combine the fault signal quantities of multiple subgroups of the signal message according to the preset priority order of fault signals corresponding to each fault type, to obtain a combined fault signal sub-message corresponding to each fault type; obtaining the preset priority order of fault types, and based on the priority order of fault types and the combined fault signal sub-message corresponding to each fault type, sequentially combining the multiple types of message groups to obtain the integrated fault message within the preset time interval.

[0044] In one embodiment of this specification, a fault identifier, i.e., a fault ID, corresponding to the CAN fault message is predefined, and the signal type of the semaphore corresponding to the CAN fault message is defined, such as a voltage signal, a current signal, etc. Fault signals are collected through a DSM fault diagnosis module. Generally, multiple DSM fault diagnosis modules are set up, and different fault diagnosis modules collect different fault types, i.e., multiple fault messages are collected. The fault signal here is the input of the DSM fault diagnosis module. The fault signal issued by the DSM is connected to the corresponding output variable, and this output variable is used as the input of the CAN Pack function module. It is connected to the input terminal of the CAN Pack function module according to the corresponding signal name. The output of the CAN Pack function module is a message in CAN Msg format, where the signal name can be the signal type.

[0045] In one embodiment of this specification, based on the fault identifier of each fault message collected by the DSM fault diagnosis module and a pre-written corresponding file, the fault type corresponding to each fault message is determined. The fault type is used to identify the vehicle component that has malfunctioned in the vehicle. The corresponding file here is the DBC file corresponding to the CAN message. CAN messages are imported via RTICANMM. The DBC file here is in CAN bus diagnostic file format. Fault identifiers are pre-set for fault information, establishing a correspondence between fault types and fault identifiers. This correspondence is used as the corresponding file to determine the fault type corresponding to each fault message in subsequent processes. At least one specified fault message belonging to the same type is grouped to obtain multiple type message groups. Based on the fault signal quantity of each specified fault message in each type message group, the fault signal quantities corresponding to the same type of signal are grouped to generate multiple signal message subgroups. The fault signal quantities include at least one type of fault signal, and the types of fault signals include, but are not limited to, voltage signals, current signals, speed signals, displacement signals, and switching signals.

[0046] The system retrieves the pre-defined priority order of fault signals for each fault type. This priority order identifies the signal type that can directly and quickly display the fault under this fault type. For example, for engine type faults, the speed signal is the first priority signal. The earlier the priority order, the more accurately the fault signal reflects this type of fault. The system determines the fault type corresponding to each signal message subgroup. Following the pre-defined priority order of fault signals for each fault type, it sequentially combines the fault signal quantities of multiple signal message subgroups to obtain a combined fault signal sub-message for each fault type. The system then retrieves the pre-defined priority order of fault types. Based on this priority order and the combined fault signal sub-messages for each fault type, it sequentially combines multiple type message groups to obtain an integrated fault message within a pre-defined time interval. The integrated fault message is formatted as a CAN Msg, which is the output of the CAN Pack function module.

[0047] Before obtaining the pre-set priority order of fault types, the method further includes: obtaining historical fault test data of the whole vehicle and market fault repair data of the corresponding model of the whole vehicle, wherein the historical fault test data includes historical fault types and historical test fault counts, and the market fault repair data includes vehicle repair fault types and fault counts; based on the historical fault test data and the market fault repair data, performing statistical analysis on the fault counts of each fault type to obtain the total fault counts corresponding to each fault type; and generating a priority order of fault types according to the total fault counts corresponding to each fault type in descending order.

[0048] In one embodiment of this specification, a priority order for different types of faults is pre-set, which can be determined based on the likelihood of vehicle faults occurring. Historical fault test data for the entire vehicle and market fault repair data for the same vehicle model are acquired. The historical fault test data includes historical fault types and the number of faults tested in history, while the market fault repair data includes vehicle repair fault types and the number of faults repaired. Based on the historical fault test data and the market fault repair data, the number of faults for each fault type is statistically analyzed to obtain the total number of faults corresponding to each fault type. A priority order for the fault types is generated according to the total number of faults corresponding to each fault type, from largest to smallest.

[0049] Step S105: The integrated fault message is sent to the CAN bus so that fault analysis can be performed based on the integrated fault message to determine the fault information.

[0050] In one embodiment of this specification, a CAN Msg message is connected to the input of the CAN Write function module to send an integrated fault message to the CAN bus, thereby realizing the function of writing fault CAN messages on the CAN bus. The recorded integrated fault message data is saved in *.asc format, which can be opened using CAN analysis software to perform fault analysis on the fault data sent from the VCU to the CAN bus, inferring fault information such as the start time and duration of the underlying fault. This fault information includes fault time information, fault signal information, and fault type information.

[0051] After determining whether there is a fault in the underlying software acquisition at the power-on moment, the method further includes: taking the power-on moment as the starting point to start timing and generate a timing period; when the timing period is greater than the preset time interval, controlling the vehicle controller to perform a stop acquisition action.

[0052] After determining whether there is a fault in the underlying software acquisition at the power-on moment, the method further includes: obtaining the acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software, wherein the acquisition data attributes include the historical acquisition time and the historical data size, and the calibration signal attributes include the historical calibration signal acquisition time and the historical signal size; determining the upload data size within the minimum time interval by using the acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software; obtaining the current data storage capacity of the hardware in the loop-on-loop test environment, and generating a preset time interval based on the current data storage capacity and the upload data size within the minimum time interval.

[0053] Because the data storage capacity of the CAN data monitoring interface is limited, data overwriting can easily occur as data is continuously recorded, making it impossible to collect all recorded fault data. Therefore, data acquisition needs to be stopped within the timing period. The starting point of this timing period is the power-on moment, and the value of the timing period is related to the data storage capacity. First, the acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software are obtained. The acquisition data attributes include the historical data size, and the calibration signal attributes include the historical calibration signal acquisition time and the historical signal size. It should be noted that the historical acquisition time of the historical acquisition data of the underlying software refers to the moment when the data was acquired, while the historical calibration signal acquisition time refers to the moment when the calibration software obtains the acquired data and displays it on the interface.

[0054] By analyzing the historical data attributes of the underlying software and the calibration signal attributes of the calibration software, the maximum upload data size within a minimum time interval is determined. This minimum time interval can be one second, representing the amount of data that can be uploaded per second. The current data storage capacity of the hardware in the open-loop test environment is then obtained. Based on this current data storage capacity and the maximum upload data size within the minimum time interval, a preset time interval is generated. This preset time interval refers to the transmission time required to fully utilize the current data storage capacity while transmitting data every second; therefore, the preset time interval should be less than this transmission time. In practical experience, this preset time interval is typically four seconds.

[0055] Through the above technical solution, communication verification is performed on the hardware-in-the-loop open-loop test environment and the vehicle controller. The communication status is determined to be normal. The vehicle controller is then put into sleep mode before power-on. While ensuring normal VCU communication, operations such as putting the vehicle controller into sleep mode and turning its key switch on simulate the power-on / off process from VCU power-down to sleep mode and then back to power-on, providing a simulated scenario for subsequent steps. Faults collected by the underlying software at power-on are integrated to generate an integrated fault message for the power-on / off process from VCU power-down to sleep mode and then back to power-on. This integrated fault data is then sent to the CAN bus, achieving fault data collection throughout the power-on / off process from VCU power-down to sleep mode and then back to power-on, ensuring the comprehensiveness of the fault data and improving the comprehensiveness and accuracy of fault analysis.

[0056] Figure 2 A flowchart illustrating another method for analyzing the underlying software faults of a vehicle controller provided in the embodiments of this specification is shown below. Figure 2As shown, the vehicle HIL test involves high-voltage power-on / off debugging. The control process is as follows: Run the vehicle power-on / off environment built in INCA; in the ControlDesk interface, set the T15 key switch to ON and start recording the CAN data monitoring interface; if the INCA interface can normally collect the T15 key switch closed state within 10 seconds, it indicates normal VCU communication; in the ControlDesk interface, set the T15 key switch to OFF; wait for the VCU to enter sleep mode. This can be determined by the INCA interface displaying abnormally as ("-") or the ControlDesk CAN data monitoring interface stopping refreshing. Enter sleep mode; in the ControlDesk interface, set the T15 key switch to ON again; at the moment of power-on, the VCU collects the faults sent by the underlying DSM module to determine if a fault has been issued. If a fault has been issued, the fault data is sent to the CAN bus periodically at 10ms (can be modified). If there is no fault, the VCU does not process it; after 4s, click the stop recording button on the CAN data monitoring interface, and ControlDesk stops data recording; the recorded data is saved in *.asc format, which can be opened and analyzed using CAN analysis software to deduce the start time, duration, and other information of the underlying fault.

[0057] It should be noted that the preparation work for the test process in this embodiment is as follows: Based on the pin definitions of the VCU controller, write a matching HIL configuration IO list; create the HIL and controller connection harness and load box, and connect them according to the configuration table; configure the VCU IO pins using ConfigurationDesk software; write the DBC file corresponding to the CAN message, and import the CAN message through RTICANMM; build a complete vehicle model using Simulink and compile to generate an SDF file; configure the ControlDesk software interface, and call up the key parameters for vehicle power-on / off and the CAN data monitoring interface; build the vehicle power-on / off calibration environment using INCA calibration software; perform HIL open-loop testing; in addition, write the VCU fault handling program, define the fault identifier corresponding to the CAN fault message (i.e., fault ID), and define the signal type of the semaphore corresponding to the CAN fault message; define the output variable corresponding to the fault connection issued by the DSM; configure the CAN Pack function module to take the output variable corresponding to the fault connection issued by the DSM as the input of the CAN Pack function module, connect it to the input terminal of the CAN Pack function module according to the corresponding signal name, and the output of the CAN Pack function module is a CAN Msg message; CAN The Write function module is configured to connect CAN Msg messages to the input of the CAN Write function module, thereby enabling the writing of fault CAN messages onto the CAN bus.

[0058] This specification also provides an embodiment of a low-level software fault analysis device for a vehicle controller, such as... Figure 3 As shown, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0059] A pre-built hardware-in-the-loop (HIL) open-loop test environment is acquired to facilitate communication verification between the HIL open-loop test environment and the vehicle controller under a trigger command, determining the communication status between the vehicle controller and the HIL open-loop test environment. When the vehicle controller and the HIL open-loop test environment are in normal communication status, the vehicle controller is controlled to enter a sleep state, and the key switch of the vehicle controller is controlled to be in the open state within a preset time interval to determine the power-on time. Through the vehicle controller, it is determined whether there is a fault collected by the underlying software at the power-on time. If the fault exists, multiple fault messages corresponding to the fault within the preset time interval are acquired, where each fault message includes a fault identifier and a fault semaphore. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis based on the integrated fault message to determine the fault information, where the fault information includes fault time information, fault signal information, and fault type information.

[0060] This specification also provides a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows:

[0061] A pre-built hardware-in-the-loop (HIL) open-loop test environment is acquired to facilitate communication verification between the HIL open-loop test environment and the vehicle controller under a trigger command, determining the communication status between the vehicle controller and the HIL open-loop test environment. When the vehicle controller and the HIL open-loop test environment are in normal communication status, the vehicle controller is controlled to enter a sleep state, and the key switch of the vehicle controller is controlled to be in the open state within a preset time interval to determine the power-on time. Through the vehicle controller, it is determined whether there is a fault collected by the underlying software at the power-on time. If the fault exists, multiple fault messages corresponding to the fault within the preset time interval are acquired, where each fault message includes a fault identifier and a fault semaphore. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis based on the integrated fault message to determine the fault information, where the fault information includes fault time information, fault signal information, and fault type information.

[0062] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0063] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0064] The devices, media, and methods provided in the embodiments of this specification are one-to-one correspondences. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0065] Those skilled in the art will understand that embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0067] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0068] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0069] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0070] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0071] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0072] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0073] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for analyzing low-level software faults in a vehicle controller, characterized in that, The method includes: A pre-built hardware-in-the-loop open-loop test environment is obtained so that communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller can be performed under the running trigger command, and the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment can be determined. When the vehicle controller and the hardware are in normal communication state in the loop-in / open-loop test environment, the vehicle controller is controlled to enter sleep state, and the key switch of the vehicle controller is controlled to be in the open state within a preset time interval to determine the power-on time. The vehicle controller determines whether there is a fault collected by the underlying software at the time of power-on. If the fault exists, it acquires multiple fault messages corresponding to the fault within the preset time interval. The fault message includes a fault identifier and a fault signal. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis and determination of fault information based on the integrated fault message. The fault information includes fault time information, fault signal information, and fault type information.

2. The method for analyzing the underlying software faults of a vehicle controller according to claim 1, characterized in that, Under the trigger command, communication verification is performed between the hardware-in-the-loop open-loop test environment and the vehicle controller to determine the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment, specifically including: In the hardware-in-loop open-loop test environment, the key switch is set to the on state to simulate the vehicle's operating state. Under the vehicle's operating state, calibration signals collected by calibration software within a first preset time period are acquired; Based on the calibration signal and the key switch status, it is determined whether the calibration software is in a normal acquisition state. When the calibration software is in a normal acquisition state, it is determined that the communication state between the vehicle controller and the hardware-in-loop open-loop test environment is a normal communication state.

3. The method for analyzing the underlying software faults of a vehicle controller according to claim 2, characterized in that, Before acquiring the calibration CAN signal collected by the calibration software within a first preset time period during the vehicle's operating state, the method further includes: Acquire multiple historical setting times of the key switch state, and the historical signal reception time of the historical calibration switch signal corresponding to each historical setting time; Based on each historical setting time and the corresponding historical signal reception time, multiple signal reception periods are determined, wherein the signal reception period is the reception duration; Among the multiple signal reception cycles, the signal reception cycle with the longest reception duration is determined as the first preset time period.

4. The method for analyzing the underlying software faults of a vehicle controller according to claim 1, characterized in that, Based on the fault identifiers and fault semaphores of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval, specifically including: Based on the fault identifier of each fault message and the pre-written corresponding file, the fault type corresponding to each fault message is determined, wherein the fault type is used to identify the vehicle component in the vehicle that has malfunctioned. Based on the fault type corresponding to each fault message, at least one specified fault message belonging to the same type is grouped to obtain multiple type message groups. Based on the fault signal quantity of each specified fault message in each type of message group, the fault signal quantities corresponding to the same type of signal are grouped to generate multiple signal message subgroups. The fault signal quantity includes at least one type of fault signal, and the type of fault signal includes any one or more of voltage signal, current signal, speed signal, displacement signal, and switch signal. Obtain the priority order of fault signals corresponding to each fault type in a preset manner, and determine the fault type corresponding to each of the signal message subgroups. Then, according to the priority order of fault signals corresponding to each fault type in a preset manner, the fault signal quantities of multiple signal message subgroups are sequentially combined to obtain the fault signal combination sub-message corresponding to each fault type. Obtain the priority order of the pre-set fault types, and based on the priority order of the fault types and the fault signal combination sub-messages corresponding to each fault type, sequentially combine the multiple type message groups to obtain the integrated fault message within the preset time interval.

5. The method for analyzing the underlying software faults of a vehicle controller according to claim 1, characterized in that, After determining whether there is a fault in the underlying software data acquisition at the time of power-on, the method further includes: The timing is started from the power-on time to generate a timing cycle. When the timing cycle is greater than the preset time interval, the vehicle controller is controlled to perform a stop data acquisition action.

6. The method for analyzing the underlying software faults of a vehicle controller according to claim 5, characterized in that, After determining whether there is a fault in the underlying software data acquisition at the time of power-on, the method further includes: The acquisition data attributes of the historical acquisition data of the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software are obtained. The acquisition data attributes include the historical acquisition time and the historical data size, and the calibration signal attributes include the historical calibration signal acquisition time and the historical signal size. The size of the uploaded data within the minimum time interval is determined by the data acquisition attributes of the historical data collected by the underlying software and the calibration signal attributes of the historical calibration signals of the calibration software. Obtain the current data storage capacity of the hardware in the open-loop test environment, and generate a preset time interval based on the current data storage capacity and the amount of data uploaded within the minimum time interval.

7. The method for analyzing the underlying software faults of a vehicle controller according to claim 1, characterized in that, Before acquiring the pre-built hardware in a loop-on-loop or open-loop test environment, the method further includes: Obtain the pre-defined pin definitions of the vehicle controller; Based on the pin definitions, a hardware-in-the-loop configuration interface list corresponding to the vehicle controller is determined, and hardware-in-the-loop connection relationships are determined based on the hardware-in-the-loop configuration interface list. Obtain the vehicle environment corresponding to the vehicle controller, and build a vehicle model based on the vehicle environment; Multiple calibration signals to be calibrated are acquired, and a vehicle power-on / off calibration environment is built in the calibration software based on the multiple calibration signals; The hardware-in-the-loop connection relationship, the vehicle model, and the vehicle power-on / off calibration environment are used to build the hardware-in-the-loop open-loop test environment.

8. The method for analyzing the underlying software faults of a vehicle controller according to claim 4, characterized in that, Before obtaining the pre-set priority order of fault types, the method further includes: Acquire historical fault test data of the whole vehicle and market fault repair data of the corresponding model of the whole vehicle, wherein the historical fault test data includes historical fault types and historical test fault counts, and the market fault repair data includes vehicle repair fault types and fault counts; Based on the historical fault test data and the market fault repair data, the number of faults for each fault type is statistically analyzed to obtain the total number of faults for each fault type. The priority order of generating fault types is determined by ranking the total number of faults corresponding to each fault type from largest to smallest.

9. A device for analyzing the underlying software faults of a vehicle controller, characterized in that, The device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed by the at least one processor, enable the at least one processor to: A pre-built hardware-in-the-loop open-loop test environment is obtained so that communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller can be performed under the running trigger command, and the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment can be determined. When the vehicle controller and the hardware are in normal communication state in the loop-in / open-loop test environment, the vehicle controller is controlled to enter sleep state, and the key switch of the vehicle controller is controlled to be in the open state within a preset time interval to determine the power-on time. The vehicle controller determines whether there is a fault collected by the underlying software at the time of power-on. If the fault exists, it acquires multiple fault messages corresponding to the fault within the preset time interval. The fault message includes a fault identifier and a fault signal. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis and determination of fault information based on the integrated fault message. The fault information includes fault time information, fault signal information, and fault type information.

10. A non-volatile computer storage medium storing computer-executable instructions, characterized in that, The computer-executable instructions are set as follows: A pre-built hardware-in-the-loop open-loop test environment is obtained so that communication verification between the hardware-in-the-loop open-loop test environment and the vehicle controller can be performed under the running trigger command, and the communication status between the vehicle controller and the hardware-in-the-loop open-loop test environment can be determined. When the vehicle controller and the hardware are in normal communication state in the loop-in / open-loop test environment, the vehicle controller is controlled to enter sleep state, and the key switch of the vehicle controller is controlled to be in the open state within a preset time interval to determine the power-on time. The vehicle controller determines whether there is a fault collected by the underlying software at the time of power-on. If the fault exists, it acquires multiple fault messages corresponding to the fault within the preset time interval. The fault message includes a fault identifier and a fault signal. Based on the fault identifier and fault semaphore of the multiple fault messages, the multiple fault messages within the preset time interval are integrated to generate an integrated fault message within the preset time interval. The integrated fault message is sent to the CAN bus to facilitate fault analysis and determination of fault information based on the integrated fault message. The fault information includes fault time information, fault signal information, and fault type information.

Images