Fault monitoring code generation method, device, medium and program product

Abstract

The application relates to the computer technical field, in particular to a fault monitoring code generation method, device, medium and program product. The method comprises the following steps: acquiring a fault monitoring strategy for monitoring vehicle faults; determining, according to a target deployment platform of the fault monitoring strategy, a first part of strategy irrelevant to the target deployment platform and a second part of strategy related to the target deployment platform in the fault monitoring strategy; acquiring a preset hierarchical rule library, the hierarchical rule library comprising platform-irrelevant layer rules and platform-related layer rules; generating first code for executing the first part of strategy based on the platform-irrelevant layer rules; generating second code for executing the second part of strategy based on the platform-related layer rules; and splicing the first code and the second code to obtain fault monitoring code for executing the fault monitoring strategy. In this way, for the fault monitoring strategy, corresponding fault monitoring code can be automatically generated according to different target deployment platforms, and the flexibility of deployment is enhanced.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a method, device, medium, and program product for generating fault monitoring codes. Background Technology

[0002] In vehicle electronic and electrical architecture, different domains (such as the powertrain domain and the autonomous driving domain) may be deployed on different hardware platforms. Fault monitoring of hardware resources (such as voltage, temperature, and current) on these different hardware platforms generally requires customized development for each platform. That is, for different hardware platforms, software engineers need to write low-level driver code for each platform and implement fault threshold judgment logic adapted to the characteristics of each domain.

[0003] Therefore, if fault monitoring functionality needs to be ported across platforms or domains, all code must be redeveloped. This makes hardware fault monitoring feature development inefficient and error-prone, and increases the cost of cross-platform and cross-domain code porting. Summary of the Invention

[0004] The purpose of this application is to provide a method, device, medium, and program product for generating fault monitoring codes.

[0005] In a first aspect of this application, a fault monitoring code generation method is provided, applied to an electronic device. The method includes: obtaining a fault monitoring strategy for monitoring vehicle faults; determining a first part of the strategy that is independent of the target deployment platform and a second part of the strategy that is related to the target deployment platform, based on the target deployment platform of the fault monitoring strategy; obtaining a preset hierarchical rule library, the hierarchical rule library including platform-independent layer rules and platform-related layer rules; generating a first code for executing the first part of the strategy based on the platform-independent layer rules; generating a second code for executing the second part of the strategy based on the platform-related layer rules; and concatenating the first code and the second code to obtain fault monitoring code for executing the fault monitoring strategy.

[0006] In this embodiment, by dividing the fault monitoring strategy into two parts—one independent of the target deployment platform and the other relevant—and then using a layered rule base to generate corresponding code for each part before concatenating them, the development efficiency and reusability of the fault monitoring code are improved. On one hand, for different vehicle fault monitoring needs, as long as there is a platform-independent fault monitoring strategy, the first code can be directly reused without rewriting it, reducing development workload. On the other hand, when the fault monitoring code needs to be deployed to different platforms, only the second code needs to be adjusted according to the platform-related layer rules, avoiding a complete rewrite of the code and significantly reducing cross-platform portability costs. Simultaneously, the use of a layered rule base makes the code structure clearer, easier to maintain and manage, and improves the reliability and stability of the code.

[0007] In one possible implementation of the first aspect, generating first code for executing the first part of the strategy based on platform-independent layer rules includes: determining multiple first objective functions for implementing the first part of the strategy based on platform-independent layer rules; and copying the code corresponding to each first objective function from the hierarchical rule base to obtain the first code.

[0008] In one possible implementation of the first aspect, second code for executing the second part of the strategy is generated based on platform-related layer rules, including: determining multiple second objective functions for implementing the second part of the strategy based on platform-related layer rules; obtaining the code template of each second objective function from the hierarchical rule base; and filling the hardware parameter information of the target deployment platform related to the second part of the strategy into the code template of each second objective function to obtain the second code.

[0009] In one possible implementation of the first aspect, the method further includes: performing a compatibility check on the fault monitoring strategy; generating fault monitoring code for executing the fault monitoring strategy when the fault monitoring strategy is compatible with the target deployment platform; and outputting a first exception message when the fault monitoring strategy is incompatible with the target deployment platform, the first exception message indicating the part of the fault monitoring strategy that is incompatible with the target deployment platform, and / or the content of the fault monitoring strategy that needs to be adjusted.

[0010] In one possible implementation of the first aspect, the fault monitoring strategy includes a monitoring object, a monitoring method corresponding to the monitoring object, fault triggering conditions, and fault handling actions. The fault monitoring strategy undergoes compatibility verification, including: verifying whether the monitoring method of the monitoring object is supported by the target deployment platform; determining the computing power of the fault monitoring strategy based on the monitoring object, monitoring method, fault triggering conditions, and fault handling actions; verifying whether the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform; if the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform, and the monitoring method of the monitoring object is supported by the target deployment platform, then the fault monitoring strategy is compatible with the target deployment platform; otherwise, the fault monitoring strategy is incompatible with the target deployment platform.

[0011] In one possible implementation of the first aspect, the method further includes: adjusting the code format of the fault monitoring code so that the adjusted fault monitoring code conforms to the compilation specifications of the target deployment platform.

[0012] In one possible implementation of the first aspect, the method further includes: verifying the fault monitoring code based on preset test cases; and outputting a second exception message when the fault monitoring code fails the test cases, the second exception message indicating that the test cases in the fault monitoring code are not applicable.

[0013] In a second aspect of this application, a readable storage medium is provided, which includes one or more programs that, when executed on an electronic device, cause the electronic device to implement the first aspect and any possible implementation of the first aspect.

[0014] In a third aspect of this application, a computer program product is provided that, when run on an electronic device, enables the electronic device to implement the first aspect and any possible implementation of the first aspect.

[0015] In a fourth aspect of this application, an electronic device is provided, comprising: one or more memories for storing one or more programs; and one or more processors for executing the one or more programs to cause the electronic device to implement the first aspect and any possible implementation of the first aspect.

[0016] The beneficial effects of the second to fourth aspects mentioned above can be found in the beneficial effects of the first aspect, and will not be repeated here. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings are described below.

[0018] Figure 1 According to some embodiments of this application, a flowchart of a fault monitoring code generation method is shown;

[0019] Figure 2 According to some embodiments of this application, a flowchart of a method for verifying the compatibility of fault monitoring strategies is shown;

[0020] Figure 3 According to some embodiments of this application, a schematic diagram of the structure of an electronic device is shown;

[0021] Figure 4 According to some embodiments of this application, a block diagram of a system-on-a-chip is shown. Detailed Implementation

[0022] The illustrative embodiments of this application include, but are not limited to, a fault monitoring code generation method, device, medium, and program product.

[0023] In the automotive industry, a "domain" is a collection of electronic and electrical architectures that control a major functional module of a vehicle. Each domain is controlled uniformly by a domain controller. The electronic and electrical architecture of a vehicle is typically divided into five domains: powertrain domain, chassis domain, body domain, cockpit domain, and autonomous driving domain. These different domains may be deployed on different hardware platforms. For example, the powertrain domain may be deployed on the Infineon™ platform, and the autonomous driving domain may be deployed on the Mobileye™ platform. Currently, fault monitoring of hardware resources (such as voltage, temperature, and current) on these different hardware platforms generally requires customized development based on the platform.

[0024] For different automotive domain platforms, the necessary fault monitoring functionalities need to be manually written separately (e.g., code to read temperature sensors is needed for chip temperature monitoring), as well as fault threshold judgment logic adapted to domain characteristics (e.g., determining if the voltage is greater than 9 volts; if it is, a fault is considered to have occurred). For monitored faults, corresponding actions are typically required, such as reporting fault codes. These actions also require manually written interactive code conforming to the automotive standard diagnostic protocol (UDS 14229) (e.g., code implementing fault code reporting). Finally, human experience is needed to manually bind monitored faults with corresponding actions (e.g., when the voltage in the powertrain domain is less than 9 volts, calling the diagnostic protocol interface to report fault codes).

[0025] Therefore, the current development model for automotive hardware fault monitoring has several shortcomings. First, development efficiency is extremely low and error-prone. Due to the lack of a unified rule base, fault monitoring code must be developed separately for each domain or platform. If multiple domains collaborate, the error rate is even higher. Second, cross-platform or cross-domain portability is costly. For monitoring the same fault, cross-domain or cross-platform deployment requires a complete rewrite of all code. Third, real-time hardware parameter adaptation is prone to failure. Different automotive domains have significantly different hardware parameter requirements (e.g., a powertrain domain platform requires a 10ms sampling period to capture transient voltage anomalies, while an intelligent driving domain platform can relax this to a 50ms sampling period for voltage monitoring). Existing technologies rely on manual memorization and code adjustments for adaptation, which easily leads to mismatches such as "using a 10ms sampling period from the powertrain domain for an intelligent driving domain platform, resulting in resource waste" or "using a 50ms period for the powertrain domain, causing missed transient faults," ultimately causing hardware fault monitoring to fail.

[0026] To address the aforementioned issues, this application provides a fault monitoring code generation method applied to electronic devices. The method includes: acquiring a fault monitoring strategy for monitoring vehicle faults; determining a first part of the strategy that is independent of the target deployment platform and a second part of the strategy that is related to the target deployment platform, based on the target deployment platform of the fault monitoring strategy; acquiring a preset hierarchical rule base, which includes platform-independent layer rules and platform-related layer rules; generating first code for executing the first part of the strategy based on the platform-independent layer rules; generating second code for executing the second part of the strategy based on the platform-related layer rules; and concatenating the first code and the second code to obtain fault monitoring code for executing the fault monitoring strategy.

[0027] The fault monitoring code generation method provided in this application improves the development efficiency and reusability of fault monitoring code by dividing the fault monitoring strategy into two parts: one independent of the target deployment platform and the other relevant. These parts are then generated using a layered rule base and concatenated. On one hand, for different vehicle fault monitoring needs, as long as the platform-independent fault monitoring strategy exists, the first part of the code can be directly reused without rewriting it, reducing development workload. On the other hand, when the fault monitoring code needs to be deployed to different platforms, only the second part of the code needs to be adjusted according to the relevant layer rules of the platform, avoiding a complete rewrite and significantly reducing cross-platform portability costs. Simultaneously, the use of a layered rule base makes the code structure clearer, easier to maintain and manage, and improves the reliability and stability of the code.

[0028] It is understood that this application does not limit the type of electronic device, which may include, but is not limited to, various in-vehicle electronic devices, mobile terminals that work in conjunction with vehicles, such as in-vehicle tablets, smart rearview mirrors or smart mobile devices with vehicle connectivity, mobile phones, wearable devices (such as smartwatches), tablet computers, desktop, laptop, handheld computers, laptops, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) / virtual reality (VR) devices, etc. The embodiments of this application do not impose any restrictions on the specific type of electronic device.

[0029] To more clearly illustrate the technical solutions provided in the embodiments of this application, the technical solutions of this application will be described below in conjunction with the accompanying drawings.

[0030] Figure 1An embodiment of this application illustrates a schematic flowchart of a fault monitoring code generation method. It is understood that the execution entity for each step of the fault monitoring code generation method in this application is an electronic device. For simplicity, the execution entity for each step will not be described again in the following description of the method flow. Figure 1 As shown, the fault monitoring code generation method may include the following steps S101 to S106:

[0031] S101: Obtain the fault monitoring policy used to monitor vehicle faults.

[0032] In this embodiment, the fault monitoring strategy specifies how to monitor, judge, and subsequently handle various possible fault conditions of the vehicle. For example, it may include setting monitoring thresholds for hardware resources (such as voltage, temperature, and current) of different vehicle components (such as the engine, battery, and sensors), and specific measures to be taken when these monitored values ​​exceed normal ranges, such as triggering alarms, recording fault information, and reporting fault codes.

[0033] For example, a fault monitoring strategy could be to "detect the power supply voltage in the vehicle's power domain with a sampling period of 10ms, and trigger the reporting of the $19 fault code of the vehicle's standard diagnostic protocol when the voltage is less than 9 volts".

[0034] It is understandable that only by adopting a reasonable and effective fault monitoring strategy can fault monitoring codes that meet actual needs be generated, so as to achieve accurate and timely monitoring and handling of vehicle faults.

[0035] S102: Based on the target deployment platform of the fault monitoring strategy, determine a first part of the strategy that is unrelated to the target deployment platform and a second part of the strategy that is related to the target deployment platform in the fault monitoring strategy.

[0036] It is understood that different automotive domains (such as powertrain domain, chassis domain, body domain, cockpit domain, and autonomous driving domain) may be deployed on different hardware platforms. This application's embodiment, based on a target deployment platform for fault monitoring strategies, can classify fault monitoring strategies, distinguishing two different strategy components from the overall strategy.

[0037] The first part of the strategy, which is independent of the target deployment platform, refers to strategy content that remains relatively stable and universal across different target deployment platforms. For example, certain basic logic regarding fault diagnosis (such as determining whether the voltage value is greater than a certain threshold) does not depend on the hardware parameters or architectural characteristics of a specific platform.

[0038] The second part of the strategy, related to the target deployment platform, is specific to its characteristics. This part considers the platform's hardware resource characteristics (such as specific CPU architecture, Analog-to-Digital Converter (ADC) sampling channel allocation rules, etc.) and computing power characteristics (single-core computing power, core count configuration, etc.). For example, it might address the ADC sampling cycle requirements of a particular platform, or determine the frequency and complexity of fault monitoring based on the platform's computing power. This distinction lays the foundation for generating corresponding code based on different rules, enabling more accurate generation of fault monitoring code suitable for the target deployment platform.

[0039] S103: Obtain the preset hierarchical rule base, which includes platform-independent layer rules and platform-related layer rules.

[0040] In this embodiment, the electronic device can obtain a pre-defined hierarchical rule base from its internal storage or related configuration files. This hierarchical rule base includes platform-independent layer rules and platform-dependent layer rules.

[0041] The platform-independent layer rules encompass a series of general programming logics, algorithms, and instruction specifications. These rules are independent of the hardware characteristics of a specific target deployment platform. For example, some general fault diagnosis algorithms and data processing logic can maintain consistent execution methods and effects across various automotive hardware platforms.

[0042] Platform-specific rules are tailored to different target deployment platforms. These rules incorporate the hardware resource characteristics of a specific platform. For example, platform-specific rules can record: whether the ADC channel of a certain core on platform A is occupied by other modules, whether a certain sampling period is supported, and which specific channels should be used to collect data from different sensors, etc. This information is used to determine whether a fault monitoring strategy can be deployed on platform A, and if so, what implementation method should be followed to implement the fault monitoring strategy.

[0043] This application embodiment, through this layered rule base design, provides a basis for subsequently generating corresponding code based on the strategies of different parts.

[0044] S104: Generate the first code for executing the first part of the strategy based on the platform-independent layer rules.

[0045] In this embodiment, the electronic device divides the fault monitoring strategy into parts related to the target deployment platform and parts unrelated to the target deployment platform, generating code for each. First, based on the obtained platform-independent layer rules, the previously determined first part of the strategy is converted into code. The first part of the strategy refers to general strategy content that does not depend on a specific target deployment platform. The electronic device, following the programming language syntax, data structures, and algorithm logic specified by the platform-independent layer rules, gradually writes the first part of the strategy into code that a computer can recognize and execute, i.e., the first code.

[0046] S105: Based on platform-related layer rules, generate second code for executing the second part of the strategy.

[0047] In this embodiment, the electronic device generates code corresponding to the second part of the strategy based on platform-related layer rules. The second part of the strategy is related to the characteristics of the target deployment platform. The electronic device writes code based on the portion of the platform-related layer rules that specifies the hardware resource characteristics of a particular platform. For example, for a specific platform, the ADC channel allocation rules specify which specific channels should be used to collect data from different sensors.

[0048] Following these rules, electronic devices use programming languages ​​and development tools suitable for the target deployment platform to translate the second part of the strategy into code that can be executed on the target deployment platform, i.e., the second code.

[0049] S106: Concatenate the first code and the second code to obtain the fault monitoring code used to execute the fault monitoring strategy.

[0050] In this embodiment, after generating the first code and the second code, the electronic device continues to perform a concatenation operation between them. First, the electronic device checks the interface specifications and data interaction methods of the first and second codes to ensure that their data formats and data transmission methods match. Then, it concatenates the two codes according to a predetermined logical functional structure and execution order.

[0051] For example, the first code is responsible for executing the general fault judgment part in the fault monitoring strategy, and the second code is responsible for collecting and preprocessing hardware resource data according to the characteristics of the target platform. The electronic device will pass the data collected by the second code to the first code for fault judgment and processing. The code segments of the two are combined together in a reasonable order to form a complete and coherent code program.

[0052] The fault monitoring code generated in this application embodiment is adapted to the characteristics of the target deployment platform, which improves the accuracy and efficiency of fault monitoring. The final fault monitoring code can run on the target deployment platform to achieve effective monitoring of vehicle faults.

[0053] The embodiments of this application improve the development efficiency and reusability of fault monitoring code by dividing the fault monitoring strategy into two parts: one independent of the target deployment platform and the other relevant. These parts are then concatenated using a layered rule base to generate corresponding code for each part. On one hand, for different vehicle fault monitoring needs, as long as similar platform-independent strategies exist, the first code can be directly reused without rewriting, reducing development workload. On the other hand, when the fault monitoring code needs to be deployed to different platforms, only the second code needs to be adjusted according to the platform-related layer rules, avoiding a complete code rewrite and significantly reducing cross-platform portability costs. Simultaneously, the use of a layered rule base makes the code structure clearer, easier to maintain and manage, and improves the reliability and stability of the code.

[0054] In some embodiments of this application, the step S104 above, which generates first code for executing the first part of the strategy based on platform-independent layer rules, may include: determining multiple first objective functions for implementing the first part of the strategy based on platform-independent layer rules; copying the code corresponding to each first objective function from the hierarchical rule base to obtain the first code.

[0055] As described above, the platform-independent layer rules provide a series of general programming logic and specifications. Based on these rules and the specific requirements of the strategy in Part One, the electronic device determines multiple first objective functions capable of implementing the strategy in Part One. Each of these first objective functions is responsible for a specific monitoring function. For example, some functions are specifically used to calculate the data collected by the sensors according to preset mathematical formulas to determine whether a fault threshold has been reached; other functions are responsible for format conversion and preliminary processing of the collected data for subsequent fault diagnosis.

[0056] After determining the first objective function, the electronic device can copy the code corresponding to each first objective function from a preset hierarchical rule base to obtain the first code. In this embodiment, the hierarchical rule base stores various code fragments related to platform-independent layer rules. For each determined first objective function, the electronic device searches for the corresponding code in the hierarchical rule base.

[0057] For example, if a primary objective function is used to execute general fault threshold judgment logic, the electronic device will find code snippets written according to platform-independent layer rules in the hierarchical rule base that implement this fault threshold judgment function. These corresponding code snippets are then copied and combined in a specific order and structure. These copied code snippets together constitute the primary code. For instance, a function that converts a 12-bit resolution ADC sample value (raw digital quantity) with a reference voltage of 3.3 volts into an actual voltage value is used as an example of the primary objective function. The code for this function is: `uint16_t adc_to_voltage(uint16_t adc_val) {return(adc_val*3300) / 4095;}`. This function's code is generic and can be directly copied.

[0058] In some embodiments of this application, the step S105 above, which generates second code for executing the second part of the strategy based on platform-related layer rules, may include: determining multiple second objective functions for implementing the second part of the strategy based on platform-related layer rules; obtaining the code template of each second objective function from the hierarchical rule base; and filling the hardware parameter information of the target deployment platform related to the second part of the strategy into the code template of each second objective function to obtain the second code.

[0059] As described above, the second part of the strategy is related to the platform characteristics of the target deployment platform. The electronic device determines one or more second objective functions that can implement the second part of the strategy based on platform-related layer rules. For example, for hardware resource data acquisition functions based on the ADC channel allocation rules of the target deployment platform, a corresponding acquisition function is determined.

[0060] After determining the second objective function, the electronic device retrieves the code template for each second objective function from the hierarchical rule base. In this embodiment, the hierarchical rule base pre-stores code templates designed for the characteristics of different target deployment platforms. For each determined second objective function, the electronic device searches for the corresponding code template in the hierarchical rule base. For example, if a second objective function is used for data acquisition according to the ADC channel allocation rules of a specific platform, the electronic device will find a code template designed according to the platform-related layer rules, containing a data acquisition framework and basic logic. This code template provides a basic code structure, and subsequent use only requires filling in specific hardware parameter information.

[0061] In this embodiment, the code template specifies the basic framework of the code, the data input / output method, and some general processing logic, ensuring that the generated code conforms to the requirements of the platform's relevant layer rules. The hardware parameter information of the target deployment platform related to the second part of the strategy is filled into the code template of each second objective function to obtain the second code.

[0062] For example, taking the CAN FD Send function as the second target function (the CAN FD Send function is a function used to implement the physical layer data transmission function of the CAN FD (Controller Area Network Flexible Data Rate) communication protocol), the CAN FD Send function needs to obtain the CAN controller hardware address of the hardware platform (target deployment platform) when sending data. Therefore, when generating code that can execute the CAN FD Send function on the target deployment platform, the CAN controller hardware address of the target deployment platform needs to be filled into the code template of the CAN FD Send function.

[0063] It is understandable that the target deployment platform has its own unique hardware parameter information. For example, the central processing unit architecture of the target deployment platform may have specific parameters such as instruction set and cache size; the ADC channel allocation rules may have parameters such as the sensor type and acquisition frequency corresponding to each channel; and the communication physical layer specifications may include information such as baud rate and data frame format. The electronic device fills in this hardware parameter information related to the strategy in Part Two into the corresponding code template as needed.

[0064] For example, the code template for the data acquisition function can be filled with the sensor information corresponding to the specific channel and the acquisition frequency, etc., from the ADC channel allocation rules of the platform. In this way, the code template can be customized according to the actual hardware parameters of the target deployment platform, ultimately resulting in the second code of the second part of the strategy that can be executed on the target deployment platform.

[0065] In some embodiments of this application, the fault monitoring code generation method may further include performing compatibility verification on the fault monitoring strategy. When the fault monitoring strategy is compatible with the target deployment platform, fault monitoring code for executing the fault monitoring strategy is generated; when the fault monitoring strategy is incompatible with the target deployment platform, a first exception message is output, which indicates the part of the fault monitoring strategy that is incompatible with the target deployment platform, and / or the content of the fault monitoring strategy that needs to be adjusted.

[0066] In this embodiment, if an incompatibility is found between the fault monitoring strategy and the target deployment platform, the electronic device will indicate which specific strategy content conflicts with the target deployment platform. For example, a specific fault threshold may be set too high or too low, exceeding the detection range of the target platform's sensors. Simultaneously, the electronic device will analyze what adjustments are needed to the overall fault monitoring strategy to achieve compatibility with the target deployment platform, such as whether the sampling frequency needs adjustment or the data processing algorithm needs optimization. Then, these incompatible parts and the content requiring adjustment are presented through a first exception message, enabling developers to understand the problem and make targeted modifications and improvements to the fault monitoring strategy, thereby ensuring the smooth generation of fault monitoring code suitable for the target deployment platform.

[0067] In some embodiments of this application, the fault monitoring strategy includes the monitored object, the corresponding monitoring method, the fault triggering condition, and the fault handling action. The monitored object specifies the specific component or system that needs to be monitored, such as the engine, battery, and various sensors of a vehicle. The monitoring method specifies the specific monitoring means used for these monitored objects, such as real-time data collection through specific sensors or periodic status checks on a component. The fault triggering condition sets the conditions under which a fault is determined to have occurred; this may be based on the collected data exceeding a certain threshold range or the occurrence of a specific event. The fault handling action describes a series of operations that should be taken after a fault is triggered, such as reporting a fault code, triggering an alarm, and adjusting system operating parameters.

[0068] Figure 2 An implementation flowchart of a method for verifying the compatibility of fault monitoring strategies is shown according to an embodiment of this application. Figure 2 As shown, the method for verifying the compatibility of the fault monitoring strategy may include the following steps S201 to S204:

[0069] S201: Verify whether the monitoring method of the monitored object is supported by the target deployment platform.

[0070] In this embodiment, the electronic device compares the monitoring method corresponding to each monitored object in the fault monitoring strategy with the hardware parameters of the target deployment platform. For each monitored object, such as engine speed monitoring (assuming the monitoring method is real-time acquisition via a specific speed sensor), the electronic device checks whether the target deployment platform has a compatible hardware interface and driver to support this acquisition method. For example, if the target deployment platform only supports a minimum ADC sampling period of 50ms, while the fault monitoring strategy requires ADC sampling with a 10ms sampling period, then the monitoring method of this strategy is not supported by the target deployment platform.

[0071] If the target platform does not have the corresponding hardware resources or cannot provide a suitable driver to collect this speed data, it indicates that the monitoring method is not supported by the target deployment platform, which may cause fault monitoring to fail.

[0072] In some embodiments of this application, if the monitoring method of the monitored object is not supported by the target deployment platform, the electronic device can provide corresponding prompts to indicate to the user in which aspects the target deployment platform does not support the monitoring method of the monitored object, so that the user can adjust the fault monitoring strategy. For example, the electronic device can prompt the user that "the target deployment platform only supports a minimum 50ms ADC sampling period" and "the ADC sampling channel has been occupied by module X".

[0073] In other embodiments, if the monitoring method of the monitored object is not supported by the target deployment platform, the electronic device can provide an alternative solution. For example, the electronic device can prompt the user that "the target deployment platform only supports a minimum ADC sampling period of 50ms, and it is recommended to adjust the sampling period from 10ms to 50ms."

[0074] In some possible embodiments, the electronic device may also support a one-click modification function, such as "The target deployment platform only supports a minimum ADC sampling period of 50ms. It is recommended to adjust the sampling period from 10ms to 50ms. Please confirm whether to modify it." If the user confirms the modification, the fault monitoring strategy can be modified with one click without repeated manual modifications.

[0075] S202: The computing power to determine the fault monitoring strategy based on the monitored object, monitoring method, fault triggering conditions, and fault handling actions.

[0076] In this embodiment, the electronic device comprehensively considers various elements of the fault monitoring strategy to calculate the computing power required for the fault monitoring requirement. The complexity of data acquisition and processing varies depending on the monitoring object and method. For example, for complex sensor network data acquisition and complex fault judgment logic (monitoring method) based on large amounts of data, combined with strict fault triggering conditions (such as multiple parameters exceeding thresholds simultaneously) and a series of complex fault handling actions (such as simultaneous fault code reporting, system status adjustment, and notification of multiple related modules), the electronic device needs to analyze the computational load involved in these operations. This includes data reading, conversion, computation, and the response efficiency of the central processing unit, memory usage, and other resources required for various logical judgments, thereby determining the computing power required for the entire fault monitoring strategy during execution.

[0077] S203: Verify whether the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform.

[0078] It is understandable that, in order to ensure the stability and reliability of the system when running various tasks, the target deployment platform has its own specific computing power redundancy requirements (for example, platform A requires reserving at least 12% computing power, and platform B requires reserving at least 10% computing power). In the embodiments of this application, the computing power parameters of each hardware platform can be pre-stored. The computing power parameters may include the core architecture of the hardware platform, the number of cores, the core computing power utilization of each core, the core computing power redundancy of each core, the core computing power redundancy required by the core architecture of the entire hardware platform, and a series of computing power-related parameters.

[0079] Electronic devices compare the computational power requirements of the calculated fault monitoring strategy with the computational power redundancy of the target deployment platform. If the computational power required by the fault monitoring strategy exceeds the redundant computational power that the target deployment platform can provide, then during platform operation, insufficient resources may prevent fault monitoring from being executed in a timely and accurate manner, and may even affect the normal operation of the entire system.

[0080] S204: If the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform, and the monitoring method of the monitored object is supported by the target deployment platform, then the fault monitoring strategy is compatible with the target deployment platform; otherwise, the fault monitoring strategy is incompatible with the target deployment platform.

[0081] After the electronic device completes the verification of the first three steps, if it is found that the computing power of the fault monitoring strategy is within the computing power redundancy range of the target deployment platform, and the monitoring method of the monitored object can also be supported by the target platform, then the fault monitoring strategy can be considered compatible with the target deployment platform. This indicates that the fault monitoring strategy can monitor vehicle faults on this target deployment platform according to the predetermined monitoring objects, monitoring methods, fault triggering conditions, and fault handling actions.

[0082] Conversely, if the monitoring method is not supported or the computing power is insufficient, it indicates that the fault monitoring strategy is incompatible with the target deployment platform. In this case, the fault monitoring strategy needs to be adjusted, such as modifying the monitoring method or optimizing the fault triggering logic to reduce computing power requirements, in order to ensure its proper functioning on the target deployment platform.

[0083] It should be noted that the compatibility verification of fault monitoring strategies is not limited to the verification aspects described above. For example, it can also verify whether the processing actions involved in the fault monitoring strategy comply with the relevant requirements of automotive standard diagnostic protocols during implementation. Furthermore, regarding communication protocol compatibility, the fault monitoring strategy may involve communication with other vehicle systems or external devices. If the communication protocol used is incompatible with the communication module of the target deployment platform—for example, if the target platform only supports a specific version of the Controller Area Network (CAN) protocol, and the fault monitoring strategy uses an outdated or incompatible version—errors, packet loss, or even communication interruptions may occur during data transmission, thus affecting the accuracy and timeliness of fault monitoring. In addition, the fault monitoring strategy should be verified in relation to the system resource usage of the target deployment platform. This application does not impose limitations on this; the verification content can be enriched according to the actual application.

[0084] In some embodiments of this application, the fault monitoring code generation method further includes adjusting the code format of the fault monitoring code so that the adjusted fault monitoring code conforms to the compilation specifications of the target deployment platform.

[0085] It's understandable that different target deployment platforms may have different compilation standards, including specifications for code syntax, identifier naming rules, and many other aspects. For example, some target deployment platforms require that function names in the code be uniformly prefixed with "Bms_Diag_" to be compatible with the naming rules of modules in the Automotive Open System Architecture (AUTOSAR). By adjusting the format of the fault monitoring code, the adjusted code conforms to the compilation standards of the target deployment platform, ensuring that the code can be compiled and run smoothly on the target platform and avoiding compilation errors or runtime anomalies caused by non-compliant code formatting.

[0086] In some embodiments of this application, the fault monitoring code generation method further includes verifying the fault monitoring code based on preset test cases. If the fault monitoring code fails the test cases, a second exception message is output, which indicates the inapplicable test cases in the fault monitoring code.

[0087] In this embodiment, test cases for detecting the functionality of relevant functions can be preset based on the code of related functions already stored in the hierarchical rule base. The test cases set in this application can cover the running scenarios of the fault monitoring code under various possible conditions, including but not limited to fault monitoring under normal operating conditions, fault triggering and handling under boundary conditions, and code response when abnormal data is input.

[0088] Once the fault monitoring code is generated, the electronic device performs functional verification, or testing, based on these pre-defined test cases. For each test case, the electronic device provides the corresponding input data to the fault monitoring code and observes the code's execution process and output results. For example, in one test case, a specific hardware parameter value is set as input. The fault monitoring code is expected to accurately detect that the parameter exceeds the normal range and respond according to the predetermined fault handling actions, such as reporting a specific fault code. The electronic device then compares the actual output of the code with the expected output to see if they match.

[0089] If the fault monitoring code fails a test case, a second exception message is output. This message indicates which test cases in the fault monitoring code are inapplicable. When the fault monitoring code exhibits unexpected behavior in a particular test case, the electronic device analyzes the specific requirements of that test case and the actual execution of the code to pinpoint which test case failed verification and identify the problem encountered during its execution. By outputting this second exception message, developers can understand in which test scenarios the fault monitoring code is problematic, allowing for targeted inspection and modification to ensure accurate execution of its corresponding fault monitoring strategy in real-world applications.

[0090] In some embodiments, this application also provides a readable storage medium storing a program or instructions that, when executed on an electronic device, cause the electronic device to perform the fault monitoring code generation method described in the above embodiments.

[0091] In some embodiments, this application also provides a program product, including: a program or instructions, which, when run on an electronic device, cause the electronic device to execute the fault monitoring code generation method described in the above embodiments.

[0092] In some embodiments, this application also provides an electronic device, which includes: one or more processors; one or more memories; the one or more memories storing one or more programs, which, when executed by one or more processors, cause the electronic device to perform the fault monitoring code generation method described in the above embodiments.

[0093] In some embodiments, this application also provides a vehicle, which includes in-vehicle electronic equipment, which may be the electronic equipment mentioned above.

[0094] Now for reference Figure 3The diagram illustrates a block diagram of an electronic device 800 according to some embodiments of this application. The electronic device 800 may include one or more processors 801 coupled to a controller hub 803. In at least one embodiment, the controller hub 803 communicates with the processor 801 via a multi-branch bus such as a Front Side Bus (FSB) or a point-to-point interface such as a Quick Path Interconnect (QPI). The processor 801 executes instructions controlling general types of data processing operations. In one embodiment, the controller hub 803 includes, but is not limited to, a Graphics & Memory Controller Hub (GMCH) (not shown) and an Input / Output Hub (IOH) (which may be on a separate chip) (not shown), wherein the GMCH includes memory and a graphics controller and is coupled to the IOH.

[0095] Electronic device 800 may also include a coprocessor 802 and a memory 804 coupled to a controller hub 803. Alternatively, one or both of the memory and GMCH may be integrated within the processor (as described in this application), with memory 804 and coprocessor 802 directly coupled to processor 801 and controller hub 803, which is on a single chip with IOH.

[0096] Memory 804 may be, for example, Dynamic Random Access Memory (DRAM), Phase Change Memory (PCM), or a combination of both. Memory 804 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. The computer-readable storage medium stores instructions, specifically, temporary and permanent copies of those instructions. These instructions may include: instructions that, when executed by at least one processor, cause electronic device 800 to implement the fault monitoring code generation method provided in the embodiments of this application. When the instructions are executed on a computer, the computer performs the fault monitoring code generation method provided in the embodiments of this application.

[0097] In one embodiment, the coprocessor 802 is a dedicated processor, such as, for example, a high-throughput many-integrated core (MIC) processor, a network or communication processor, a compression engine, a graphics processor, general-purpose computing on graphics processing units (GPGPU), or an embedded processor, etc. Optional properties of the coprocessor 802 are indicated by dashed lines. Figure 3 middle.

[0098] In one embodiment, electronic device 800 may further include a Network Interface Controller (NIC) 806. The network interface 806 may include a transceiver for providing a radio interface for electronic device 800 to communicate with any other suitable device, such as a front-end module, antenna, etc. In various embodiments, the network interface 806 may be integrated with other components of electronic device 800. The network interface 806 can implement the functions of the communication unit in the above embodiments.

[0099] Electronic device 800 may further include input / output (I / O) device 805. Input / output device 805 may include: a user interface designed to enable a user to interact with electronic device 800; a peripheral component interface designed to enable peripheral components to interact with electronic device 800; and / or sensors designed to determine environmental conditions and / or location information related to electronic device 800.

[0100] It is worth noting that, Figure 3 This is merely an example. That is, although... Figure 3 The electronic device 800 shown includes multiple devices such as a processor 801, a controller hub 803, and a memory 804. However, in practical applications, devices using the methods of this application may include only a portion of the devices in the electronic device 800. For example, it may include only the processor 801 and the network interface 806. Figure 3 The properties of the optional devices are shown by dashed lines.

[0101] Now for reference Figure 4 The diagram shown is a block diagram of a System-on-Chip (SoC) 900 according to some embodiments of this application. Figure 4 In the diagram, similar components share the same reference numerals. Additionally, dashed boxes are an optional feature for more advanced SoCs. Figure 4In this embodiment, SoC 900 includes: an interconnect unit 950 coupled to processor 910; a system proxy unit 980; a bus controller unit 990; an integrated memory controller unit 940; a group or one or more coprocessors 920, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 930; and a direct memory access (DMA) unit 960. In one embodiment, coprocessor 920 includes a dedicated processor, such as, for example, a network or communication processor, a compression engine, general-purpose computing on graphics processing units (GPGPU), a high-throughput MIC processor, or an embedded processor.

[0102] Static Random Access Memory (SRAM) cell 930 may include one or more tangible, non-transitory computer-readable media for storing data and / or instructions. The computer-readable storage medium stores instructions, specifically, temporary and permanent copies of the instructions. The instructions may include: instructions that, when executed by at least one processor, cause the SoC to implement the fault monitoring code generation method disclosed in embodiments of this application. When the instructions are executed on a computer, they cause the computer to perform the fault monitoring code generation method disclosed in embodiments of this application.

[0103] It is understood that, as used herein, the term “module” may refer to or include, or be part of, an application-specific integrated circuit (ASIC), electronic circuitry, a processor (shared, dedicated, or grouped) and / or memory that executes one or more software or firmware programs, combinational logic circuitry, and / or other suitable hardware components that provide the described functionality.

[0104] It is understood that in the various embodiments of this application, the processor may be a microprocessor, a digital signal processor, a microcontroller, etc., and / or any combination thereof. According to another aspect, the processor may be a single-core processor, a multi-core processor, etc., and / or any combination thereof.

[0105] The embodiments disclosed in this application can be implemented in hardware, software, firmware, or a combination of these implementation methods. Embodiments of this application can be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0106] Program code can be applied to input instructions to execute the functions described in this application and generate output information. The output information can be applied to one or more output devices in a known manner. For the purposes of this application, the processing system includes any system having a processor such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0107] The program code can be implemented using a high-level procedural language or an object-oriented programming language to communicate with the processing system. Assembly language or machine language can also be used when needed. In fact, the mechanisms described in this application are not limited to any particular programming language. In either case, the language can be a compiled language or an interpreted language.

[0108] In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried or stored thereon on one or more temporary or non-temporary machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or through other computer-readable media. Therefore, machine-readable media may include any mechanism for storing or transmitting information in a machine-readable (e.g., computer-readable) form, including but not limited to floppy disks, optical disks, CD-ROMs, magneto-optical disks, read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic cards or optical cards, flash memory, or tangible machine-readable storage for transmitting information (e.g., carrier waves, infrared signals, digital signals, etc.) using the Internet in the form of electrical, optical, acoustic, or other forms of propagated signals. Therefore, machine-readable media includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a machine-readable (e.g., computer-readable) form.

[0109] In the accompanying drawings, some structural or methodological features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order may not be necessary. Rather, in some embodiments, these features may be arranged in a manner and / or order different from that shown in the illustrative drawings. Furthermore, the inclusion of structural or methodological features in a particular figure does not imply that such features are required in all embodiments, and in some embodiments, these features may be omitted or may be combined with other features.

[0110] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0111] It should be noted that in the examples and description of this application, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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 limitations, 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.

[0112] Although this application has been illustrated and described with reference to certain preferred embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made thereto without departing from the scope of this application.

Claims

1. A method for generating fault monitoring codes, applied to electronic devices, characterized in that, The method includes: Obtain the fault monitoring strategy used to monitor vehicle faults; Based on the target deployment platform of the fault monitoring strategy, a first part of the strategy that is unrelated to the target deployment platform and a second part of the strategy that is related to the target deployment platform are determined in the fault monitoring strategy. Obtain a preset hierarchical rule base, which includes platform-independent layer rules and platform-related layer rules; Based on the platform-independent layer rules, first code is generated to execute the first part of the strategy; Based on the platform-related layer rules, second code is generated for executing the second part of the strategy; By concatenating the first code and the second code, fault monitoring code is obtained for executing the fault monitoring strategy.

2. The method according to claim 1, characterized in that, The generation of first code for executing the first part of the strategy based on the platform-independent layer rules includes: Based on the platform-independent layer rules, a plurality of first objective functions are determined to implement the first part of the strategy; The code corresponding to each of the first objective functions is copied from the hierarchical rule base to obtain the first code.

3. The method according to claim 1, characterized in that, The step of generating second code for executing the second part of the strategy based on the platform-related layer rules includes: Based on the platform-related layer rules, a plurality of second objective functions are determined to implement the second part of the strategy; Obtain the code template for each of the second objective functions from the hierarchical rule base; The hardware parameter information of the target deployment platform related to the second part of the strategy is filled into the code template of each second objective function to obtain the second code.

4. The method according to claim 1, characterized in that, The method further includes: Perform compatibility verification on the aforementioned fault monitoring strategy; When the fault monitoring strategy is compatible with the target deployment platform, fault monitoring code is generated to execute the fault monitoring strategy; When the fault monitoring strategy is incompatible with the target deployment platform, a first abnormality prompt message is output. The first abnormality prompt message is used to indicate the part of the fault monitoring strategy that is incompatible with the target deployment platform, and / or the content of the fault monitoring strategy that needs to be adjusted.

5. The method according to claim 4, characterized in that, The fault monitoring strategy includes the monitoring object, the monitoring method corresponding to the monitoring object, the fault triggering condition, and the fault handling action. The compatibility verification of the fault monitoring strategy includes: Verify whether the monitoring method of the monitored object is supported by the target deployment platform; The computing power for determining the fault monitoring strategy is based on the monitored object, the monitoring method, the fault triggering conditions, and the fault handling actions. Verify whether the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform; If the computing power of the fault monitoring strategy meets the computing power redundancy requirements of the target deployment platform, and the monitoring method of the monitored object is supported by the target deployment platform, then the fault monitoring strategy is compatible with the target deployment platform; otherwise, the fault monitoring strategy is incompatible with the target deployment platform.

6. The method according to claim 1, characterized in that, The method further includes: The fault monitoring code is formatted to conform to the compilation specifications of the target deployment platform.

7. The method according to claim 1, characterized in that, The method further includes: The fault monitoring code is verified based on preset test cases; If the fault monitoring code fails the test case, a second exception message is output, which indicates that the test case in the fault monitoring code is not applicable.

8. A readable storage medium, characterized in that, The readable storage medium includes one or more programs that, when executed on an electronic device, cause the electronic device to perform the method according to any one of claims 1 to 7.

9. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more memories are used to store one or more programs; One or more processors are configured to execute the one or more programs to cause the electronic device to perform the method of any one of claims 1 to 7.

Images