A control system of a vehicle cabin domain and a vehicle cabin domain

Abstract

The application provides a control system of a vehicle cabin domain and the vehicle cabin domain. The control system comprises a micro control unit (MCU) module and a micro processing unit (MPU) module. The MCU module switches a channel for transmitting a key signal generated by a physical operation component between the MCU module and the MPU module from a normal interaction path to an emergency interaction path in response to a trigger instruction generated by the physical operation component in the vehicle cabin domain. The MPU module is configured to capture interface display data for driving a vehicle display screen to display in a corresponding frame buffer of the MPU module after the emergency interaction path is established, and transmit the interface display data back to a mobile terminal bound with the vehicle cabin domain through a cloud server via a vehicle network. Through the application, the vehicle-machine system after screen display failure can restore complete visual control capability through dynamic reconstruction of an existing signal link in the cabin domain control part and standardized mapping of the key signal without adding hardware.

Description

Technical Field

[0001] This application relates to the field of vehicle cockpit technology, and more specifically, to a control system for a vehicle cockpit and a vehicle cockpit domain. Background Technology

[0002] The in-vehicle display screen is the core window for human-machine interaction in a smart cockpit, undertaking key tasks such as vehicle status display, function operation, and fault prompts. Existing cockpit systems generally adopt an architecture of a domain controller plus an in-vehicle display screen. The domain controller typically integrates a microcontroller unit and a microprocessor unit, while the in-vehicle display screen is connected to the domain controller via a low-voltage differential signal link to receive video signals and display images. At the same time, it senses user touch operations through an integrated touch panel.

[0003] During normal interaction, both the display channel and the touch input channel are highly dependent on the in-vehicle display screen. When the in-vehicle display screen experiences abnormal states such as a black screen, distorted screen, or white screen, its physical display function and touch sensing function will be lost simultaneously, and both interaction channels will be cut off. At this time, even if the operating system and vehicle applications running on the microprocessor unit in the domain controller are still running normally in the background, and the system interface is continuously refreshing in the frame buffer, the driver and passengers will not be able to see any interface content on the screen, nor will they be able to perform any operations by touch. Human-machine interaction is completely interrupted, and operations such as fault code reading, exporting important files, and adjusting system settings cannot be performed. They can only passively wait for the vehicle to be returned to the factory for repair. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a control system for a vehicle cockpit and a vehicle cockpit, which aims to overcome at least one of the above-mentioned defects.

[0005] In a first aspect, this application provides a control system for a vehicle cockpit domain, the control system including a microcontroller unit (MCU) module and a microprocessor unit (MPU) module, the MCU module being connected to the MPU module; The MCU module is used to switch the transmission path of the button signal from the normal interaction path to the emergency interaction path in response to the trigger command generated by the physical control component in the vehicle cockpit when the vehicle display screen in the vehicle cockpit is in an abnormal state, so as to transmit the button signal to the MPU module through the emergency interaction path. The MPU module is configured to, after the emergency interaction channel is established, capture the interface display data that drives the vehicle display screen to display in the frame buffer corresponding to the MPU module, transmit the interface display data back to the mobile terminal bound to the vehicle cockpit domain via the cloud server through the vehicle network, and convert the button signals received through the emergency interaction channel into input layer standard event identifiers of the operating system running the MPU module, so as to drive the interface displayed by the operating system to perform corresponding actions based on the interface display data presented by the mobile terminal through the standard event identifiers.

[0006] In one possible implementation, the control system further includes a network communication module, which is connected to the MPU module via a data bus; The network communication module is used to perform the following processes: After the emergency interaction channel is established, the connection status between the vehicle network and the cloud server is detected, and the connection status is sent to the MPU module; The MPU module is also used to perform the following processes: When the connection status indicates an interruption, the interface display data is cached in the storage area corresponding to the MPU module; After the connection is restored, the cached interface display data is retrieved from the storage area and sent back to the mobile terminal.

[0007] In one possible implementation, the MPU module is also used to perform the following processes: When the connection status indicates an interruption, a network interruption notification command is generated; The network interruption notification command is sent to the MCU module through the emergency interaction channel; The MCU module is also used to respond to the network interruption prompt command and control the audio output component in the vehicle cockpit domain to emit a first prompt tone.

[0008] In one possible implementation, the MCU module is also used to perform the following processes: After the emergency interaction channel is established, the heartbeat signal of the MPU module is detected; If the heartbeat signal does not arrive within a preset time, the MPU module is determined to be in a fault state, and the fault reporting information is pushed to the mobile terminal via the cloud server through the vehicle network.

[0009] In one possible implementation, the MCU module is also used to perform the following processes: After determining that the MPU module is in a faulty state, the audio output component in the vehicle cabin domain is controlled to emit a second prompt tone, which is different from the first prompt tone.

[0010] In one possible implementation, the vehicle display screen is connected to the MPU module via a low-voltage differential signal LVDS link, and the abnormal state of the vehicle display screen includes any one of black screen, distorted screen, or white screen. The MPU module is also used to determine whether the vehicle display screen is in an abnormal state by means of the following methods: The determination is made based on the display driver status of the LVDS link. When the serial deserialization chip of the LVDS link is found to be unlocked, the display driver circuit is interrupted, or a verification error is detected, the vehicle display screen is determined to be in an abnormal state. Alternatively, the determination can be made based on the lock status signal or heartbeat signal of the serial deserialization chip in the LVDS link. When the lock status signal of the serial deserialization chip is lost or the heartbeat signal is interrupted, the vehicle display screen is determined to be in an abnormal state. Alternatively, the self-test information reported by the microcontroller unit of the vehicle display screen can be received via the I2C bus, and the vehicle display screen can be determined to be in an abnormal state based on the self-test information. The MPU module is also used to send the determination result to the MCU module.

[0011] In one possible implementation, the MPU module is also used to perform the following processes: After capturing the interface display data in the frame buffer corresponding to the MPU module, the interface display data is video encoded and compressed to generate a video stream; The video stream is used as the interface display data and transmitted back to the mobile terminal via the vehicle network and the cloud server.

[0012] In one possible implementation, the MPU module is also used to perform the following processes: The interface display data is cached for a preset duration during scrolling. When the screen recording start command is received from the mobile terminal via the cloud server, the interface display data captured after the screen recording start command arrives is merged with the interface display data cached in the scrolling cache within the preset time period before the screen recording start command arrives, and then sent back to the mobile terminal.

[0013] In one possible implementation, the MCU module is also used to perform the following processes: After the emergency interaction channel is established, the button signals generated by the physical control component are continuously monitored; If the button signal is not received within a preset time period, an emergency mode exit command is sent to the MPU module; The MPU module is also used to perform the following processes: In response to the emergency mode exit command, the emergency interaction path is switched back to the normal interaction path to stop capturing the interface display data and stop the conversion of the button signals to the standard event identifier.

[0014] Secondly, this application provides a vehicle cockpit domain, including an in-vehicle display screen and a control system for the aforementioned vehicle cockpit domain.

[0015] This application provides a control system for a vehicle cockpit domain and a vehicle cockpit domain itself. The control system includes a microcontroller unit (MCU) module and a microprocessor unit (MPU) module. The MCU module, responding to trigger commands generated by physical control components in the vehicle cockpit domain, switches the channel for transmitting button signals generated by the physical control components between the MCU module and the MPU module from a normal interaction path to an emergency interaction path. After the emergency interaction path is established, the MPU module captures the interface display data that drives the in-vehicle display screen in its corresponding frame buffer and transmits the interface display data back to the mobile terminal bound to the vehicle cockpit domain via the in-vehicle network and a cloud server. This application achieves the restoration of complete visual control capabilities of the vehicle's infotainment system after a display failure by dynamically reconstructing existing signal links within the cockpit domain control and standardizing the mapping of button signals, without adding new hardware.

[0016] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is one of the structural schematic diagrams of a vehicle cockpit domain control system provided in an embodiment of this application; Figure 2 This is a second schematic diagram of the structure of a vehicle cockpit domain control system provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0020] First, the applicable application scenarios of this application will be introduced. This application can be applied to the technical field of vehicle cockpits.

[0021] Research has revealed that with the development of smart cockpit technology, in-vehicle displays have become the core window for interaction between drivers and passengers and the cockpit domain control system, undertaking core functions such as vehicle status display, function operation, fault indication, and multimedia entertainment. Existing in-vehicle cockpit domain control systems generally adopt an architecture of a domain controller host plus an in-vehicle display screen. The cockpit domain controller host features a dual-core architecture of MCU and MPU. At the hardware driver and communication levels, most hardware modules within the system, such as radio, Bluetooth and wireless network, and cameras, are mounted on the Android system running on the MPU and driven by the MPU. The MCU communicates and interacts with specific hardware modules such as audio digital signal processors and mobile network modules through interfaces such as SPI, UART, and GPIO to control and acquire the status of these specific hardware components. The MCU and MPU work together to complete functions such as overall vehicle hardware control, signal acquisition and forwarding, Android system operation, application management, and video processing.

[0022] The vehicle-mounted display screen is connected to the domain controller via an LVDS link, receives video signals output by the domain controller to display images, and integrates a TP module to sense user touch operations and feed them back to the domain controller.

[0023] Currently, there are two main solutions for handling in-vehicle screen display malfunctions. Solution one is direct repair and replacement. When a screen display malfunction occurs, the user cannot view or operate any interface and must return the vehicle to the factory for repair personnel to diagnose the fault and replace the faulty component. This solution lacks any emergency compensation mechanism. Solution two is remote command control. Some high-end models support remote issuance of simple commands via a mobile client. However, this solution can only execute preset commands and cannot provide real-time viewing of the vehicle's interface, perform complex operations such as fault code reading, exporting important files, or adjusting system settings. Furthermore, it lacks local button emergency control capabilities.

[0024] The existing technical solutions have the following drawbacks: In the existing cockpit domain control system, the MPU is only responsible for the operation of the Android system and video output under normal scenarios. It does not design emergency interaction logic after the screen display is abnormal. Users cannot control the vehicle system in any way, and cannot view fault information or export important data. In the existing remote control solutions, the communication between the mobile client and the domain control host is limited to command issuance and execution feedback. It does not establish a collaborative link for real-time screen transmission and precise operation. The mobile client cannot obtain the vehicle system interface in real time, resulting in blind remote operation and failing to meet the needs of emergency scenarios. Some emergency solutions attempt to achieve control after the screen display is abnormal by adding hardware modules such as emergency displays and dedicated remote controls. However, they do not reuse the existing steering wheel control, MCU-MPU link and Android screen recording function, which increases hardware costs, complicates deployment, and cannot be adapted to the existing vehicle architecture, making it difficult to promote on a large scale.

[0025] Based on this, this application provides a vehicle cockpit domain control system and a vehicle cockpit domain, aiming to solve the problem of complete interruption of human-machine interaction when the vehicle display screen is abnormal. Without adding any hardware, it uses the vehicle's existing physical control components and mobile terminals to rebuild the human-machine interaction channel, with the mobile terminal responsible for display and the physical control components responsible for input. This allows drivers and passengers to view the vehicle interface in real time and complete complex emergency operations such as fault code reading and file export. At the same time, strict isolation between emergency mode and normal mode ensures driving safety.

[0026] Please see Figure 1 , Figure 1 This is one of the structural schematic diagrams of a vehicle cockpit domain control system provided in an embodiment of this application. The vehicle cockpit domain control system 100 provided in this embodiment includes a microcontroller unit (MCU) module 101 and a microprocessor unit (MPU) module 102. The MCU module 101 and the MPU module 102 are coupled through a serial communication interface, which is a UART interface or an SPI interface, used to carry bidirectional data transmission between the MCU module 101 and the MPU module 102.

[0027] When the vehicle display screen in the vehicle cockpit is in an abnormal state, the MCU module 101 is used to switch the channel for transmitting button signals generated by the physical control components in the vehicle cockpit from the normal interaction path to the emergency interaction path in response to the trigger command generated by the physical control components in the vehicle cockpit. The button signals are then transmitted to the MPU module 102 through the emergency interaction path, while shielding signals that do not originate from the physical control components carried on the normal interaction path. After the emergency interaction channel is established, the MPU module 102 is used to capture the interface display data that drives the vehicle display screen to be displayed in the corresponding frame buffer of the MPU module 102, and transmit the interface display data back to the mobile terminal 200 bound to the vehicle cockpit domain via the cloud server through the vehicle network. It also converts the key signals received through the emergency interaction channel into input layer standard event identifiers of the operating system running on the MPU module 102, so as to drive the interface displayed by the operating system to perform corresponding actions based on the interface display data presented by the mobile terminal 200 through the standard event identifiers.

[0028] Specifically, the MCU module 101 is the processing unit within the cockpit domain responsible for signal scheduling and communication with specific hardware, undertaking basic vehicle-level functions such as wake-up management, power mode control, and CAN / LIN bus communication. At the hardware control level, most hardware modules within the system, such as radio, Bluetooth and wireless network, and cameras, are mounted on the Android system running on the MPU module 102 and driven by the MPU module 102. The MCU module 101 communicates with specific hardware modules such as the audio digital signal processor and mobile network module through interfaces such as SPI, UART, and GPIO to control and acquire the status of these specific hardware components.

[0029] The MPU module 102 is the processing unit within the cockpit domain responsible for upper-level application logic and video processing. It runs an operating system, specifically Android, and is responsible for application management, video processing, and rendering of the human-machine interface. The in-vehicle display screen is connected to the MPU module 102 via a low-voltage differential signal (LVDS) link, receiving video signals output from the MPU module 102 to display images. It also integrates a touch panel (TP) module, which senses user touch operations and feeds back touch coordinates to the MPU module 102.

[0030] Specifically, during normal interaction within the vehicle cockpit, the human-machine interaction between the driver / passengers and the vehicle's infotainment system relies on two parallel channels. The first is the display channel, where the operating system running on the MPU module 102 generates the interface image, which is then transmitted unidirectionally to the in-vehicle display screen via the LVDS link for presentation. The driver / passengers obtain visual information by viewing the in-vehicle display screen. It should be noted that LVDS is a unidirectional video differential transmission interface; both the protocol and physical layers only support sending image pixel data and timing control signals from the MPU module 102 to the in-vehicle display screen, and it does not have the ability to send data back in reverse.

[0031] The second channel is the touch input channel. When a driver or passenger touches the TP module on the in-vehicle display screen, the touch coordinates are transmitted back to the MPU module 102 via the I2C serial communication link in the wiring harness connecting the display screen and the MPU module 102. The MPU module 102 then drives the interface displayed by the operating system to perform corresponding operations. The wiring harness between the in-vehicle display screen and the MPU module 102 includes both LVDS differential signal lines and I2C serial communication lines. LVDS carries video data transmitted unidirectionally from the MPU module 102 to the in-vehicle display screen, while I2C carries reverse communication data such as touch coordinates.

[0032] Both of these channels are physically highly dependent on the same hardware: the in-vehicle display screen. When the in-vehicle display screen experiences abnormal states such as a black screen, a distorted screen, or a white screen, its physical display function and touch sensing function will be lost simultaneously, and both the display channel and the touch input channel will be cut off. At this time, although the operating system running on the MPU module 102 and its upper-level vehicle applications are still running normally in the background, and the system interface is continuously refreshing in the frame buffer, the driver and passengers cannot see any interface content on the in-vehicle display screen, nor can they perform any operations through the touch screen; human-machine interaction is completely interrupted.

[0033] In this embodiment, a set of physical control components, independent of the aforementioned display channel and touch input channel, also exists within the vehicle cabin area. Specifically, the physical control components are steering wheel control buttons, which include up, down, left, right, and an OK confirmation button for physical pressing by the driver and passengers. These steering wheel control buttons are connected to the MCU module 101 via a CAN bus, LIN bus, or AD sampling link. This signal transmission link is completely independent of the vehicle display screen and LVDS link. When the user presses these buttons, a button signal is generated and transmitted to the MCU module 101 along the CAN / LIN / AD link. Under normal operating conditions, this signal is used for multimedia control, telephone answering, and other routine operations. Because the signal link of the steering wheel control buttons is physically independent of the vehicle display screen, even if the vehicle display screen malfunctions, the button signals generated by the physical control components can still reach the MCU module 101 normally and will not be interrupted due to screen failure.

[0034] Based on the aforementioned hardware architecture characteristics, this application can, when the in-vehicle display screen malfunctions and both the display channel and touch input channel fail simultaneously, utilize the still-functioning independent input channel of the physical control components to replace the touch input channel. Simultaneously, leveraging the MPU module 102's ability to acquire the interface image from the frame buffer and the in-vehicle network transmission capability, the interface image originally displayed on the in-vehicle display screen is routed to the mobile terminal 200 for display, using the mobile terminal 200 as the alternative display channel. In this way, during a physical failure of the in-vehicle display screen, a human-machine interaction system is rebuilt for the driver and passengers, with the mobile terminal 200 handling the display and the physical control components handling the input.

[0035] Specifically, under normal operating conditions, the control system 100 operates in the normal interaction path. The normal interaction path is the regular channel used by the MCU module 101 and MPU module 102 to transmit button signals generated by the physical control components under normal operating conditions. In addition to button signals from the physical control components, this channel may also carry other regular input signals such as volume adjustment, track switching, and telephone answering / hanging up. When a user presses a physical control component to generate a button signal, the MCU module 101 parses the button signal and forwards it to the MPU module 102 through the normal interaction path. The MPU module 102 then drives the system interface on the vehicle display screen to perform the corresponding operation.

[0036] An abnormal state of the vehicle display screen is a core scenario that this control system 100 needs to handle. The abnormal state of the vehicle display screen includes any one of the following: a black screen, a distorted screen, or a white screen. The determination of the abnormal state can be achieved through the following three methods: The first method is that the MPU module 102 determines the abnormal state based on the display driver status of the LVDS link. When it detects that the serial deserialization chip in the LVDS link is unlocked, the display driver circuit is interrupted, or a verification error occurs, it determines that the vehicle display screen is in an abnormal state. The second method is that the MPU module 102 determines the abnormal state based on the lock status signal or heartbeat signal of the serial deserialization chip in the LVDS link. When it detects that the lock status signal of the serial deserialization chip is lost or the heartbeat signal is interrupted, it determines that the vehicle display screen is in an abnormal state. The third method is that the MPU module 102 receives self-test information reported by the microcontroller unit built into the vehicle display screen via the I2C bus and determines whether the vehicle display screen is in an abnormal state based on this self-test information. After determining the abnormal state through any of the above methods, the MPU module 102 sends the determination result to the MCU module 101.

[0037] When the vehicle display screen exhibits the aforementioned abnormal state, the user generates a trigger command by pressing a preset button in the physical control unit. The trigger command can be a long-press signal generated by continuously pressing a preset button in the physical control unit for a preset duration, such as pressing a single button for at least 5 seconds; or it can be a combination button signal generated by simultaneously pressing at least two preset buttons in the physical control unit, such as simultaneously pressing the up arrow key and the OK key for at least 3 seconds. Trigger parameters can be flexibly configured according to the actual vehicle model and project requirements. The trigger command is transmitted to the MCU module 101 via the CAN / LIN / AD link between the physical control unit and the MCU module 101. If the trigger command recognition fails due to insufficient pressing time or a malfunction of the button itself, the MCU module 101 sends a trigger failure signal to the MPU module 102. The MPU module 102 then emits a prompt tone through the audio output component in the vehicle cabin domain to remind the user to re-operate. The audio output component refers to a speaker or buzzer in the vehicle cabin domain, which provides the prompt through PCM audio playback, without relying on the display function of the vehicle display screen.

[0038] After receiving a valid trigger command, the MCU module 101 switches the channel for transmitting button signals generated by the physical control components between the MCU module 101 and the MPU module 102 from the normal interaction path to the emergency interaction path. The emergency interaction path is a dedicated signal transmission channel established between the MCU module 101 and the MPU module 102 in the event of a display malfunction. It is used only to transmit button signals originating from the physical control components and is isolated from the normal interaction path.

[0039] Simultaneously with the establishment of the emergency interaction path, MCU module 101 sends an emergency mode activation signal to MPU module 102, and MPU module 102 sends an emergency mode activation confirmation signal back to MCU module 101. Both parties complete the synchronous confirmation of the mode status through a two-way handshake. Afterwards, MCU module 101 stops forwarding normal button signals, retaining only the pass-through link for emergency button signals. During the activation of the emergency interaction path, MCU module 101 also determines the source identifier of signals carried on the normal interaction path. Signals whose source identifier matches that of a physical control component are allowed to pass through, while signals whose source identifier does not match that of a physical control component are discarded. This ensures the purity of button signal transmission during emergency operation and prevents other regular operation signals from interfering with the emergency operation process.

[0040] After the emergency interaction channel is established, the MPU module 102 initiates a collaborative processing flow for image capture and remote control. After the emergency mode is enabled, the MPU module 102 automatically detects and turns on the available vehicle network switch, which can be any of 4G, 5G, or WiFi networks.

[0041] In terms of image capture and transmission, the MPU module 102 calls the screen capture interface of its running operating system, specifically the native MediaProjection service of the Android system, to obtain the interface display data generated by the operating system and originally used to drive the vehicle display screen from the corresponding frame buffer of the MPU module 102. The frame buffer is a memory area in the MPU module 102 used to temporarily store a frame of the image to be displayed. Even if the vehicle display screen is in an abnormal state and cannot display normally, the interface display data in the frame buffer is continuously refreshed as the operating system runs normally, so it can be completely captured.

[0042] The MPU module 102 performs video encoding and compression on the acquired interface display data, generates a video stream using H.264 or H.265 encoding algorithms, and transmits the compressed image data back to the mobile terminal 200 bound to the vehicle cockpit domain via the vehicle network and cloud server.

[0043] Mobile terminal 200 refers to a smart terminal device carried by the user, equipped with a vehicle-specific application that supports iOS or Android operating systems. The binding relationship between mobile terminal 200 and the vehicle cockpit domain is established based on the vehicle identification number (VIN) of the vehicle to which the vehicle cockpit domain belongs. The user needs to log in to the same user account in the vehicle-specific application on both the in-vehicle infotainment system and mobile terminal 200, and complete the binding verification between the account and the vehicle using the vehicle VIN. The cloud server matches and verifies the account and VIN, and after successful verification, a two-way network communication link is established between the in-vehicle infotainment system and mobile terminal 200.

[0044] After receiving the image data, the cloud server verifies the identity of the mobile terminal 200 based on the vehicle identification code. Upon successful verification, the image data is encrypted using the AES encryption algorithm before being forwarded to the mobile terminal 200. The mobile terminal 200 receives the encrypted image data, decrypts it, and decodes the video, displaying the complete screen of the operating system interface in real-time on the in-vehicle dedicated application interface. It also displays the emergency mode status and button operation feedback information. Thus, although the user cannot view the screen through the in-vehicle display, they can obtain complete visual information of the operating system interface from the mobile terminal 200, successfully establishing an alternative display channel.

[0045] Regarding the mapping and execution of button signals, the MPU module 102 converts the button signals received through the emergency interaction channel into standard event identifiers for the input layer of its running operating system. These standard event identifiers refer to the standard button event codes defined in the Android system's input subsystem. Specifically, the mapping is as follows: the up arrow key is mapped to KEYCODE_DPAD_UP, corresponding to moving the cursor up or switching to the previous screen; the down arrow key is mapped to KEYCODE_DPAD_DOWN, corresponding to moving the cursor down or switching to the next screen; the left arrow key is mapped to KEYCODE_DPAD_LEFT, corresponding to moving the cursor left; the right arrow key is mapped to KEYCODE_DPAD_RIGHT, corresponding to moving the cursor right; and the OK confirmation key is mapped to KEYCODE_ENTER, corresponding to function confirmation, opening a file, or reading a fault code. This conversion achieves precise mapping between the button signals of the physical control components and the standard button events of the operating system, enabling all upper-level vehicle applications to directly respond to emergency button operations without requiring any adaptation or modification for emergency scenarios.

[0046] The aforementioned image feedback and button operation do not operate independently, but are integrated into a complete collaborative loop through user actions. The user first observes the real-time image data displayed on the mobile terminal 200 to understand the current state of the operating system's interface, and then determines the next step by pressing the up, down, left, and right directional keys and the OK confirmation key on the physical control unit. The button signals are transmitted to the MCU module 101 via the CAN / LIN / AD link. The MCU module 101 transmits the button signals to the MPU module 102 through an emergency interaction path. The MPU module 102 converts the button signals into standard event identifiers, driving the operating system's displayed interface to perform actions corresponding to the currently displayed image data, such as cursor movement, menu switching, function confirmation, fault code reading, important file export, system setting adjustment, and emergency light activation.

[0047] The interface changes following a control action are captured in real time by the MediaProjection service. After video encoding, compression, and cloud forwarding, the changes are transmitted back to the mobile terminal 200 as image data. The user then observes the results and decides whether to proceed. This forms a complete closed loop of screen monitoring, button control, and screen feedback, restoring the ability to visually control the operating system's interface even when the in-vehicle display is malfunctioning. This closed loop solves the core problems of disconnect between the screen and operation, and blind operation, in existing remote control solutions.

[0048] During emergency control operations, the control system 100 also has the capability to handle various abnormal scenarios.

[0049] Please see Figure 2 , Figure 2 This is a second schematic diagram of a vehicle cockpit domain control system provided in this application embodiment. In case of vehicle network interruption, the control system 100 further includes a network communication module 103, which is connected to the MPU module 102 via a data bus. After the emergency interaction path is established, the network communication module 103 continuously monitors the connection status between the vehicle network and the cloud server and sends the connection status to the MPU module 102. When the connection status indicates interruption, the MPU module 102 caches image data in a storage area independent of the frame buffer. After the connection status is restored, the cached image data is retrieved from this storage area and transmitted back to the mobile terminal 200 to avoid loss of image data. Simultaneously, the MPU module 102 generates a network interruption prompt command and sends it to the MCU module 101 via the emergency interaction path. The MCU module 101 responds to the network interruption prompt command by controlling the audio output component in the vehicle cockpit domain to emit a first prompt tone, reminding the user that the current image transmission link is unavailable. The mobile terminal 200 also simultaneously displays a network connection interruption prompt.

[0050] In the event of a fault in the MPU module 102, the MCU module 101 continuously monitors the MPU module 102's heartbeat signal after the emergency interaction path is established. The heartbeat signal is a periodic survival confirmation signal sent by the MPU module 102 to the MCU module 101, indicating that it is in normal operating condition. If the heartbeat signal does not reach the MCU module 101 within a preset time, the MCU module 101 determines that the MPU module 102 is in a faulty state and immediately pushes the fault reporting information to the mobile terminal 200 via the vehicle network and cloud server, notifying the user that the current emergency control function is unusable due to the MPU module 102 fault. After determining that the MPU module 102 is in a faulty state, the MCU module 101 also controls the audio output component in the vehicle cabin to emit a second prompt tone. The second prompt tone differs from the first prompt tone in pitch, rhythm, or duration to help the user distinguish the fault type without checking the mobile terminal 200. If the MPU module 102 malfunctions and the emergency mode cannot be activated, the MCU module 101 will automatically trigger the backup emergency logic, control the audio output component to emit a prompt tone to inform the user that the emergency mode cannot be entered, and at the same time report the fault information to the cloud server and push it to the mobile terminal 200 to remind the user to arrange for repair in time.

[0051] To address the issue of asynchronous screen recording commands, the MPU module 102 implements a preset-duration rolling cache for image data. The rolling cache refers to the MPU module 102 maintaining a fixed-time-window buffer of image data in memory. Newly generated image data continuously overwrites older data, ensuring that image data within the most recent preset duration remains readily available. When a user opens the vehicle-specific application on the mobile terminal 200 and confirms normal communication with the vehicle's infotainment system, they click the screen recording view button to initiate a screen recording command. This command is encrypted and forwarded by the cloud server and transmitted to the MPU module 102 via the vehicle network. Upon receiving the screen recording start command, the MPU module 102 merges the image data generated after the command's arrival with the image data cached in the rolling cache within the preset duration before the command's arrival, and then sends this merged back to the mobile terminal 200. This mechanism allows users to not only see the real-time screen after the command arrives but also review the interface state for a short period before the command's arrival, providing a more complete understanding of the changes to the vehicle's infotainment interface before and after the screen display anomaly.

[0052] It should be noted that the MCU module 101 maintains independent communication connections with the audio digital signal processor and the mobile network module through channels such as SPI, UART, and GPIO. In the extreme case where the serial communication interface between the MCU module 101 and the MPU module 102 is disconnected, the status information of the MCU module 101 cannot be transmitted to the MPU module 102. However, the MCU module 101 can still directly control the audio digital signal processor to issue a preset first or second prompt tone through the aforementioned independent channels, and control the mobile network module to send fault reporting information to the cloud server via the vehicle network. This hardware architecture design ensures that even when the communication between the MCU module 101 and the MPU module 102 is interrupted, the two key emergency functions of audio prompts and fault reporting can still operate independently, and will not be completely paralyzed due to the failure of a single link.

[0053] After the emergency control task is completed, the user generates an exit command by pressing the preset trigger button in the physical control component again. The triggering method of the exit command is consistent with that when entering emergency mode. After the emergency interaction path is established, the MCU module 101 continuously monitors the button signals generated by the physical control component. When it receives the exit trigger command or does not receive any button signals within a preset time, it sends an emergency mode exit command to the MPU module 102. The MPU module 102 responds to the emergency mode exit command by switching the emergency interaction path back to the normal interaction path, stopping the acquisition of interface display data in the frame buffer, and stopping the operation of converting button signals into standard event identifiers. After receiving the feedback signal of emergency mode exit, the MCU module 101 restores the normal button signal forwarding link, and the button signals generated by the physical control component are restored to the transmission mode of normal mode. At the same time, the user stops screen recording on the mobile terminal 200. The mobile terminal 200 sends a screen recording stop command to the MPU module 102, the MediaProjection service of the MPU module 102 stops working, video transmission stops, and the mobile terminal 200 stops displaying the vehicle interface. Once the vehicle's infotainment system has fully returned to normal interactive mode, and the user can resume touch operation via the touchscreen after the physical fault of the in-vehicle display screen has been repaired.

[0054] This application also provides a vehicle cockpit domain, which includes an in-vehicle display screen and a control system 100 for the vehicle cockpit domain described in any of the above embodiments. This vehicle cockpit domain has the complete capability to reconstruct human-machine interaction through physical control components in conjunction with a mobile terminal 200 in the event of a display malfunction. It is compatible with all vehicles equipped with a dual-core cockpit domain control architecture of MCU plus MPU and an Android vehicle system, and can handle various display malfunction scenarios such as display screen damage, LVDS link failure, and display driver malfunction.

[0055] Compared with existing technologies, this application constructs a dedicated emergency interaction architecture and processing flow for the specific scenario of abnormal display in the vehicle cockpit domain. By establishing an emergency interaction path that is strictly isolated from the normal interaction path between the MCU module 101 and the MPU module 102, and with a mode switching mechanism of long-press triggering and bidirectional feedback, a clear separation between emergency mode and normal mode is achieved. The trigger parameters can be flexibly configured, effectively avoiding the risk of accidental touches in normal driving scenarios. By constructing an emergency button transparent transmission link from the physical control component to the MCU module 101 via CAN / LIN / AD bus, and then to the MPU module 102 via UART / SPI serial port, which is different from the general link of conventional buttons in existing technologies, low-latency and interference-free transmission of emergency button signals is achieved. At the same time, it fully reuses the vehicle's existing hardware resources such as steering wheel control, MCU, MPU, vehicle network and mobile terminal 200, without the need for any additional emergency display screen or dedicated remote control or other hardware components, resulting in zero hardware cost. By uniformly mapping the button signals of physical control components to native standard button events of the Android system, seamless adaptation with all in-vehicle applications is achieved. Simultaneously, the MediaProjection service is used to capture interface data in the frame buffer when the in-vehicle display malfunctions, overcoming the limitation of existing technologies that cannot obtain the interface without a display screen. By constructing a collaborative closed loop between real-time video transmission from the mobile terminal and local physical control component operations, the problem of screen and operation disconnect in existing remote control solutions is solved, enabling precise execution of complex emergency operations such as fault code reading and important file export. Through account binding of the vehicle's VIN code, identity verification on the cloud server, and AES data encryption, combined with multi-layered anomaly mitigation measures such as network interruption buffering and resuming transmission, heartbeat fault detection, and audio-level tiered prompts, the safety and reliability of the emergency control process are comprehensively improved, meeting the requirements of the ISO 21434 in-vehicle information security standard.

[0056] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0057] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0059] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0060] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A control system for a vehicle cockpit area, characterized in that, The control system includes a microcontroller unit (MCU) module and a microprocessor unit (MPU) module, wherein the MCU module is connected to the MPU module. The MCU module is used to switch the transmission path of the button signal from the normal interaction path to the emergency interaction path in response to the trigger command generated by the physical control component in the vehicle cockpit when the vehicle display screen in the vehicle cockpit is in an abnormal state, so as to transmit the button signal to the MPU module through the emergency interaction path. The MPU module is configured to, after the emergency interaction channel is established, capture the interface display data that drives the vehicle display screen to display in the frame buffer corresponding to the MPU module and send it back to the mobile terminal bound to the vehicle cockpit domain, and convert the key signals received through the emergency interaction channel into input layer standard event identifiers of the operating system running the MPU module, so as to drive the interface displayed by the operating system to perform corresponding actions based on the interface display data presented by the mobile terminal through the standard event identifiers.

2. The control system according to claim 1, characterized in that, The control system also includes a network communication module, which is connected to the MPU module via a data bus. The network communication module is used to perform the following processes: After the emergency interaction path is established, the connection status between the vehicle network and the cloud server is detected, and the connection status is sent to the MPU module. The MPU module is also used to perform the following processes: When the connection status indicates an interruption, the interface display data is cached in the storage area corresponding to the MPU module; After the connection is restored, the cached interface display data is retrieved from the storage area and sent back to the mobile terminal.

3. The control system according to claim 2, characterized in that, The MPU module is also used to perform the following processes: When the connection status indicates an interruption, a network interruption notification command is generated; The network interruption notification command is sent to the MCU module through the emergency interaction channel. The MCU module is also used to respond to the network interruption prompt command and control the audio output component in the vehicle cockpit domain to emit a first prompt tone.

4. The control system according to claim 2, characterized in that, The MCU module is also used to perform the following processes: After the emergency interaction channel is established, the heartbeat signal of the MPU module is detected; If the heartbeat signal does not arrive within a preset time, the MPU module is determined to be in a fault state, and the fault reporting information is pushed to the mobile terminal via the cloud server through the vehicle network.

5. The control system according to claim 4, characterized in that, The MCU module is also used to perform the following processes: After determining that the MPU module is in a faulty state, the audio output component in the vehicle cabin domain is controlled to emit a second prompt tone, which is different from the first prompt tone.

6. The control system according to claim 1, characterized in that, The vehicle display screen is connected to the MPU module via a low-voltage differential signal LVDS link. An abnormal state of the vehicle display screen includes any one of the following: a black screen, a distorted screen, or a white screen. The MPU module is also used to determine whether the vehicle display screen is in an abnormal state by means of the following methods: The determination is made based on the display driver status of the LVDS link. When the serial deserialization chip of the LVDS link is found to be unlocked, the display driver circuit is interrupted, or a verification error is detected, the vehicle display screen is determined to be in an abnormal state. Alternatively, the determination can be made based on the lock status signal or heartbeat signal of the serial deserialization chip in the LVDS link. When the lock status signal of the serial deserialization chip is lost or the heartbeat signal is interrupted, the vehicle display screen is determined to be in an abnormal state. Alternatively, the self-test information reported by the microcontroller unit of the vehicle display screen can be received via the I2C bus, and the vehicle display screen can be determined to be in an abnormal state based on the self-test information. The MPU module is also used to send the determination result to the MCU module.

7. The control system according to claim 2, characterized in that, The MPU module is also used to perform the following processes: After capturing the interface display data in the frame buffer corresponding to the MPU module, the interface display data is video encoded and compressed to generate a video stream; The video stream is used as the interface display data and transmitted back to the mobile terminal via the vehicle network and the cloud server.

8. The control system according to claim 7, characterized in that, The MPU module is also used to perform the following processes: The interface display data is cached for a preset duration during scrolling. When the screen recording start command is received from the mobile terminal via the cloud server, the interface display data captured after the screen recording start command arrives is merged with the interface display data cached in the scrolling cache within the preset time period before the screen recording start command arrives, and then sent back to the mobile terminal.

9. The control system according to claim 1, characterized in that, The MCU module is also used to perform the following processes: After the emergency interaction channel is established, the button signals generated by the physical control component are continuously monitored; If no button signal is received within a preset time period, an emergency mode exit command is sent to the MPU module. The MPU module is also used to perform the following processes: In response to the emergency mode exit command, the emergency interaction path is switched back to the normal interaction path to stop capturing the interface display data and stop the conversion of the button signals to the standard event identifier.

10. A vehicle cabin area, characterized in that, Includes an in-vehicle display screen and a control system for the vehicle cabin area as described in any one of claims 1 to 9.

Images