Display screen association management method and device, vehicle, medium and program product

Abstract

The embodiment of the invention provides a display screen association management method and device, a vehicle, a medium and a program product. Display update information in a plurality of display screens is acquired according to a preset period, and the display update information comprises display state data, driving state data of a target vehicle and application state information of each display screen; based on a preset association rule in a preset association rule base, determining a cooperative relationship of at least two display screens in the plurality of display screens in display updating; performing cross verification on the display update information of at least two different display screens to obtain a verification result, the different display screens having a cooperative relationship; and under the condition that the verification result is that the fault screen exists, determining a fault type corresponding to the fault screen based on the verification result and the cooperative relationship. According to the method provided by the embodiment of the invention, the fault is subjected to graded recovery according to the fault source, so that the user experience and the system availability are improved.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data processing, and particularly relates to a display screen association management method and device, a vehicle, a medium and a program product. BACKGROUND

[0002] With the popularization of intelligent cockpits, modern vehicles are usually configured with multiple display screens, such as digital instrument panels, central information screens, co-pilot entertainment screens and rear entertainment screens, which increases the probability of display screen failure and damage.

[0003] In the prior art, common fault monitoring technologies include watchdog timers and frame content comparison methods. The watchdog timer method monitors system-level lock, and requires that an application or system periodically "feeds the dog", otherwise a reset is triggered. The frame content comparison method can detect the hash value of consecutive frames by determining whether it is long-term unchanged to monitor display freezing.

[0004] However, in the watchdog timer method, the failure of a specific application or service cannot be identified, and the frame content comparison method is prone to misjudging normal static pictures as failures, resulting in a high false positive rate. In addition, false positives can be partially reduced by increasing scene adaptation rules, but the rules are complex to maintain and are not fully covered. SUMMARY

[0005] The embodiments of the application provide a display screen association management method, device, vehicle, medium and program product, which can cooperatively detect a faulty screen, improve the pertinence of fault detection, reduce the impact on use in the process of solving the fault, and improve the user's use experience.

[0006] In a first aspect, the embodiments of the application provide a display screen association management method, which includes: obtaining display update information in multiple display screens according to a preset period, wherein the display update information includes display state data, driving state data of a target vehicle and application state information of each display screen; determining a cooperative relationship of at least two display screens in the display update based on a preset association rule in a preset association rule library; cross-checking the display update information of at least two different display screens to obtain a checking result, wherein the different display screens have a cooperative relationship; in a case where the checking result is that there is a faulty screen, determining a fault type corresponding to the faulty screen based on the checking result and the cooperative relationship.

[0007] In a second aspect, the embodiments of the application provide a display screen association management device, which includes: The display module is configured to acquire display update information in a plurality of display screens according to a preset period, wherein the display update information comprises display state data, driving state data of the target vehicle, and application state information of each display screen. The management module is configured to determine a cooperative relationship of at least two display screens in the display update based on a preset association rule in a preset association rule library. The verification module is configured to cross-check the display update information of the at least two different display screens to obtain a verification result, wherein the different display screens have a cooperative relationship. The fault module is configured to determine a fault type corresponding to a fault screen based on the verification result and the cooperative relationship in a case where the verification result indicates that there is a fault screen.

[0008] In a third aspect, an embodiment of the present application provides a vehicle, which comprises a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the display screen association management method according to the first aspect.

[0009] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores computer program instructions; the computer program instructions are executed by a processor to implement the display screen association management method according to the first aspect.

[0010] In a fifth aspect, an embodiment of the present application provides a computer program product, which comprises a computer program; the computer program is executed by a processor to implement the display screen association management method according to the first aspect.

[0011] The display screen association management method, device, vehicle, medium and program product provided by the embodiments of the present application acquire display update information in a plurality of display screens according to a preset period, wherein the display update information comprises display state data, driving state data of the target vehicle, and application state information of each display screen, determine a cooperative relationship of at least two display screens in the display update based on a preset association rule in a preset association rule library, thereby regarding the plurality of display screens as a whole, establishing an association between the plurality of display screens, facilitating accurate positioning of faults, cross-checking the display update information of the at least two different display screens to obtain a verification result, wherein the different display screens have a cooperative relationship, thereby inferring the fault of another display screen according to the state of one display screen based on the cooperative relationship, and distinguishing between a “reasonable static” state and a “fault frozen” state based on the cooperative relationship, avoiding false positives, determining a fault type corresponding to a fault screen based on the verification result and the cooperative relationship in a case where the verification result indicates that there is a fault screen, accurately locating the root cause of the fault, and then performing hierarchical recovery of the fault based on the root cause, thereby improving user experience and system availability. BRIEF DESCRIPTION OF DRAWINGS

[0012] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required to be used in the embodiments of the present application will be briefly introduced as follows, and other drawings can be obtained by those of ordinary skill in the art without creative effort on the premise of not paying creative effort.

[0013] Figure 1 is a flow diagram of a display screen association management method provided by the embodiments of the present application; Figure 2 is a schematic diagram of a display screen association management architecture provided by the embodiments of the present application; Figure 3 is a structure schematic diagram of a display screen association management device provided by the embodiments of the present application; Figure 4 is a structure schematic diagram of a vehicle provided by the embodiments of the present application. DETAILED DESCRIPTION

[0014] The features and exemplary embodiments of various aspects of the present application will be described in detail below, in order to make the purposes, technical solutions and advantages of the present application more clear, the present application will be further described in detail below in combination with the drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, but not to limit the present application. The present application can be implemented without some of these specific details by those skilled in the art. The following description of the embodiments is only to provide a better understanding of the present application by showing examples of the present application.

[0015] It should be noted that in this paper, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the terms "include", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or equipment including a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or equipment. Without more limitations, the elements defined by the statement "include" do not exclude the presence of other identical elements in the process, method, article or equipment including the elements.

[0016] With the popularization of intelligent cockpits, modern vehicles are usually equipped with multiple display screens, such as digital instrument panels, central control information screens, co-pilot entertainment screens, and rear entertainment screens. There is a logical association between multiple display screens in terms of function and data. For example, after setting a navigation route on the central control screen, the guidance information is displayed on the instrument panel, the control interface (such as song name and progress bar) of the media played on the rear screen is displayed on the central control screen, and vehicle status information (such as vehicle speed, engine speed, and alarms) is displayed on all related screens.

[0017] Currently, fault monitoring techniques for a single display screen are relatively mature, mainly including watchdog timers and frame content comparison methods. The watchdog timer requires an application or system to periodically "feed the dog", otherwise a reset is triggered. This method cannot distinguish the specific fault source, and the entire system reset seriously affects user experience. The frame content comparison method, for example, calculates the hash value of consecutive frames to monitor display freezing by determining whether it remains unchanged for a long time. The defect of this method is a high false positive rate. When a display screen displays static content (such as paused video, static navigation page, and settings menu) legally, it will be incorrectly determined as a faulty screen.

[0018] In summary, existing technologies independently monitor a single display screen, lack a system-level perspective, and cannot use information provided by other normally working screens to assist in judgment and accurate positioning when one display screen is stuck. In addition, existing technologies cannot distinguish between "faulty freezing" and "reasonable static", leading to unnecessary recovery actions in normal use scenarios. Furthermore, once a fault is detected, existing technologies usually restart the entire application or system, which lacks pertinence and affects user experience.

[0019] Therefore, the embodiments of the present application provide a display screen association method, which changes multiple display screens in a cockpit from a single isolated monitoring object to a "perception network" that can verify each other. By analyzing the logical association between the display states of each display screen, it is determined whether the "no update" state of a certain display screen is a reasonable behavior or a fault behavior, and an accurate recovery operation is performed accordingly.

[0020] To solve the problems of the prior art, the embodiments of the present application provide a display screen association management method, device, vehicle, medium, and program product.

[0021] First, the display screen association management method provided by the embodiments of the present application will be introduced.

[0022] Figure 1 A flowchart of a display screen association management method provided by an embodiment of the present application is shown. As shown in Figure 1 The method can include the following steps: S101: Obtain display update information in the plurality of display screens according to a preset period.

[0023] The display update information includes display state data, driving state data of the target vehicle, and application state information of each display screen.

[0024] Specifically, the display update information in the plurality of display screens is obtained according to a preset period. The display update information can be a display update region of a preset dynamic region in the display screen. Each display screen includes at least one preset dynamic region. The preset dynamic region is a specific region in the display screen that updates content according to changes in vehicle operation, application operation, and the like. For example, in an instrument panel, regions corresponding to vehicle speed, engine speed, and energy consumption can be marked as preset dynamic regions.

[0025] The display update information includes display state data, driving state data of the target vehicle, and application state information of each display screen.

[0026] In each preset period, a feature value such as a hash value in the display screen can be determined by a monitoring agent to determine the display update information according to the hash value of the current preset period and the hash value of the previous preset period. The preset period can be set according to the functions of different display screens.

[0027] The driving state data can be obtained in real time through a vehicle bottom network, including but not limited to vehicle speed, engine speed, gear position, tire pressure, and other parameters reflecting the real-time running state of the target vehicle. The application state information can be collected by a context perception module, including application process indicators of foreground running of each display screen, and life cycle states of applications, such as play / pause / stop states of media applications, navigation states of navigation applications, and active / exit states of setting applications.

[0028] Further, the hash value can be determined by incremental calculation. The hash value calculation can be performed in an incremental calculation manner, that is, the hash value of a pixel block that has changed in the preset dynamic region is updated, thereby reducing the occupation of computing resources.

[0029] The embodiments of the present application reflect the update status of the display screen through the display update information, and realize fault diagnosis from the system level through the fusion of multi-dimensional data, thereby providing a data basis for subsequent collaborative analysis and cross-validation.

[0030] S102: Determine a cooperative relationship in display updating of at least two display screens in the plurality of display screens based on a preset association rule in a preset association rule library.

[0031] Specifically, a predefined association rule library is defined to obtain a preset association rule library, and the preset association rule library includes formalized and modeled various preset association rules, and the preset association rules describe fixed association relationships in actual use scenarios of the multiple display screens.

[0032] According to a preset association relationship in the preset association rule library, a cooperative relationship of at least two display screens in display updating is determined.

[0033] The cooperative relationship represents a logical relationship of mutual influence and mutual association of the at least two display screens in display updating, and can include a cause-effect relationship rule, a data homology rule, and a state dependency rule.

[0034] In actual operation, an adaptive preset association rule is matched from the preset association rule library according to collected driving state data and application state information of the target vehicle, so as to determine a corresponding cooperative relationship between any two or more display screens.

[0035] For example, when it is detected that the center screen runs a navigation application and the rear screen runs a media application, a cause-effect relationship rule and a state dependency rule are matched respectively, so as to determine a cause-effect relationship rule of the instrument panel and the center screen in navigation display, and a state dependency rule of the rear screen and the center screen in media control.

[0036] Further, the preset association rules in the preset association rule library can be upgraded by remote control or other upgrading methods to adapt to newly added application functions or display screen types.

[0037] According to the preset association rule library determined according to mutual cooperation in function and mutual association in data, the cooperative relationship between the multiple display screens is determined to accurately identify the cooperative relationship of different display screens in different application scenarios.

[0038] S103: Cross-checking is performed on display updating information of the at least two different display screens to obtain a checking result.

[0039] The different display screens have a cooperative relationship.

[0040] Specifically, after the cooperative relationship between the at least two display screens is determined, cross-checking is performed on the display updating information of the corresponding display screens according to the cooperative relationship, that is, by comparing the display updating information of the display screens, it is determined whether the display updating of the display screens meets a cooperative requirement corresponding to the cooperative relationship in the preset association rule.

[0041] Cross-validation involves determining the expected update behavior of each participating display screen under normal circumstances based on the preset association rules corresponding to the collaborative relationship, comparing the actual display update information reported by each display screen with the expected update behavior, and judging whether there is any deviation from the expectation.

[0042] For example, if a causal relationship is determined based on preset association rules between the foreground operation of the navigation application in the central control screen and the navigation card area of ​​the instrument panel, and the corresponding coordination relationship indicates that the navigation card area of ​​the instrument panel is updated within a first preset time when the target vehicle speed is the first preset speed, then during cross-validation, the application status information of the central control screen, the driving status data of the target vehicle, and the display status data of the navigation card area of ​​the instrument panel are extracted to meet the coordination relationship, and it is determined to meet the coordination requirements and there is no faulty screen.

[0043] The verification results include the absence of faulty screens among all participating displays and the presence of at least one faulty screen.

[0044] Furthermore, the reliability of the verification results can be evaluated using historical verification data and current context information. For example, an occasional update delay can reduce the confidence level of a suspected fault.

[0045] The embodiments of this application perform cross-verification on multiple displays based on collaborative relationships. This can reduce the probability of misjudgment and improve the accuracy of fault location by mutually verifying each other through preset association rules and context information between multiple displays.

[0046] S104: If the verification result indicates the existence of a faulty screen, determine the fault type corresponding to the faulty screen based on the verification result and the collaboration relationship.

[0047] Specifically, when the verification result indicates the presence of a faulty screen, the root cause of the fault is determined based on the verification result and the inherent logic of the corresponding collaborative relationship. This determines the fault type corresponding to the faulty screen, which includes display fault type, system service fault type, and communication fault type. This allows for precise and minimally impactful recovery based on the fault type, improving user experience and system availability.

[0048] Furthermore, fuzzy reasoning can be used to handle some boundary and uncertainty verification results. For example, when the update delay of the display screen is at the threshold edge, multi-dimensional information can be combined to comprehensively determine the fault type.

[0049] Furthermore, it can be combined with watchdog timers to form a multi-layered defense system of "application-level recovery, service-level recovery, and system-level recovery," thereby enhancing the system's robustness.

[0050] The verification results of this application reflect the abnormal differences of each display screen. The collaborative relationship represents the logical dependency and data flow between each display screen. Logical reasoning is performed together based on the verification results and the collaborative relationship, which realizes the accurate location of the faulty screen and the fault type, improves the accuracy of fault type recovery, reduces the impact of restoring the faulty screen on use, and improves the user experience.

[0051] This application embodiment acquires updated information from multiple displays at a preset cycle to provide data support for judging faulty screens. By clarifying the collaborative relationship between multiple displays through a preset association rule base, the limitations of isolated monitoring are avoided. Cross-validation is performed based on the collaborative relationship, and the obtained verification results reduce the false alarm rate. Based on the verification results and collaborative relationship, the fault type is inferred and located, realizing accurate monitoring and location of display faults. This enables the execution of targeted hierarchical recovery strategies, improves the continuity of the smart cockpit and the smoothness of the user experience, and enhances the user experience.

[0052] In some embodiments, the preset association rules include causal relationship rules; cross-validation is performed on the display update information of at least two different displays to obtain the validation results, including: Determine the corresponding result display screen among multiple displays based on causal relationship rules; If the specified application in the results display screen is in the first preset application state or the driving status data of the target vehicle meets the first vehicle condition, determine whether the display update information of the results display screen is updated within a first preset time. If so, confirm that the verification result indicates there is no faulty screen; If not, the verification result indicates that a faulty screen exists.

[0053] Specifically, the preset association rules include causal relationship rules, which are used to indicate that if the first preset application state or the first vehicle condition is met, the corresponding display screen must be updated within a first preset time.

[0054] The corresponding result display screen is determined among multiple display screens according to the causal relationship rule. The result display screen refers to the display screen that is triggered and updated according to the causal relationship rule.

[0055] In addition, if the specified application corresponding to the result display screen is in the first preset application state or the driving status data of the target vehicle meets the first vehicle condition, it is determined whether the display update information of the result display screen is updated within a first preset time.

[0056] The first preset application state refers to the application state that is preset in the causal relationship rule and can trigger the update of the result display screen, such as the "navigating" state of a navigation application or the "playing" state of a media application. The first vehicle condition refers to the vehicle driving state that can trigger the update of the result display screen, such as the vehicle speed being greater than 5 km / s or the gear being in driving gear. The first preset time refers to the maximum time threshold that the result display screen should complete after the update is triggered in the causal relationship rule. The first preset time can be set differently according to the update requirements of different application scenarios.

[0057] If the specified application in the result display is in the first preset application state or the driving status data of the target vehicle meets the first vehicle condition, the display update information of the result display will be updated within the first preset time, and the corresponding verification result will be that there is no fault screen.

[0058] If the specified application in the result display is in the first preset application state or the driving status data of the target vehicle meets the first vehicle condition, and the display update information of the result display is not updated within the first preset time, then the corresponding verification result is that there is a fault screen.

[0059] In the process of updating the result display screen, the screen monitoring agent can report the hash value and change status of the result display screen at a preset period to determine the start time when the trigger condition is met, and determine whether the corresponding hash value changes from the start time to the end of the first preset time. If the hash value changes, the verification result is determined to be that there is no faulty screen. If the hash value does not change, the verification result is determined to be that there is a faulty screen.

[0060] For example, causal relationship rules can include the following scenarios: Navigation: If the central control screen navigation application is in the foreground and is in navigation mode, and the vehicle speed is greater than 5 km / h, then the instrument panel navigation card / area (e.g., turn arrows, distance information) should be updated within time T1. The instrument panel navigation card / area is the result display screen, the central control screen navigation application being in the foreground and in navigation mode is the first preset application state, and the vehicle speed being greater than 5 km / h is the first preset vehicle condition. Safety alarms: If the vehicle domain controller reports a new fault alarm (such as low tire pressure), the instrument panel - alarm indicator and the central control screen - notification center should be displayed simultaneously within time T1. The instrument panel - alarm indicator and the central control screen - notification center are the result display screens, and the new fault alarm reported by the vehicle domain controller is the first vehicle condition. Task relay type: If the rear screen initiates screen mirroring to the front central control screen, the central control screen should respond within time T1. The central control screen is the result display screen, and the rear screen initiating screen mirroring to the front central control screen is the first preset application state.

[0061] This application embodiment clarifies the logical relationship between multiple displays through cross-validation based on causal relationship rules, providing an accurate basis for judgment in the cross-validation process. It makes full use of the functional logical relationship between multiple displays and achieves effective identification of faulty screens. It accurately locates the faulty screen when a faulty screen exists, rather than simply indicating that the screen is unresponsive, thus improving the accuracy of display screen fault monitoring.

[0062] In some embodiments, the preset association rules include data origination rules; cross-validation is performed on the display update information of at least two different displays to obtain the validation results, including: At least two displays whose content originates from the same data source are identified as homologous displays. Determine the update cycle and synchronization characteristics of each display screen based on the data source; If the synchronization features are consistent and the difference in update cycles does not exceed the second preset time, the verification result is determined to be that there is no faulty screen. If the synchronization feature values ​​are inconsistent, or the difference in update cycles exceeds the second preset time, the verification result is determined to be a faulty screen.

[0063] Specifically, the preset association rules include the data same-source rule, which is used to identify all the corresponding displays as the same-source displays when the content displayed on multiple displays in the smart cockpit has a common data source. At the same time, in the data same-source rule, the same-source displays should all be updated when the data source is updated, and the difference in the update cycle should not exceed the second preset time.

[0064] In addition, for displays with the same source, their respective synchronization feature values ​​and update cycles are determined. The update cycle can be based on the refresh interval of the part of the display that originates from the same data source. The synchronization feature value is used to determine whether the numerical content of different displays with the same source is logically consistent when they are updated. The synchronization feature value focuses more on the semantic value extracted from the display content.

[0065] If the synchronization feature values ​​of each source display screen are consistent and the difference in update cycle does not exceed the second preset time, the verification result of each source display screen is determined to be that there is no faulty screen.

[0066] If the synchronization feature values ​​corresponding to the same source displays are inconsistent, or the difference in update cycles exceeds the second preset time, the verification result of each same source display is determined to be a faulty screen. If the synchronization feature values ​​are inconsistent but the difference in update cycles does not exceed the second preset time, it may be that the display content of at least one display is disconnected from the real data source, or that there is an error in the data processing stage. If the synchronization feature values ​​are consistent but the difference in update cycles exceeds the second preset time, it may be that there is a performance bottleneck or partial blockage in the rendering pipeline or subscription mechanism of the same source display.

[0067] For example, the same-origin rule can include the following scenarios: Vehicle dynamic data: All screens displaying vehicle speed, engine speed, and gear position (such as the instrument panel, central control screen, and rear seats) have values ​​derived from the same Controller Area Network (CAN) bus signal, and the display update cycle does not exceed the difference of T2 milliseconds. Among them, the CAN signal is the data source, and the screens displaying vehicle speed, engine speed, and gear position are the same source display screens. Environmental data: The outside temperature, time, and date information displayed on the instrument panel and the central control screen are consistent and updated synchronously. The outside temperature, time, and date information are the data sources, and the instrument panel and the central control screen are the same display screen. System status data: The Bluetooth / wireless network connection status icon on the instrument panel should be consistent with the connection status in the central control screen - settings menu in real time. The Bluetooth / wireless network connection status is the data source, and the instrument panel and the central control screen - settings menu are the same display screen.

[0068] Furthermore, data sources can be managed hierarchically. For important data sources (such as vehicle speed and fault alarm data), stricter consistency requirements for synchronization characteristics and shorter second preset times can be set, while for non-important data sources (such as date and time), the standards can be appropriately relaxed.

[0069] This application's embodiments expand the monitoring perspective from the integrity of a single display screen to the system level of cross-device data consistency and synchronization based on cross-verification of data origin rules. This improves the reliability of information and the consistency of user experience, avoids errors caused by subjective judgment, and enhances the reliability of verification results.

[0070] In some embodiments, the preset association rules include state dependency rules; cross-validation is performed on the display update information of at least two different displays to obtain the validation results, including: Determine the master and slave displays among multiple displays based on state dependency rules; If the main display screen has been synchronized and the difference between the update time and the synchronization time does not exceed the third preset time, the verification result is determined to be that there is no faulty screen when the corresponding application status information is updated from the specified application on the display screen. If the main display screen fails to synchronize, or the difference between the update time and the synchronization time exceeds a third preset time, the verification result indicates that there is a faulty screen when updating the corresponding application status information from the specified application on the display screen.

[0071] Specifically, in addition to causal relationship rules and data origination rules, there are also state dependency rules in the preset association rules, which are used to represent the master-slave control and feedback relationship. That is, the state change that occurs on one display screen needs to be reflected in a timely and accurate manner on another display screen that acts as a control or state summary screen.

[0072] In addition, based on the collected display update information, the main display screen and the slave display screen are determined according to the state dependency rules. The main display screen is the receiver, mirror, or control end of the state change, and is generally the core function screen or the main operation control screen, such as the central control screen. The slave display screen refers to the initiator or source of the state change in the state dependency rules, such as the rear entertainment screen.

[0073] In addition, continuous monitoring of the state changes of a specified application on the display screen can be achieved by collecting the application state information of the specified application on the display screen in real time based on the context awareness module. When the specified application completes a state update, the update time corresponding to the application state information update is recorded, and the synchronous monitoring process of the main display screen is triggered.

[0074] After triggering synchronization monitoring, the system monitors the preset dynamic area on the main display screen corresponding to the specified application to determine whether the main display screen has completed synchronization and whether the synchronization is within a third preset time period. Specifically, the main display screen's screen monitoring agent can report the hash value and change status of the associated display area at preset intervals. The system compares the hash values ​​before and after the status update. If the hash value changes in accordance with the application status update on the secondary display screen, the main display screen is determined to have completed synchronization, and the synchronization time is recorded. If the hash value does not change accordingly, the main display screen is determined to have failed to complete synchronization.

[0075] In addition, the difference between the update time and the synchronization time is determined, and it is determined whether the difference between the update time and the synchronization time exceeds a third preset time.

[0076] If the main display screen has completed synchronization and the difference between the update time and the synchronization time does not exceed the third preset time, the verification result is determined to be that there is no faulty screen. If the main display screen has not completed synchronization, or although synchronization has been completed but the difference between the update time and the synchronization time exceeds the third preset time, the verification result is determined to be that there is a faulty screen.

[0077] For example, state dependency rules can include the following scenarios: For media control, if the media application status on the rear screen is "playing", the song progress bar on the central control screen (or the media control bar on the passenger side screen) should be updated within T3 time, and the play / pause status icons should be consistent. The rear screen is the secondary display screen, and the central control screen is the primary display screen. Air conditioning control: If the user adjusts the rear air conditioning temperature through the rear screen, the corresponding area of ​​the central control screen - air conditioning control interface should be updated within T3 time. The rear screen is the secondary display screen, and the central control screen is the primary display screen. Call status: When an incoming call occurs, the instrument panel, central control screen, and head-up display (HUD) should simultaneously display the call notification interface. After the call is established, its call timer should be updated synchronously. The call timer is the slave display, while the instrument panel, central control screen, and HUD are the master displays.

[0078] This application embodiment determines the main display screen and the slave display screen through state dependency rules to complete the cross-verification of multiple display screens, which improves functional reliability, ensures the immediacy and continuity of cross-screen interaction, can effectively identify master-slave screen synchronization failures, and improves the user experience.

[0079] In some embodiments, determining the fault type corresponding to the faulty screen based on the verification result and the cooperation relationship includes: The screen to be updated is determined based on the collaboration relationship; If the verification result indicates that the updated screen is a faulty screen and the corresponding updated screen is a non-faulty screen, the fault type is determined as the application display fault type. If the verification results indicate that both the updated screen and the corresponding updated screen are faulty screens, and the fault of the updated screen is caused by an abnormal system service, the fault type will be determined as a system service fault type. If the verification results indicate that both the updated screen and the updated screen are faulty screens, and the data source stops updating, the fault type is determined to be a communication fault type.

[0080] Specifically, a collaborative relationship describes the direction of information flow or state transmission. Through collaborative relationships, the recipient of information or state can be determined, i.e., the screen being updated. For example, in the causal relationship rule of "central control navigation - instrument display arrow", the instrument panel is the screen being updated.

[0081] Based on the verification results, if the updated screen is clearly a faulty screen and the corresponding updated screen is a non-faulty screen, the fault type can be determined to be an application display fault type. That is, if the update screen is normal, the triggering conditions, data transmission links and system services are all normal, and the fault is the display of the specified application on the updated screen.

[0082] For example, if the navigation application on the central control screen (updating screen) is running normally and the vehicle speed meets the triggering conditions (updating screen is not faulty), but the navigation card area on the instrument panel (updated screen) is not updated (updated screen is faulty), the fault only exists in the navigation application display function of the instrument panel and does not affect the updating screen or other modules, which is consistent with the characteristics of application display fault.

[0083] The verification results show that both the updated screen and the corresponding updated screen are faulty screens. To check the running status of the system services, the running parameters of the core system services can be collected in real time through the background monitoring process, including but not limited to whether the service process is alive, service response time, and service data transmission success rate. If an anomaly is detected in the system service, such as the data distribution service process crashing, the rendering service response timeout, or the inter-service communication link being interrupted, and the system service provides support for the display updates of both the updated screen and the screen being updated, then the fault type is determined to be a system service fault type.

[0084] For example, after the media application status of the rear screen (updated screen) is updated, the control bar of the central control screen (updated screen) is not synchronized, and the media status display of the rear screen itself is also abnormal. After investigation, it was found that the data distribution service has stopped running. It can be determined that the failure of the rear screen and the central control screen is caused by the abnormality of the system service, and the failure type is determined to be the system service failure type.

[0085] The verification results show that both the updated screen and the updated screen are faulty screens. The output data of the data source can be collected through the context awareness module. If it is found that the data source has stopped updating, the fault type is determined to be a communication fault type.

[0086] For example, the vehicle speed display on the instrument panel and the central control screen (both of which are being updated) has not been updated, and the data source transmission node corresponding to the updated screen that is responsible for transmitting vehicle speed data also has no data output. The system service is running normally, but the CAN signal has stopped reporting the vehicle speed signal. At this time, the fault originates from the communication interruption of the data source, and the fault type is determined to be a communication fault type.

[0087] The embodiments of this application can classify fault types into application-level display fault types, service-level system service fault types, and communication-level communication fault types. This allows for the determination of corresponding intervention methods based on the fault type, ensuring the continuity of cockpit functions and the smoothness of user experience, and improving product reliability and user satisfaction.

[0088] In some embodiments, after determining the fault type corresponding to the faulty screen based on the verification result and the cooperation relationship, the method further includes: If the fault type is an application display fault type, a first control command is sent to the fault screen to terminate and restart the specified application that has malfunctioned based on the first control command; In the case of a system service failure, a second control command is sent to the cockpit controller to restart the corresponding system service based on the second control command; In the event of a communication failure, a third control command is sent to the cockpit controller to restart the corresponding communication link or data service based on the third control command.

[0089] Specifically, for different types of faults, differentiated recovery or intervention operations can be implemented to perform recovery or intervention in a targeted manner according to the fault type, thereby minimizing the impact on the system.

[0090] When the fault type is an application display fault, a first control command is generated and sent to the fault screen. This first control command terminates and restarts the specified faulty application. The first control command may include the identifier of the faulty application, the display screen identifier where the application resides, and the restart priority. During the execution of the first control command, all functions of other applications on the fault screen and other displays remain unaffected.

[0091] In the case of a system service failure, a second control command is generated and sent to the cockpit controller to restart the corresponding system service. The second control command may include the service name of the abnormal system service, the identifier of the service process, and the timing of the restart. During the execution of the second control command, applications that depend on this system service are disconnected, and the connection is re-established after the restart is complete, restoring normal display update logic and avoiding prolonged functional interruptions due to service restarts.

[0092] In the event of a communication failure, a third control command is generated and sent to the cockpit controller to restart the corresponding communication link or data service. During the recovery process, the transmission success rate of the communication link or the reception status of the data service is monitored. Upon confirmation of successful recovery, the relevant displays are notified to reload the display content that depends on the data source, resuming normal updates.

[0093] This application embodiment executes hierarchical control commands based on fault type, constructing a layered recovery system from the application level to the system level and then to the communication level. This reduces interference during user operation, ensures effective fault resolution, and preserves the user's usage status and data to the greatest extent, thereby improving the availability and user experience of the intelligent cockpit display system.

[0094] Figure 2 This is a schematic diagram of a display screen association management architecture provided in an embodiment of this application, such as... Figure 2As shown, it includes a data acquisition layer 210, a core processing layer 220, and an execution layer 230.

[0095] The data acquisition layer 210 includes a screen monitoring agent and a context awareness module. The screen monitoring agent is deployed on each display screen, such as the instrument panel, central control panel, and rear screen. It collects the hash value and change status of the corresponding screen frame buffer and reports it according to a preset period to provide basic data for judging the display update status.

[0096] The context awareness module is used to collect CAN signal data of the target vehicle in real time (such as vehicle speed, RPM, gear and other driving status data) and application status information of each display screen to supplement the context basis for fault diagnosis.

[0097] The core processing layer 220 includes a preset association rule base, a fault inference engine, and a global fault adjudication. The preset association rule base predefines preset association rules such as causal relationship rules, data origination rules, and state dependency rules, which are used to clarify the collaborative relationship between multiple displays and provide data basis for fault inference.

[0098] The fault inference engine is used to receive all display update information reported by the data acquisition layer, compare the display update information with the preset association rules in the association rule base, and analyze the rationality of the display updates of each display screen through cross-validation to initially identify faults.

[0099] Global fault adjudication is used to integrate the analysis results of the fault inference engine, conduct global fault adjudication, determine the fault screen and determine the fault type by combining the collaborative relationship. The fault type includes application display fault type, system service fault type and communication fault type.

[0100] The execution layer 230 includes a recovery actuator, which receives the fault type and verification result output by the global fault adjudication, and issues corresponding control commands according to different fault types to achieve hierarchical recovery.

[0101] Figure 3 This is a schematic diagram of a display screen association management device provided in an embodiment of this application. Figure 3 As shown, the device may include a display module 310, a management module 320, a verification module 330, and a fault module 340.

[0102] The display module 310 is used to acquire display update information from multiple displays according to a preset cycle. The display update information includes display status data, driving status data of the target vehicle, and application status information of each display. Management module 320 is used to determine the collaborative relationship between at least two displays in display updates based on preset association rules in a preset association rule base; The verification module 330 is used to cross-verify the display update information of at least two different displays to obtain the verification result, wherein there is a collaborative relationship between the different displays; The fault module 340 is used to determine the fault type corresponding to the fault screen based on the verification result and the collaboration relationship when the verification result indicates that a fault screen exists.

[0103] In some embodiments, the preset association rules include causal relationship rules; the verification module 330 performs cross-validation on the display update information of at least two different displays to obtain the verification result, which is used for: Determine the corresponding result display screen among multiple displays based on causal relationship rules; If the specified application in the results display screen is in the first preset application state or the driving status data of the target vehicle meets the first vehicle condition, determine whether the display update information of the results display screen is updated within a first preset time. If so, confirm that the verification result indicates there is no faulty screen; If not, the verification result indicates that a faulty screen exists.

[0104] In some embodiments, the preset association rules include data origination rules; the verification module 330 performs cross-validation on the display update information of at least two different displays to obtain the verification result, which is used for: At least two displays whose content originates from the same data source are identified as homologous displays. Determine the update cycle and synchronization characteristics of each display screen based on the data source; If the synchronization features are consistent and the difference in update cycles does not exceed the second preset time, the verification result is determined to be that there is no faulty screen. If the synchronization feature values ​​are inconsistent, or the difference in update cycles exceeds the second preset time, the verification result is determined to be a faulty screen.

[0105] In some embodiments, the preset association rules include state dependency rules; the verification module 330 performs cross-validation on the display update information of at least two different displays to obtain the verification result, which is used for: Determine the master and slave displays among multiple displays based on state dependency rules; If the main display screen has been synchronized and the difference between the update time and the synchronization time does not exceed the third preset time, the verification result is determined to be that there is no faulty screen when the corresponding application status information is updated from the specified application on the display screen. If the main display screen fails to synchronize, or the difference between the update time and the synchronization time exceeds a third preset time, the verification result indicates that there is a faulty screen when updating the corresponding application status information from the specified application on the display screen.

[0106] In some embodiments, the fault module 340 determines the fault type corresponding to the fault screen based on the verification result and the cooperation relationship, for the purpose of: The screen to be updated is determined based on the collaboration relationship; If the verification result indicates that the updated screen is a faulty screen and the corresponding updated screen is a non-faulty screen, the fault type is determined as the application display fault type. If the verification results indicate that both the updated screen and the corresponding updated screen are faulty screens, and the fault of the updated screen is caused by an abnormal system service, the fault type will be determined as a system service fault type. If the verification results indicate that both the updated screen and the updated screen are faulty screens, and the data source stops updating, the fault type is determined to be a communication fault type.

[0107] In some embodiments, after determining the fault type corresponding to the fault screen based on the verification result and the cooperation relationship, the fault module 340 is further configured to: If the fault type is an application display fault type, a first control command is sent to the fault screen to terminate and restart the specified application that has malfunctioned based on the first control command; In the case of a system service failure, a second control command is sent to the cockpit controller to restart the corresponding system service based on the second control command; In the event of a communication failure, a third control command is sent to the cockpit controller to restart the corresponding communication link or data service based on the third control command.

[0108] Figure 4 A schematic diagram of the hardware structure of the vehicle provided in an embodiment of this application is shown.

[0109] The vehicle may include a processor 401 and a memory 402 storing computer program instructions.

[0110] Specifically, the processor 401 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0111] Memory 402 may include mass storage for data or instructions. For example, and not limitingly, memory 402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 402 may include removable or non-removable (or fixed) media, or memory 402 may be non-volatile solid-state memory. Memory 402 may be internal or external to the integrated gateway disaster recovery device.

[0112] In one instance, memory 402 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0113] Memory 402 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this disclosure.

[0114] The processor 401 reads and executes computer program instructions stored in the memory 402 to achieve... Figure 1 The display screen association management method in the illustrated embodiment.

[0115] In one example, the vehicle may also include a communication interface 403 and a bus 404. Wherein, as... Figure 4 As shown, the processor 401, memory 402, and communication interface 403 are connected through bus 404 and complete communication with each other.

[0116] The communication interface 403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0117] Bus 404 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 404 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0118] Furthermore, in conjunction with the display screen association management method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the display screen association management methods in the above embodiments.

[0119] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the display screen association management methods described in the above embodiments.

[0120] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0121] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0122] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0123] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in 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, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0124] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for managing the association of display screens, characterized in that, include: The display update information is obtained from multiple displays according to a preset period, wherein the display update information includes display status data, driving status data of the target vehicle, and application status information of each display. Based on preset association rules in a preset association rule base, determine the collaborative relationship between at least two of the multiple display screens in display updates; Cross-validation is performed on the display update information of at least two different display screens to obtain a validation result, wherein the collaborative relationship exists between the different display screens; If the verification result indicates the presence of a faulty screen, the fault type corresponding to the faulty screen is determined based on the verification result and the collaboration relationship.

2. The method according to claim 1, characterized in that, The preset association rules include causal relationship rules; the cross-validation of the display update information of at least two different display screens to obtain the validation result includes: The corresponding result display screen is determined among the multiple display screens based on causal relationship rules; If the specified application in the result display screen is in a first preset application state or the driving status data of the target vehicle meets the first vehicle condition, it is determined whether the display update information of the result display screen is updated within a first preset time. If so, confirm that the verification result indicates there is no faulty screen; If not, the verification result indicates that a faulty screen exists.

3. The method according to claim 1, characterized in that, The preset association rules include data origination rules; the cross-validation of the display update information of at least two different display screens to obtain the validation result includes: At least two displays whose content originates from the same data source are identified as homologous displays. Determine the update cycle and synchronization characteristic quantity of each of the aforementioned source displays based on the data source; If the synchronization feature values ​​are consistent and the difference in the update cycle does not exceed the second preset time, the verification result is determined to be that there is no faulty screen. If the synchronization feature values ​​are inconsistent, or the difference in the update cycle exceeds the second preset time, the verification result is determined to be a faulty screen.

4. The method according to claim 1, characterized in that, The preset association rules include state dependency rules; the cross-validation of the display update information of at least two different display screens to obtain the validation result includes: The master display screen and the slave display screen are determined among the multiple display screens based on the state dependency rules; In the case of updating the application status information corresponding to the designated application on the display screen, if it is detected that the main display screen has completed synchronization and the difference between the update time and the synchronization time does not exceed a third preset time, the verification result is determined to be that there is no faulty screen. If, when updating the application status information corresponding to the specified application on the display screen, the main display screen is found to have not completed synchronization, or the difference between the update time and the synchronization time exceeds a third preset time, the verification result is determined to be a faulty screen.

5. The method according to claim 1, characterized in that, Determining the fault type corresponding to the faulty screen based on the verification result and the collaboration relationship includes: The screen to be updated is determined based on the aforementioned collaborative relationship; If the verification result indicates that the updated screen is the faulty screen and the updated screen corresponding to the updated screen is a non-faulty screen, the fault type is determined as the application display fault type. If the verification result indicates that both the updated screen and the corresponding updated screen are faulty screens, and the fault of the updated screen is caused by a system service anomaly, then the fault type is determined to be a system service fault type. If the verification result indicates that both the updated screen and the updated screen are faulty screens, and the data source stops updating, the fault type is determined to be a communication fault type.

6. The method according to claim 1, characterized in that, After determining the fault type corresponding to the fault screen based on the verification result and the collaboration relationship, the method further includes: If the fault type is an application display fault type, a first control command is sent to the fault screen to terminate and restart the specified application that has malfunctioned based on the first control command; If the fault type is a system service fault type, a second control command is sent to the cockpit controller to restart the corresponding system service based on the second control command; In the case of a communication failure, a third control command is sent to the cockpit controller to restart the corresponding communication link or data service based on the third control command.

7. A display screen association management device, characterized in that, The device includes: The display module is used to acquire display update information from multiple displays according to a preset period, wherein the display update information includes display status data, driving status data of the target vehicle, and application status information of each display. The management module is used to determine the collaborative relationship between at least two of the multiple display screens in display updates based on preset association rules in a preset association rule base. A verification module is used to cross-verify the display update information of at least two different display screens to obtain a verification result, wherein the collaborative relationship exists between the different display screens; The fault module is used to determine the fault type corresponding to the faulty screen based on the verification result and the collaboration relationship when the verification result indicates that a faulty screen exists.

8. A vehicle, characterized in that, The vehicle includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the display screen association management method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed by a processor, implement the display screen association management method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program, which, when executed, implements the display screen association management method as described in any one of claims 1 to 6.

Images