Instrument screen fault monitoring method, device and equipment and readable storage medium
By using the lock step core function on the target microcontroller to detect instrument screen failure and perform fault recovery, the problem of QM SOC misjudgment of fault status is solved, and the accurate monitoring of instrument screen failure and the functional safety requirements of the smart cockpit are achieved.
Patent Information
- Application Number
- CN202411277962.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-12
- Publication Date
- 2025-06-06
AI Technical Summary
In the prior art, when the QM SOC monitors the instrument screen failure, the kernel does not support the lock step core, resulting in misjudging the screen fault status and failing to transmit the fault status to the entire vehicle in time, affecting the functional safety needs of the smart cockpit.
Avoid misjudgment by obtaining instrument screen data on the target microcontroller and using its lock step core function to perform fault detection. For faulty screens, perform fault recovery control to ensure that the screen is displayed normally.
It realizes accurate monitoring of instrument screen faults, avoids fault misjudgment problems, and ensures the functional safety requirements of the smart cockpit.
Smart Images
Figure CN120103742A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the technical field of vehicle-mounted terminal fault control, and in particular to an instrument screen fault monitoring method, device, equipment and readable storage medium. Background Art
[0002] With the rapid development of the "four modernizations" of automobiles, the electronic and electrical architecture of the entire vehicle is becoming more and more complex. Therefore, in order to avoid the probability of automobile errors under complex architecture design, safety naturally becomes an important basic requirement for intelligent vehicle design; among them, the purpose of functional safety design is to achieve through electronic and electrical design that when errors occur in various modules of the entire vehicle, it is necessary to warn the driver within a specified time, so that the driver has enough time to reach a safe state.
[0003] In recent years, the smart cockpit, as a human-machine interaction unit, can notify the driver of errors in the electronic control units of the whole vehicle through the instrument display screen. Therefore, it is necessary to make it realize the functional safety requirements assigned to the whole vehicle; among them, its functional safety requirements are usually designed to correctly display the fault display light of the instrument, and the safety level is ASIL B (Automotive Safety Integrity Level B, used to assess the risk level of functional safety of electronic and electrical systems in road vehicles); it can be seen that once the smart cockpit cannot correctly display to notify the whole vehicle, it may cause the driver to be unable to obtain key information in time, which will affect the driving decision. It is understandable that one of the links of whether the smart cockpit displays correctly is whether the instrument screen works normally. If the screen fails, it will cause abnormal display, so that the goal of correct display cannot be achieved. Therefore, it is very critical to effectively monitor the failure of the instrument screen.
[0004] In the related art, the monitoring of whether the screen has abnormal faults is usually carried out by SOC (System on Chip) to diagnose the screen fault; however, some QM (Quality Management, non-functional safety) SOCs (such as 8155 chips) do not support lock-step cores during monitoring, which may lead to incorrect judgment of the screen fault status. That is, the screen has an abnormal display fault, but the QM SOC mistakenly judges that the screen has not had an abnormal display fault, so that the screen fault status cannot be transmitted to the whole vehicle in time, thereby failing to meet the functional safety requirements of the smart cockpit. Summary of the invention
[0005] The present application provides an instrument screen fault monitoring method, device, equipment and readable storage medium, which can accurately monitor the instrument screen faults in the smart cockpit to avoid the problem of misjudgment of instrument screen faults, thereby effectively realizing the functional safety requirements of the smart cockpit.
[0006] In a first aspect, an embodiment of the present application provides a method for monitoring a meter screen fault, wherein the method is applied to a target microcontroller and comprises the following steps:
[0007] Acquire target screen data, and detect whether the target screen has a fault based on the target screen data;
[0008] Based on the detection result and when the detection result is yes, the control performs fault recovery to achieve normal display of the target screen.
[0009] In combination with the first aspect, in one implementation, when the detection result is yes, controlling fault recovery includes:
[0010] When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data;
[0011] Determining whether the target screen still has a fault based on the first screen data;
[0012] If the target screen still has a fault, the control performs hardware-level fault recovery;
[0013] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0014] In combination with the first aspect, in one implementation, the controlling performs hardware-level fault recovery, including:
[0015] Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data;
[0016] Determining whether the target screen still has a fault based on the second screen data;
[0017] If the target screen still has a fault, control the target screen to power on again;
[0018] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0019] In combination with the first aspect, in one implementation, the target screen data is transparently transmitted to the target microcontroller via a general purpose input and output port GPIO.
[0020] In a second aspect, an embodiment of the present application provides a device for monitoring a fault of an instrument screen, wherein the device comprises a target microcontroller, and the target microcontroller is used to:
[0021] Acquire target screen data, and detect whether the target screen has a fault based on the target screen data;
[0022] Based on the detection result and when the detection result is yes, the control performs fault recovery to achieve normal display of the target screen.
[0023] In conjunction with the second aspect, in one implementation, the target microcontroller is specifically used for:
[0024] When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data;
[0025] Determining whether the target screen still has a fault based on the first screen data;
[0026] If the target screen still has a fault, the control performs hardware-level fault recovery;
[0027] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0028] In conjunction with the second aspect, in one implementation, the target microcontroller is further used for:
[0029] Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data;
[0030] Determining whether the target screen still has a fault based on the second screen data;
[0031] If the target screen still has a fault, control the target screen to power on again;
[0032] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0033] In combination with the second aspect, in one implementation, the target screen data is transparently transmitted to the target microcontroller via a general purpose input and output port GPIO.
[0034] In the third aspect, an embodiment of the present application provides an instrument screen fault monitoring device, which includes a processor, a memory, and an instrument screen fault monitoring program stored in the memory and executable by the processor, wherein when the instrument screen fault monitoring program is executed by the processor, the steps of the aforementioned instrument screen fault monitoring method are implemented.
[0035] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, on which an instrument screen fault monitoring program is stored, wherein when the instrument screen fault monitoring program is executed by a processor, the steps of the aforementioned instrument screen fault monitoring method are implemented.
[0036] The beneficial effects brought by the technical solution provided in the embodiments of the present application include:
[0037] By directly transmitting the target screen data to the target microcontroller and using the lock-step core function of the target microcontroller to accurately detect whether the target screen has a fault, the target screen will be accurately detected to avoid misjudgment of instrument screen faults; for target screens with faults, fault recovery control will be performed to ensure the normal display of the target screen. It can be seen that this application can achieve accurate monitoring of smart cockpit instrument screen faults to avoid misjudgment of instrument screen faults, thereby effectively meeting the functional safety requirements of smart cockpits. BRIEF DESCRIPTION OF THE DRAWINGS
[0038] Figure 1 This is a flow chart of an embodiment of the instrument screen fault monitoring method of the present application;
[0039] Figure 2 It is a flow chart of realizing instrument screen fault monitoring based on QM SOC in the prior art;
[0040] Figure 3 This is a schematic diagram of static data transmission involved in the embodiment of the present application;
[0041] Figure 4 A schematic diagram of dynamic data transmission involved in the embodiment of the present application;
[0042] Figure 5 This is a schematic diagram of the hardware structure of the instrument screen fault monitoring device involved in the embodiment of the present application. DETAILED DESCRIPTION
[0043] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.
[0044] An embodiment of the present application provides an instrument screen fault monitoring method, which can realize accurate monitoring of instrument screen faults in a smart cockpit to avoid misjudgment of instrument screen faults, thereby effectively meeting the functional safety requirements of the smart cockpit.
[0045] To achieve the above objectives, the overall idea of this application is as follows:
[0046] Step S10: acquiring target screen data through a target microcontroller, and detecting whether the target screen has a fault based on the target screen data;
[0047] Step S20: Based on the detection result and when the detection result is yes, control to perform fault recovery to achieve normal display of the target screen.
[0048] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.
[0049] In a first aspect, an embodiment of the present application provides a method for monitoring instrument screen faults.
[0050] In one embodiment, referring to Figure 1 , Figure 1 This is a flow chart of an embodiment of the instrument screen fault monitoring method of the present application. Figure 1 As shown, the instrument screen fault monitoring method is applied to the target microcontroller, including the following steps:
[0051] Step S10: acquiring target screen data, and detecting whether the target screen has a fault based on the target screen data; wherein the target screen data is transparently transmitted to the target microcontroller through a general purpose input and output port GPIO.
[0052] Exemplarily, in this embodiment, the target screen data is the data corresponding to the instrument screen during operation, and the target screen data can be used to identify whether the instrument screen has a fault. Figure 2 As shown, when the abnormal fault monitoring of the screen is traditionally implemented through QM SOC, the target screen data corresponding to the instrument screen will be transmitted to the QM SOC through the encoding and decoding string, so that the QM SOC can determine whether there is an abnormal fault on the screen based on the target screen data; if there is a fault, the screen fault status is transmitted to the microcontroller, and then the microcontroller notifies the vehicle Vechile in an E2E (End-to-End) manner; although the above method can realize screen fault monitoring, because the core of QM SOC does not support the lock-step core during monitoring, it will mistakenly judge the screen fault status as wrong, that is, the screen has a display abnormal fault, but the QM SOC mistakenly determines that the screen has not a display abnormal fault, so that the screen fault status cannot be transmitted to the whole vehicle in time, thereby failing to meet the functional safety requirements of the smart cockpit.
[0053] In order to solve the above problems, this embodiment will directly obtain the target screen data through the target microcontroller MCU with a safety level of ASIL B and use the lock-step core function of the target microcontroller MCU to accurately detect screen failures. Figure 3As shown, at the instrument screen end, the target screen DIS Panel with a safety level of ASIL B will output data used to characterize whether it has a fault during the power-on process. The data can be preferably transmitted to the deserializer De-serializer with a safety level of ASIL B through GPIO (General-Purpose Input / Output) for deserialization, and the processing results are preferably transmitted to the serializer Serializer at the cockpit host end through high-speed digital interface technologies such as FPD-Link (Flat Panel Display Link, a high-speed digital video interface standard) and GMSL (Gigabit Multimedia Serial Link, which represents products used for serial and parallel conversion and buffering of data streams in short-range communications). It can be understood that ASIL B is a safety level defined in the ISO 26262 standard, which is used to assess the risk level of functional safety of electronic and electrical systems in road vehicles. It is mainly applicable to some systems that pose a moderate risk to personal safety. The failure of these systems may have a certain impact on the safety of the vehicle, but usually does not pose a direct threat to the life safety of the driver and passengers.
[0054] See also Figure 3 As shown, after the serializer serializes the received data, the target screen data can be formed. It should be understood that this embodiment directly connects the target microcontroller MCU in the control cabin host end with the serializer, so the serializer can directly transmit the target screen data to the target microcontroller MCU through GPIO.
[0055] It should be noted that the safety level of the target microcontroller MCU in this embodiment is ASIL B, which meets the functional safety requirements, and it has a lock-step core function; therefore, see Figure 4 As shown, after receiving the target screen data, the target microcontroller MCU can use its own lock-step core function to parse and process the target screen data, such as verifying, decoding, format conversion and other operations on the target screen data to extract useful information (such as fault codes, operating status, etc.), and then accurately determine whether the target screen has a fault based on the extracted information to avoid the problem of misjudgment of instrument screen faults.
[0056] Step S20: Based on the detection result and when the detection result is yes, control to perform fault recovery to achieve normal display of the target screen.
[0057] Exemplarily, in this embodiment, whether fault recovery is required is determined by the fault detection result. Specifically, if the detection result shows that the target screen has no fault, indicating that the target screen can be displayed normally, then no fault recovery is required; and if the detection result shows that the target screen has a fault, indicating that the target screen cannot be displayed normally, then it is determined that fault recovery is required, and at this time, fault recovery at the hardware level, software level or screen end may be preferably performed to ensure that the target screen can be displayed normally.
[0058] It can be seen that this embodiment transmits the target screen data directly to the target microcontroller and uses the lock-step core function of the target microcontroller to accurately detect whether the target screen has a fault, so as to avoid misjudging the instrument screen fault; for the target screen with a fault, fault recovery control will be performed to ensure the normal display of the target screen. Therefore, this embodiment can realize accurate monitoring of the instrument screen fault of the smart cockpit, so as to avoid the problem of misjudgment of the instrument screen fault, and effectively realize the functional safety requirements of the smart cockpit.
[0059] Further, in one embodiment, when the detection result is yes, controlling the fault recovery includes:
[0060] When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data;
[0061] Determining whether the target screen still has a fault based on the first screen data;
[0062] If the target screen still has a fault, the control performs hardware-level fault recovery;
[0063] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0064] For example, in this embodiment, when a fault is detected on the target screen, it is preferred to first perform fault recovery at the software level (ie, Level 1). Figure 4 As shown, in order to further improve the accuracy of fault judgment, multiple fault judgments can be performed on the target screen; if a fault is detected for multiple consecutive times (for example, 3 times) (i.e., the fault is established 3 times in a row), the SOC is controlled to reinitialize the Serilizer through IPCL (Internal Processor Communication Language, internal inter-chip communication protocol) (see Figure 3As shown, the SOC and the Serilizer can exchange data through DIS (DisplaySerial Interface, a video interface standard) to try to recover the communication failure between the SOC and the Serilizer (for example, the video belonging to the SOC is stuck, resulting in the screen always displaying the same frame of image without moving, or the register of the SOC configuration serializer is written with an incorrect configuration value). If the recovery is successful, it means that the detected fault is a software fault, and the target screen can continue to display normally after the software fault is recovered; if the recovery is not successful, that is, the target screen still has a fault, it means that the detected fault is not a software fault, and then hardware-level or screen-side fault recovery is required to ensure that the target screen can be displayed normally.
[0065] Furthermore, in one embodiment, the control performs hardware-level fault recovery, including:
[0066] Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data;
[0067] Determining whether the target screen still has a fault based on the second screen data;
[0068] If the target screen still has a fault, control the target screen to power on again;
[0069] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0070] For example, in this embodiment, when it is determined that the detected fault is not a software fault (ie, the fault still exists after restarting Level 1), it is preferred to perform hardware level (ie, Level 2) fault recovery on the target screen. Figure 4 As shown, in order to further improve the accuracy of fault judgment, multiple fault judgments can be performed on the target screen based on fault Level 1; if the fault occurs multiple times in a row (for example, 3 times), the power supply of the Serilizer can be restarted through GPIO to try to restore the fault of the register hardware of the Serilizer itself (for example, the screen display is abnormal due to hardware problems such as Serilizer register jamming). If the recovery is successful, it means that the detected fault belongs to the hardware fault of the Serilizer, and the target screen can continue to display normally after the hardware fault is restored; if the recovery is not successful, that is, the target screen still has a fault, it means that the detected fault is not a hardware fault, and then the screen-side fault recovery is required to ensure that the target screen can be displayed normally.
[0071] It should be understood that if the fault still exists after restarting Level 2, it is most likely not a fault on the cockpit host side, but a fault caused by an abnormality on the target screen itself, so the only way to try to recover from the fault is to restart the target screen. For details, see Figure 4 As shown, in order to further improve the accuracy of fault judgment, multiple fault judgments can be performed on the target screen based on fault Level 2; see Figure 3 and Figure 4 As shown, if the fault occurs again for multiple consecutive times (for example, 3 times), the target microcontroller MCU can notify the vehicle Vechile with a safety level of ASIL B of the screen-side fault through bus technologies such as CAN (Controller Area Network), LIN (Local Interconnect Network), and Flex Ray (a high-speed, reliable data transmission bus), that is, notify the vehicle Vechile to power on the target screen as a whole, so that the vehicle Vechile can power on the target screen as a whole through GPIO to try to restore it to a normal state, thereby achieving the purpose of screen-side fault recovery, thereby ensuring that the target screen can be displayed normally.
[0072] In summary, compared with QM's SOC, the MCU in this embodiment meets the functional safety requirements and can realize the lock-step core function, that is, the MCU can correctly judge whether the screen is actually faulty; therefore, in this embodiment, the screen fault data is directly transmitted to the MCU without passing through the SOC, and the fault transmission of the instrument screen is realized through GPIO, that is, the GPIO is transmitted to the cockpit host end after encoding and deserializing, and then connected to the MCU, so that the MCU judges whether there is a fault on the screen end through GPIO, and adds a fault recovery strategy (that is, Level 1 to Level 3) to send the fault status to the vehicle controller, thereby realizing accurate monitoring of the smart cockpit instrument screen fault, so as to avoid the problem of misjudgment of instrument screen fault, and effectively realize the functional safety requirements of the smart cockpit.
[0073] In a second aspect, an embodiment of the present application also provides an instrument screen fault monitoring device.
[0074] In one embodiment, the instrument screen fault monitoring device includes a target microcontroller, wherein the target microcontroller is used to:
[0075] Acquire target screen data, and detect whether the target screen has a fault based on the target screen data;
[0076] Based on the detection result and when the detection result is yes, the control performs fault recovery to achieve normal display of the target screen.
[0077] Furthermore, in one embodiment, the target microcontroller is specifically used for:
[0078] When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data;
[0079] Determining whether the target screen still has a fault based on the first screen data;
[0080] If the target screen still has a fault, the control performs hardware-level fault recovery;
[0081] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0082] Furthermore, in one embodiment, the target microcontroller is further used for:
[0083] Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data;
[0084] Determining whether the target screen still has a fault based on the second screen data;
[0085] If the target screen still has a fault, control the target screen to power on again;
[0086] If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
[0087] Furthermore, in one embodiment, the target screen data is transparently transmitted to the target microcontroller via a general purpose input and output port GPIO.
[0088] Among them, the functional implementation of each module in the above-mentioned instrument screen fault monitoring device corresponds to the various steps in the above-mentioned instrument screen fault monitoring method embodiment, and its functions and implementation processes will not be repeated here one by one.
[0089] In a third aspect, an embodiment of the present application provides an instrument screen fault monitoring device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.
[0090] Reference Figure 5 , Figure 5 Schematic diagram of the hardware structure of the instrument screen fault monitoring device involved in the embodiment of the present application. In the embodiment of the present application, the instrument screen fault monitoring device may include a processor, a memory, a communication interface and a communication bus.
[0091] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.
[0092] The communication interface includes input / output (I / O) interface, physical interface and logical interface, etc., which are used to realize the interconnection of devices inside the instrument screen fault monitoring device, and the interface used to realize the interconnection between the instrument screen fault monitoring device and other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device can be a display, a keyboard, etc.
[0093] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0094] The processor may be a general-purpose processor, and the general-purpose processor may call the instrument screen fault monitoring program stored in the memory and execute the instrument screen fault monitoring method provided in the embodiment of the present application. For example, the general-purpose processor may be a central processing unit (CPU). The method executed when the instrument screen fault monitoring program is called may refer to the various embodiments of the instrument screen fault monitoring method of the present application, and will not be repeated here.
[0095] Those skilled in the art will understand that Figure 5 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.
[0096] In a fourth aspect, an embodiment of the present application also provides a computer-readable storage medium.
[0097] The readable storage medium of the present application stores an instrument screen fault monitoring program, wherein when the instrument screen fault monitoring program is executed by a processor, the steps of the instrument screen fault monitoring method as described above are implemented.
[0098] Among them, the method implemented when the instrument screen fault monitoring program is executed can refer to the various embodiments of the instrument screen fault monitoring method of the present application, and will not be repeated here.
[0099] It should be noted that the serial numbers of the above-mentioned embodiments of the present application are only for description and do not represent the advantages or disadvantages of the embodiments.
[0100] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.
[0101] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.
[0102] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.
[0103] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.
[0104] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.
[0105] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.
Claims
1. A method for monitoring instrument screen failure, characterized in that: The instrument screen fault monitoring method is applied to a target microcontroller, comprising the following steps: Acquire target screen data, and detect whether the target screen has a fault based on the target screen data; Based on the detection result and when the detection result is yes, the control performs fault recovery to achieve normal display of the target screen.
2. The instrument screen fault monitoring method according to claim 1, characterized in that: The controlling of fault recovery based on the detection result and when the detection result is yes includes: When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data; Determining whether the target screen still has a fault based on the first screen data; If the target screen still has a fault, the control performs hardware-level fault recovery; If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
3. The instrument screen fault monitoring method according to claim 2, characterized in that: The control performs hardware-level fault recovery, including: Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data; Determining whether the target screen still has a fault based on the second screen data; If the target screen still has a fault, control the target screen to power on again; If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
4. The instrument screen fault monitoring method according to claim 1, characterized in that: The target screen data is transparently transmitted to the target microcontroller through a general purpose input and output port GPIO.
5. An instrument screen fault monitoring device, characterized in that: The instrument screen fault monitoring device includes a target microcontroller, and the target microcontroller is used to: Acquire target screen data, and detect whether the target screen has a fault based on the target screen data; Based on the detection result and when the detection result is yes, the control performs fault recovery to achieve normal display of the target screen.
6. The instrument screen fault monitoring device according to claim 5, characterized in that: The target microcontroller is specifically used for: When it is detected that the target screen has a fault, the control system on chip SOC re-initializes the serializer and re-acquires new screen data to obtain first screen data; Determining whether the target screen still has a fault based on the first screen data; If the target screen still has a fault, the control performs hardware-level fault recovery; If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
7. The instrument screen fault monitoring device according to claim 6, characterized in that: The target microcontroller is also specifically used for: Controlling the power supply of the serializer to restart and then reacquire new screen data to obtain second screen data; Determining whether the target screen still has a fault based on the second screen data; If the target screen still has a fault, control the target screen to power on again; If there is no fault on the target screen, it is determined that the target screen can be displayed normally.
8. The instrument screen fault monitoring device according to claim 5, characterized in that: The target screen data is transparently transmitted to the target microcontroller through a general purpose input and output port GPIO.
9. An instrument screen fault monitoring device, characterized in that: The instrument screen fault monitoring device includes a processor, a memory, and an instrument screen fault monitoring program stored in the memory and executable by the processor, wherein when the instrument screen fault monitoring program is executed by the processor, the steps of the instrument screen fault monitoring method as described in any one of claims 1 to 4 are implemented.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores an instrument screen fault monitoring program, wherein when the instrument screen fault monitoring program is executed by a processor, the steps of the instrument screen fault monitoring method according to any one of claims 1 to 4 are implemented.