Vehicle instrument screen operating state monitoring method, smart cockpit, and vehicle having same

Abstract

Disclosed in the present invention are a vehicle instrument screen operating state monitoring method, a smart cockpit, and a vehicle having same. The steps of the method comprise: using a microcontroller unit (MCU) in a cockpit-domain system controller (CSC) to periodically query an operating state of a vehicle instrument screen MFD module by means of an IIC communication protocol, and determining whether an interactive message between the MCU and the vehicle instrument screen MFD module is successful; and when it is detected that a heartbeat signal is lost, the MCU performing a hardwire reset on the vehicle instrument screen MFD module by means of a hardwire IO. In summary, according to the present invention, requirements of an automotive safety integrity level are considered, and by means of precise fault detection and timely recovery measures, the safety of the vehicle during operation is significantly improved. The present invention not only meets functional safety requirements but also provides a higher level of safety assurance for drivers and passengers by reducing potential accidents caused by instrument screen failures.

Description

An automobile instrument screen running state monitoring method, intelligent cockpit and vehicle thereof TECHNICAL FIELD

[0001] The present application relates to a monitoring method, intelligent cockpit and vehicle thereof, in particular to an automobile instrument screen running state monitoring method, intelligent cockpit and vehicle thereof. BACKGROUND

[0002] The automobile instrument screen module MFD usually adopts IIC communication. In the original cockpit domain controller CSC controller design, the automobile instrument screen module MFD display is realized by information interaction with the SOC chip of the cockpit domain controller CSC, and the display content includes vehicle body fault information, component running state, multimedia information, etc. In the prior art scheme, the MCU chip of the cockpit domain controller CSC monitors the SOC running state, and when the abnormal SOC state is detected and the instrument display cannot be normally controlled, the MCU also sends a display command to the automobile instrument screen module MFD through the IIC protocol. Under this architecture, there is a disadvantage: the information sending end (the cockpit domain controller CSC side) is designed to be more reliable, and a redundant design under the backup of the SOC and the MCU is adopted, but once the receiving end automobile instrument screen module MFD side runs an error (such as a crash, a runaway, an initialization failure, etc.), the display will be directly invalid, and the alarm information cannot be notified to the driver - the above problems need to be improved. SUMMARY

[0003] The purpose of the present application is to provide an automobile instrument screen running state monitoring method, intelligent cockpit and vehicle thereof, which proposes a corresponding technical solution for the technical problem that the automobile instrument screen module error will cause the display to be invalid, and solves the shortcomings of the prior art.

[0004] The present application provides the following scheme:

[0005] An automobile instrument screen running state monitoring method applied to an automobile instrument screen running state monitoring system, comprising:

[0006] Periodically querying the running state of the automobile instrument screen module MFD through the IIC communication protocol by using the microcontroller unit MCU in the cockpit domain controller CSC;

[0007] By querying the E2E state word of the automobile instrument screen module MFD, it is judged whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful;

[0008] When the running state of the automobile instrument screen module MFD is detected to be abnormal, the microcontroller unit MCU sends a soft reset request to the automobile instrument screen module MFD through the IIC protocol, and the automobile instrument screen module MFD executes self-reset after receiving the request;

[0009] The internal logic of the microcontroller unit MCU side processing includes monitoring the running state of the automobile instrument screen module MFD and sending a reset request, configuring the hard-wire reset strategy between the cabin domain controller CSC and the automobile instrument screen module MFD, and the microcontroller unit MCU periodically queries the heartbeat signal sent by the automobile instrument screen module MFD;

[0010] When the loss of the heartbeat signal is detected, the microcontroller unit MCU performs a hard-wire reset on the automobile instrument screen module MFD through a hard-wire IO, or:

[0011] When the heartbeat signal is lost and the IIC communication fails, the microcontroller unit MCU enables the hard-wire IO to perform a hard-wire reset on the MFD.

[0012] Further, the E2E state word of the automobile instrument screen module MFD is queried to determine whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful, specifically:

[0013] When the E2E state word is 1, it indicates that the microcontroller unit MCU and the automobile instrument screen module MFD interact successfully, and when the E2E state word is 0, it indicates that the microcontroller unit MCU and the automobile instrument screen module MFD interact unsuccessfully.

[0014] Further, the E2E state word of the automobile instrument screen module MFD is queried to determine whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful, further comprising:

[0015] The message livecounter mechanism is used to monitor the dynamic running state of the automobile instrument screen module MFD to identify the stuck or dead state;

[0016] When the running state of the automobile instrument screen module MFD is detected to be abnormal, the MCU sends a soft reset request to the automobile instrument screen module MFD through the IIC protocol;

[0017] After the automobile instrument screen module MFD receives the request, it performs a self-reset operation.

[0018] Further, the message livecounter mechanism specifically includes:

[0019] Real-time detection of communication interaction between the microcontroller MCU and the automobile instrument screen module MFD, and storage and recording when communication interaction is detected;

[0020] Further comprising: judging the self-checking state of the automobile instrument screen module MFD through a screen working state signal, wherein the screen working state signal specifically includes: a state of 1 indicating normal, and a state of 2 indicating abnormal.

[0021] Further, the heartbeat signal is specifically:

[0022] A periodic signal sent by the automobile instrument screen module MFD to the cabin domain controller CSC is used to confirm that the automobile instrument screen module MFD is running normally and is in communication connection with the cabin domain controller CSC.

[0023] An automobile instrument screen running state monitoring system is applied to an automobile instrument screen running state monitoring method, and comprises:

[0024] An automobile instrument screen module running state query module periodically queries the running state of the automobile instrument screen module MFD through the IIC communication protocol by using the microcontroller unit MCU in the cabin domain controller CSC;

[0025] The E2E state word of the automobile instrument screen module MFD is queried to determine whether the interactive message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful;

[0026] An automobile instrument screen module abnormal running state processing module, when detecting that the running state of the automobile instrument screen module MFD is abnormal, sends a soft reset request to the automobile instrument screen module MFD through the IIC protocol by the microcontroller unit MCU, and the automobile instrument screen module MFD performs self-resetting after receiving the request;

[0027] The internal logic of the microcontroller unit MCU side processing includes monitoring of the running state of the automobile instrument screen module MFD and sending of the reset request, a hard-wire reset strategy between the cabin domain controller CSC and the automobile instrument screen module MFD is configured, and the microcontroller unit MCU periodically queries the heartbeat signal sent by the MFD;

[0028] An automobile instrument screen module recovery module, when detecting that the heartbeat signal is lost, performs hard-wire reset on the automobile instrument screen module MFD through the hard-wire IO by the microcontroller unit MCU, or:

[0029] When the heartbeat signal is lost and the IIC communication fails, the microcontroller unit MCU enables the hard-wire IO to perform hard-wire reset on the automobile instrument screen module MFD.

[0030] An intelligent cabin, the automobile instrument screen and the automobile instrument screen running state monitoring system establish a connection, and execute the automobile instrument screen running state monitoring method.

[0031] An electronic device, characterized in that, comprising: a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface, the memory complete mutual communication through the communication bus; the memory stores a computer program, when the computer program is executed by the processor, makes the processor execute the steps of the method.

[0032] A computer-readable storage medium stores a computer program executable by an electronic device, which when running on the electronic device, causes the electronic device to perform the steps of the method.

[0033] A vehicle is provided with the intelligent cabin.

[0034] Compared with the prior art, the present application has the following advantages:

[0035] The present application provides an innovative fault detection and recovery mechanism based on the functional safety instrument screen monitoring scheme. Through real-time monitoring of the heartbeat signal and running state signal of the automobile instrument screen module MFD by the microcontroller unit MCU, the present application can timely identify and respond to abnormal states of the automobile instrument screen module MFD, thereby significantly improving the reliability and safety of the system. Specifically, when the microcontroller unit MCU detects that the heartbeat signal of the automobile instrument screen module MFD is normal but the running state is abnormal, a soft reset instruction is sent through IIC communication, which can quickly and effectively restore the function of the automobile instrument screen module MFD, avoiding potential risks caused by display failure.

[0036] The present application can detect the situation where the heartbeat signal of the automobile instrument screen module MFD is completely lost, and determine that it may have encountered a more serious failure. At this time, the microcontroller unit MCU will immediately perform a more direct reset operation through the hard-wired IO, ensuring that even when the IIC communication link is problematic, the automobile instrument screen module MFD can be quickly restored to a normal working state. This double protection mechanism significantly improves the robustness of the automobile instrument screen and intelligent cabin system in the face of various failure conditions, ensuring that the driver can continuously receive critical alarm information.

[0037] In summary, the present application takes into account the requirements of the Automotive Safety Integrity Level (ASIL), significantly improves the safety of the automobile during operation through accurate fault detection and timely recovery measures, not only meets the functional safety requirements, but also reduces potential accidents caused by instrument screen failure, providing higher level of safety protection for drivers and passengers. BRIEF DESCRIPTION OF DRAWINGS

[0038] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings needed to be used in the specific embodiments or prior art description. Obviously, the drawings described below are some embodiments of the present application, and those skilled in the art can obtain other drawings according to these drawings without creative labor.

[0039] Fig. 1 is a flow chart of the automobile instrument screen running state monitoring method.

[0040] Fig. 1A is a flow chart of the optimization technical solution of step S2.

[0041] Fig. 1B is a flow chart of the optimization technical solution of step S21.

[0042] Fig. 2 is an architecture diagram of the automobile instrument screen running state monitoring system.

[0043] Fig. 3 is a framework diagram of the instrument screen module MFD of the prior art.

[0044] Fig. 4 is a framework diagram containing the instrument screen module MFD monitoring strategy.

[0045] Fig. 5 is a flow chart of querying the automobile instrument screen module MFD running state for monitoring whether the MFD is running normally.

[0046] Fig. 6 is a flow chart of querying the automobile instrument screen module MFD running state.

[0047] Fig. 7 is a hard-wire reset strategy interaction timing diagram between the cabin domain controller CSC and the automobile instrument screen module MFD.

[0048] Fig. 8 is a flow chart of the MCU side actively enabling the hard-wire IO to perform hard-wire reset on the automobile instrument screen module MFD.

[0049] Fig. 9 is a structural schematic diagram of an electronic device. DETAILED DESCRIPTION

[0050] The technical solutions of the present application will be described clearly and completely below in conjunction with the drawings. Obviously, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0051] The automobile instrument screen running state monitoring method shown in Fig. 1 is applied to an automobile instrument screen running state monitoring system and includes the following steps.

[0052] Step S1: periodically querying the running state of the automobile instrument screen module MFD by the microcontroller unit MCU in the cabin domain controller CSC through the IIC communication protocol;

[0053] Step S2: judging whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful by querying the E2E state word of the automobile instrument screen module MFD.

[0054] Step S3, when detecting that the abnormal running state of the automobile instrument screen module MFD, the microcontroller unit MCU sends a soft reset request to the automobile instrument screen module MFD through the IIC protocol, and the automobile instrument screen module MFD performs self-resetting after receiving the request;

[0055] Step S4, the internal logic of the microcontroller unit MCU side processing includes monitoring the running state of the automobile instrument screen module MFD and sending a reset request, configuring the hard-wire reset strategy between the cabin domain controller CSC and the automobile instrument screen module MFD, and the microcontroller unit MCU periodically queries the heartbeat signal sent by the automobile instrument screen module MFD;

[0056] Step S5, when detecting that the heartbeat signal is lost, the microcontroller unit MCU performs hard-wire reset on the automobile instrument screen module MFD through the hard-wire IO, so as to restore the alarm icon display function, or:

[0057] Step S6, when the heartbeat signal is lost and the IIC communication fails, the microcontroller unit MCU enables the hard-wire IO to perform hard-wire reset on the automobile instrument screen module MFD. The hard-wire IO refers to the input / output (Input / Output) hard-wire, also known as GPIO (General Purpose Input / Output). The hard-wire IO is used to connect the communication interface between the microcontroller and the external device. When the heartbeat signal is lost and the IIC communication fails, the MCU will perform hard-wire reset on the automobile instrument screen module MFD through the hard-wire IO, that is, by changing the level state of a specific pin to restart or reset the automobile instrument screen module MFD module, so as to ensure that the automobile instrument screen module MFD runs normally and keeps communication connection with the CSC.

[0058] Steps S1 to S6 construct a multi-level and high-reliability monitoring and fault recovery method to ensure that the instrument screen module MFD in the intelligent cockpit of the electric vehicle can normally display key information in any case. The implementation of the automobile instrument screen running state monitoring method in steps S1 to S6 can realize comprehensive monitoring of the instrument screen module. The MCU continuously monitors the running state of the MFD by using periodic IIC communication, and ensures that any abnormality can be found in time. When performing fault processing, the MCU can evaluate whether the interaction between the MFD and the MCU is successful and the self-checking state of the MFD itself by using the E2E state word and the screen working state information, and at the same time realizes a soft reset mechanism. When the MFD running state is abnormal but the heartbeat signal is normal, the MCU sends a soft reset request through the IIC protocol to allow the MFD to recover itself, thereby providing a non-invasive and fast fault recovery method. The internal logic of the MCU not only monitors the running state of the MFD, but also is responsible for sending a reset request and configuring a hard-wire reset strategy to cope with more serious fault conditions. By periodically querying the heartbeat signal sent by the MFD through the MCU, the key indicators of the normal operation of the MFD are confirmed. When the heartbeat signal is lost and the IIC communication fails, the MCU immediately enables the hard-wire IO to reset the MFD by hard-wire, which is a more direct and powerful recovery means to ensure that the MFD can quickly recover to the normal working state.

[0059] The multi-level and high-reliability monitoring and fault recovery method provided by steps S1 to S6 has high reliability. Through the multi-level monitoring and recovery mechanism, the reliability of the MFD is significantly improved, the driving risk caused by display failure is reduced, and the fast fault recovery function is also realized. Whether it is a soft reset or a hard-wire reset, the MFD fault can be quickly responded to, and the influence of the fault on driving safety is minimized.

[0060] The hard-wire reset strategy of the application is particularly suitable for handling serious fault conditions, ensuring that the function of the MFD can be quickly restored even when the communication link is completely disabled, and ensuring driving safety. The overall scheme design meets the requirements of Automotive Safety Integrity Level (ASIL), and provides high-standard functional safety protection for the intelligent cockpit system of the electric vehicle.

[0061] In summary, steps S1 to S6 ensure that the MFD can stably operate in various situations through a comprehensive monitoring and fault recovery method, thereby significantly improving the safety and reliability of the intelligent cockpit system.

[0062] Preferably, the E2E state word of the automobile instrument screen module MFD is queried to determine whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful, specifically:

[0063] E2E status word is 1, indicating that the microcontroller unit MCU and the automotive instrument screen module MFD interaction is successful, E2E status word is 0, indicating that the microcontroller unit MCU and the automotive instrument screen module MFD interaction fails.

[0064] As shown in Figure 1A, preferably, in the optimization technical solution of step S2, the method further comprises:

[0065] Step S21, using the message livecounter mechanism to monitor the dynamic running state of the automotive instrument screen module MFD, to identify the stuck or dead state;

[0066] Step S22, when detecting that the automotive instrument screen module MFD running state is abnormal, the MCU sends a soft reset request to the automotive instrument screen module MFD through the IIC protocol;

[0067] Step S23, the automotive instrument screen module MFD receives the request and performs a self-reset operation.

[0068] Steps S21 to S23 ensure the continuous and stable operation of the automotive instrument screen module MFD through real-time dynamic monitoring and intelligent fault recovery process, thereby providing continuous key information display for the driver,

[0069] The optimization technical solution of steps S21 to S23 ensures the continuous and stable operation of the automotive instrument screen module MFD through real-time dynamic monitoring and intelligent fault recovery process, thereby providing continuous key information display for the driver.

[0070] The optimization technical solution of steps S21 to S23 uses the message livecounter mechanism for dynamic state monitoring, the MCU can monitor the dynamic running state of the MFD in real time, track the value change of the message livecounter in real time, and identify whether the MFD appears stuck or dead state, thereby realizing continuous monitoring of the MFD running state. When the MCU identifies that the MFD running state is abnormal through the message livecounter, the system will automatically trigger the fault handling process, realize intelligent fault detection, and the result of intelligent evaluation and response of the MFD state.

[0071] The MCU sends a soft reset request to the MFD through the IIC protocol, realizes the fault recovery means, allows the MFD to restore its display function without restarting the entire system, and reduces the system recovery time.

[0072] Finally, the MFD receives a soft reset request and performs a self-reset operation, enabling the MFD to have self-diagnosis and recovery capabilities, further improving the reliability of the system.

[0073] As shown in FIG. 1B, in step S21, the message livecounter mechanism is specifically:

[0074] Step S211, real-time detection of communication interaction between the microcontroller MCU and the automobile instrument screen module MFD, and storage and recording when communication interaction is detected;

[0075] Step S212, judging the self-checking state of the automobile instrument screen module MFD through the screen working state signal, wherein the screen working state signal is specifically: state 1 indicates normal, and state 2 indicates abnormal.

[0076] Steps S211 and S212 are based on the optimization technical solution provided in step S21, and steps S211 and S212 realize dynamic monitoring of the running state of the automobile instrument screen module MFD through real-time communication interaction detection and self-checking state judgment, ensuring that the automobile instrument screen module MFD can respond and handle possible abnormal situations in time.

[0077] The optimization technical solution provided in steps S211 and S212 has real-time, self-checking and fault prevention capabilities, realizes dynamic monitoring of the running state of the automobile instrument screen module MFD through real-time communication interaction detection and self-checking state judgment, and ensures that the automobile instrument screen module MFD can respond and handle possible abnormal situations in time:

[0078] Through real-time detection of communication interaction between MCU and MFD, the system can immediately capture any abnormal communication behavior, thereby quickly responding. The self-checking state signal of the MFD provides a clear indication of whether it is running normally or has an abnormality, which helps the MCU make accurate fault judgment, and then prevents faults from occurring through the message livecounter mechanism to identify potential running problems before the problem becomes serious.

[0079] Principle of message livecounter mechanism:

[0080] The message livecounter mechanism is a dynamic monitoring method with communication interaction detection function and self-checking state recording function:

[0081] Communication interaction detection: MCU continuously monitors the communication interaction between the MCU and the MFD. Whenever valid communication is detected, the value of livecounter is updated or increased, indicating that the MFD is responding to the MCU query.

[0082] Self-check status record: After each self-check, the MFD sends a status signal to the MCU. This signal indicates the result of the MFD's self-check, whether it is normal (state 1) or abnormal (state 2).

[0083] The application and implementation of the message livecounter mechanism in steps S211 and S212 are as follows:

[0084] Step S211: The MCU real-time detects the IIC communication between the MCU and the MFD. Whenever the MCU successfully receives a response from the MFD, the value of livecounter is updated. This updating is continuous, and as long as the MFD responds normally, livecounter will continue to increase, thus ensuring that the value of livecounter reflects the real-time running state of the MFD.

[0085] Step S212: The MCU receives the screen working state signal sent by the MFD, and judges the self-check state of the MFD according to the value of the signal (1 for normal, 2 for abnormal). If the value of livecounter is no longer updated, even if the MFD reports a normal state, the MCU can reasonably suspect that the MFD may have been stuck or dead, because a normal MFD will continue to update livecounter.

[0086] Through the message livecounter mechanism, the MCU can not only monitor whether the MFD is responding normally, but also identify whether the MFD has stopped updating or responding slowly through the change of livecounter, so as to take corresponding measures, such as sending a soft reset request to restore the normal operation of the MFD. The optimization technical solution of steps S211 and S212 based on the livecounter mechanism significantly improves the self-diagnosis ability and fault recovery speed of the system, and enhances the reliability and safety of the intelligent cockpit system.

[0087] Preferably, the heartbeat signal is specifically a periodic signal sent by the automobile instrument screen module MFD to the cockpit domain controller CSC, used to confirm that the automobile instrument screen module MFD is running normally and maintaining communication connection with the cockpit domain controller CSC.

[0088] The main purpose of the heartbeat signal as a periodic signal is to detect and confirm whether the automobile instrument screen module MFD is working normally. By sending signals regularly, potential problems or faults can be discovered in time, and corresponding measures can be taken for repair or maintenance.

[0089] The heartbeat signal maintains communication connection with the cockpit domain controller CSC, which can confirm that the communication link is smooth: when the automobile instrument screen module MFD can successfully send the periodic signal to the cockpit domain controller CSC and get a response, it means that the communication link between the two is smooth and reliable.

[0090] Heartbeat signals can also detect abnormal situations: if the automotive instrument panel module MFD cannot normally send or receive responses from the cabin domain controller CSC, there may be a fault or abnormal situation. By monitoring these abnormal situations, problems can be identified in time and appropriate actions can be taken.

[0091] Heartbeat signals can ultimately improve system stability: regular status checks help improve the stability and reliability of the entire system, including the automotive instrument panel module and the cabin domain controller.

[0092] For the method steps disclosed in the above embodiments, the method steps are described as a series of action combinations for the purpose of simple description, but those skilled in the art should know that the embodiments of the present application are not limited by the order of the described actions, because according to the embodiments of the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily necessary for the embodiments of the present application.

[0093] Any process or method described by a flowchart or otherwise described herein can be understood as a representation of code modules, segments, or portions of code that include one or more executable instructions for performing a certain function or a step in the process, and the scope of preferred embodiments of the present application includes other implementations that can not be described by the order of the steps shown or discussed, including implementations that perform functions according to the functions involved in a substantially simultaneous manner or in reverse order, or according to a cyclic, branching, or other procedure structure, executing computer instructions and implementing corresponding functions, which those skilled in the art can understand as a matter of course when implementing the embodiments of the present application.

[0094] The automotive instrument panel operating state monitoring system shown in FIG. 2 is applied to implement the automotive instrument panel operating state monitoring method, which comprises:

[0095] The automotive instrument panel module operating state query module periodically queries the operating state of the automotive instrument panel module MFD through the IIC communication protocol by using the microcontroller unit MCU in the cabin domain controller CSC;

[0096] By querying the E2E status word of the automotive instrument panel module MFD, it is determined whether the interactive message between the microcontroller unit MCU and the automotive instrument panel module MFD is successful;

[0097] The automotive instrument panel module abnormal operating state processing module, when detecting that the automotive instrument panel module MFD operating state is abnormal, the microcontroller unit MCU sends a soft reset request to the automotive instrument panel module MFD through the IIC protocol, and the automotive instrument panel module MFD performs self-reset after receiving the request;

[0098] The internal logic of the microcontroller unit MCU side processing includes monitoring of the running state of the automobile instrument screen module MFD and sending of a reset request, configuring a hard-wire reset strategy between the cabin domain controller CSC and the automobile instrument screen module MFD, and the microcontroller unit MCU periodically inquires the heartbeat signal sent by the automobile instrument screen module MFD;

[0099] The automobile instrument screen module recovery module, when the heartbeat signal loss is detected, the microcontroller unit MCU performs a hard-wire reset on the automobile instrument screen module MFD through a hard-wire IO; to restore the alarm icon display function, or:

[0100] When the heartbeat signal loss and IIC communication failure, the microcontroller unit MCU enables the hard-wire IO to perform a hard-wire reset on the automobile instrument screen module MFD.

[0101] The above-described embodiments of the system are merely illustrative, for example: wherein each functional module, unit or subsystem in the system can or can not be physically separated, or can or can not be a physical unit, i.e. can be located in the same place, or can be distributed to multiple different systems and their subsystems or modules. Those skilled in the art can select part or all of the functional modules, units or subsystems to achieve the purpose of the embodiments of the present application according to actual needs, and those skilled in the art can understand and implement without creative labor.

[0102] As shown in Fig. 3, the frame diagram of the prior art automobile instrument screen module MFD, the automobile instrument screen module MFD mostly uses iic communication. In the original design of the cabin domain controller CSC controller, the automobile instrument screen module MFD display is realized by information interaction with the SOC chip under the CSC, and the display content includes vehicle fault information, component running state, multimedia information, etc. In this scheme, the MCU chip under the CSC will monitor the SOC running state, and when the SOC state is abnormal and cannot normally control the instrument display, the MCU will also send a display command to the automobile instrument screen module MFD through the iic protocol. The existing technology has the following shortcomings: the information sending end (CSC side) design is more reliable, and a redundant design under the backup of SOC and MCU is adopted, but once the receiving end MFD side runs incorrectly (such as dead, runaway, initialization failure, etc.), it will directly cause the display to fail, and the alarm information cannot be notified to the driver.

[0103] As shown in Fig. 4, the frame diagram containing the instrument screen module MFD monitoring strategy, on the basis of the prior art, a hard-wire IO recovery mechanism is added.

[0104] The query MFD running state shown in FIG. 5 is a flowchart for monitoring whether the MFD is running normally: when the iic communication between the MFD and the MCU is normal, the MCU periodically queries the MFD running state; the running state is obtained through corresponding bytes of the iic protocol, and the running state is determined by combining multiple signals:

[0105] (1) E2E state word, representing whether the screen side check MCU interaction message is successful. 0-failure, 1-success;

[0106] (2) Screen working state, representing the screen self-checking state, 1-normal, 2-exception, and other-invalid value;

[0107] (3) Message livecounter, the value is dynamically +1 every time the message, and the MCU monitors whether the screen enters a state card stagnation or a dead state through the signal.

[0108] When any one of the above three conditions is abnormal, the MCU determines that the screen running state is abnormal, sends a soft reset request through iic, and the MFD responds to the instruction to complete the self-reset.

[0109] From the process of querying the MFD running state for monitoring whether the MFD is running normally, it can be seen that the embodiment utilizes the IIC communication protocol and multiple signals to ensure the normal running of the automotive instrument screen module (MFD), and through periodic query and signal analysis, the running state of the MFD can be evaluated in real time, and corresponding measures can be taken when an exception is detected, so that real-time monitoring and evaluation can be realized, the running state of the MFD is determined from multiple dimensions (E2E state word, screen working state, and message livecounter three signals), the accuracy of fault detection is improved, potential faults can be found and prevented in time, and the stability, safety and reliability of the intelligent cockpit system are significantly improved.

[0110] As shown in FIG. 6, the embodiment provides a process of querying the MFD running state, specifically: querying the MFD running state feedback, detecting whether the running state is abnormal, if the running state is abnormal, sending an MFD soft reset request, and if no running state exception is found, continuing to query the MFD running state feedback.

[0111] As shown in FIG. 7, the CSC and MFD hard reset strategy interaction timing sequence, the MCU periodically queries the heartbeat signal sent by the MFD, and when the heartbeat signal is lost, it indicates that the MFD display has failed.

[0112] The MCU side actively enables the hard-wired IO to reset the MFD by a hard-wired reset process as shown in FIG. 8. In this scenario, the normal iic communication interaction has also failed due to the loss of the heartbeat signal. In this scenario, the reset of the iic path no longer takes effect, and the MCU side actively enables the hard-wired IO to reset the MFD in order to attempt to restore the alarm icon display function.

[0113] As shown in FIG. 9, the application provides an intelligent cockpit, an electronic device and a storage medium corresponding to the automobile instrument screen operation state monitoring method and system.

[0114] An intelligent cockpit, the automobile instrument screen is connected with the automobile instrument screen operation state monitoring system, and the automobile instrument screen operation state monitoring method is executed.

[0115] An electronic device, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method.

[0116] A computer readable storage medium, which stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method.

[0117] A vehicle, wherein the intelligent cockpit is arranged in the vehicle.

[0118] As shown in FIG. 9, the device 600 comprises a computing unit 601, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory 602 (ROM) or a computer program loaded from a storage unit 608 to a random access memory 603 (RAM). In the RAM, various programs and data required for the operation of the device 600 can also be stored. The computing unit 601, the ROM and the RAM are connected to each other through a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0119] A plurality of components in the device 600 are connected to the I / O interface 605, including an input unit 606 such as a keyboard, a mouse, etc., an output unit 607 such as various types of displays, a loudspeaker, etc., a storage unit 608 such as a magnetic disk, an optical disk, etc., and a communication unit 609 such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 609 allows the device 600 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0120] The computing unit 601 can be various general and / or special purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs various methods and processes described above. For example, in some embodiments, the car instrument panel running status monitoring method can be implemented as a computer software program tangibly embodied in a machine-readable medium, such as the storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed onto the device 600 via the ROM 602 and / or the communication unit 609. When the computer program is loaded onto the RAM 603 and executed by the computing unit 601, one or more steps of the car instrument panel running status monitoring method described above can be performed. Alternatively, in other embodiments, the computing unit 601 can be configured to perform the car instrument panel running status monitoring method by other any suitable means, such as by means of firmware.

[0121] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a complex programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0122] Program code for carrying out methods of the present application can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general or special purpose computer, special purpose computer, or other automotive instrument panel running status monitoring system, such that the program code, when executed by the processor or controller, causes the functions / operations specified in the flow charts and / or block diagrams to be implemented. The program code can execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

[0123] In the context of the present application, a machine-readable medium can be a tangible medium that can contain or store program for use by or in connection with an instruction execution system, apparatus, or device. Machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable medium can include, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of machine-readable storage medium would include one or more lines of electrical wire, portable computer diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination of the foregoing.

[0124] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0125] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), and the Internet.

[0126] The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server can arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The server can be a cloud server, a server of a distributed system, or a server combined with a blockchain.

[0127] It should be understood that the various forms of flow illustrated above can be used to reorder, add, or delete steps. For example, the steps described in the present disclosure can be performed in parallel, in series, or in a different order, as long as the desired results of the technology disclosed in the present disclosure can be achieved, and the present disclosure is not limited herein.

[0128] The technical features of the above embodiments can be combined in any manner. In order to make the description simple, all possible combinations of the technical features in the above embodiments are not described herein, however, as long as the combinations of the technical features do not contradict each other, they should be considered as being within the scope of the present disclosure.

[0129] In addition, those skilled in the art will understand that although some embodiments described herein include certain features of other embodiments but not others, combinations of features of the different embodiments are to be construed as being within the scope of the present disclosure and forming different embodiments. For example, any one of the embodiments claimed in the claims can be used in any combination of the embodiments of the present disclosure.

[0130] In the description of the present disclosure, the description of the terms "one embodiment", "an example", "a specific example", and the like means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. In the present disclosure, the illustrative description of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0131] In addition, the technical solutions of the various embodiments of the present disclosure can be combined with each other, but must be based on the fact that a person skilled in the art can implement it, when the combination of technical solutions contradicts each other or cannot be implemented, it should be considered that the combination of technical solutions does not exist and is not within the protection scope required by the present disclosure.

[0132] All features disclosed in the present specification, or all steps of the methods or processes disclosed, can be combined in any manner, except for mutually exclusive features and / or steps. Any feature disclosed in the present specification can be replaced by other equivalent or similarly purposed alternative features, unless specifically stated otherwise. That is, each feature is merely an example of a range of equivalent or similar features unless specifically stated otherwise. Throughout the specification, like reference numerals indicate like elements.

[0133] Those skilled in the art can understand that the modules in the device in the embodiments can be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and furthermore can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive, all combinations of all features disclosed in this specification (including the corresponding claims, abstract and drawings) and all processes or units of any method or apparatus disclosed herein can be adopted. Unless explicitly stated otherwise, each feature disclosed in this specification (including the corresponding claims, abstract and drawings) can be replaced by an alternative feature providing the same, equivalent or similar purpose.

[0134] Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit it; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that: it can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacement for part or all of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for monitoring the running state of an automobile instrument screen, applied to a system for monitoring the running state of an automobile instrument screen, characterized in that, The application relates to a method for monitoring the running state of a motor vehicle instrument panel module (MFD) by a microcontroller unit (MCU) in a cockpit domain controller (CSC). The method comprises the following steps: periodically querying the running state of the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU) in the cockpit domain controller (CSC) through an IIC communication protocol; judging whether the interactive message between the microcontroller unit (MCU) and the motor vehicle instrument panel module (MFD) is successful by querying the E2E state word of the motor vehicle instrument panel module (MFD); when detecting that the running state of the motor vehicle instrument panel module (MFD) is abnormal, sending a soft reset request to the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU) through the IIC protocol, and executing a self-reset operation by the motor vehicle instrument panel module (MFD) after receiving the request; the internal logic of the microcontroller unit (MCU) side processing comprises monitoring the running state of the motor vehicle instrument panel module (MFD) and sending a reset request, configuring a hard-wire reset strategy between the cockpit domain controller (CSC) and the motor vehicle instrument panel module (MFD), and periodically querying the heartbeat signal sent by the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU); 2. The method of claim 1, wherein, when detecting that the heartbeat signal is lost, performing a hard-wire reset on the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU) through a hard-wire IO. The step of judging whether the interactive message between the microcontroller unit (MCU) and the motor vehicle instrument panel module (MFD) is successful by querying the E2E state word of the motor vehicle instrument panel module (MFD) comprises the following steps:

3. The method of claim 1, wherein, when the E2E state word is 1, it indicates that the interactive message between the microcontroller unit (MCU) and the motor vehicle instrument panel module (MFD) is successful; and when the E2E state word is 0, it indicates that the interactive message between the microcontroller unit (MCU) and the motor vehicle instrument panel module (MFD) fails. The step of judging whether the interactive message between the microcontroller unit (MCU) and the motor vehicle instrument panel module (MFD) is successful by querying the E2E state word of the motor vehicle instrument panel module (MFD) further comprises the following steps: monitoring the dynamic running state of the motor vehicle instrument panel module (MFD) by a message livecounter mechanism, so as to identify a stuck or dead state; when detecting that the running state of the motor vehicle instrument panel module (MFD) is abnormal, sending a soft reset request to the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU) through the IIC protocol; 4. The method of claim 3, wherein, after receiving the request, executing a self-reset operation by the motor vehicle instrument panel module (MFD). The message livecounter mechanism comprises the following steps: real-time detecting the communication interaction between the microcontroller (MCU) and the motor vehicle instrument panel module (MFD), and storing and recording the communication interaction when the communication interaction is detected; 5. The method of claim 1, wherein, the method further comprises judging the self-checking state of the motor vehicle instrument panel module (MFD) by a screen working state signal, wherein the screen working state signal is as follows: the state is 1, indicating normal; and the state is 2, indicating abnormal. The heartbeat signal comprises the following steps:

6. A system for monitoring the running state of an automobile instrument screen, applied to realize a method for monitoring the running state of an automobile instrument screen, characterized in that, the motor vehicle instrument panel module (MFD) sends a periodic signal to the cockpit domain controller (CSC), so as to confirm that the motor vehicle instrument panel module (MFD) normally operates and keeps communication connection with the cockpit domain controller (CSC). The application relates to a method for monitoring the running state of a motor vehicle instrument panel module (MFD) by a microcontroller unit (MCU) in a cockpit domain controller (CSC). The method comprises the following steps: periodically querying the running state of the motor vehicle instrument panel module (MFD) by the microcontroller unit (MCU) in the cockpit domain controller (CSC) through an IIC communication protocol; By querying the E2E status word of the automobile instrument screen module MFD, it is determined whether the interaction message between the microcontroller unit MCU and the automobile instrument screen module MFD is successful; When it is detected that the automobile instrument screen module MFD is in an abnormal running state, the microcontroller unit MCU sends a soft reset request to the automobile instrument screen module MFD through the IIC protocol, and the automobile instrument screen module MFD performs self-resetting after receiving the request; The internal logic of the microcontroller unit MCU side processing includes monitoring the running state of the automobile instrument screen module MFD and sending a reset request, configuring the hard-wire reset strategy between the cabin domain controller CSC and the automobile instrument screen module MFD, and the microcontroller unit MCU periodically queries the heartbeat signal sent by the MFD; When it is detected that the heartbeat signal is lost, the microcontroller unit MCU performs a hard-wire reset on the automobile instrument screen module MFD through a hard-wire IO.

7. An intelligent cabin, characterized in that, The automobile instrument screen is connected with the automobile instrument screen running state monitoring system of claim 6, and executes the automobile instrument screen running state monitoring method of any one of claims 1 to 5.

8. An electronic device, comprising: It comprises: A processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory complete mutual communication through the communication bus; the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method of any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, It stores a computer program executable by an electronic device, and when the computer program runs on the electronic device, the electronic device executes the steps of the method of any one of claims 1 to 6.

10. A vehicle characterized by comprising: The vehicle is provided with the intelligent cabin of claim 7.

Images