Cabin controller power management dual-system interaction method and system and electronic equipment

Abstract

The invention discloses a cabin controller power management dual-system interaction method and system and electronic equipment, and belongs to the field of system power supplies, and the method comprises the steps: S1, building a dual-communication link between a QNX system and an Android system, the dual-communication link comprises a software communication link depending on an Ethernet protocol, and the software communication link is connected with the Android system; the backup communication link depends on a virtual I / O (Input / Output) provided by a high-pass SOC (System On Chip) platform used by the cabin controller; s2, when the cabin controller executes a sleep wake-up process, preferentially realizing interaction between the QNX system and the Android system through the software communication link; if the communication delay or abnormity occurs in the software communication link, switching to the virtual I / O backup communication link for interaction; and S3, optimizing a sleep wake-up state machine of the QNX system, and adding an STRRESUME state and a REQPOWERUP state on the basis of an original ON state, an original SUTDOWNPREPARE state, an original STR (sleep) state and an original OFF state, so that the state of the QNX system and the state of the Android system are synchronized in real time.

Description

Technical Field

[0001] This application relates to the field of system power supply, and more particularly to a dual-system interaction method for cockpit controller power management, a dual-system interaction system for cockpit controller power management, electronic devices, storage media, and vehicle cockpits. Background Technology

[0002] This application relates to the field of electric vehicle cockpit controller technology, specifically focusing on the power management interaction technology of a dual-system architecture cockpit controller. The cockpit controller has a dual-system architecture, with the underlying layer being the QNX operating system, and a virtual machine created in the QNX system, running the Android system within the virtual machine.

[0003] When the electric vehicle enters a sleep state, the QNX and Android systems in the cockpit controller must also enter a sleep state sequentially as required. Correspondingly, when the vehicle is woken up, the two systems must complete the wake-up operation in reverse order. In this entire sleep-wake process, the two systems need to frequently interact and synchronize their states. The stability of the interaction between the two systems and the accuracy of the state synchronization are the core prerequisites for ensuring that the cockpit controller can stably enter sleep and wake up normally, directly affecting the reliability of the cockpit controller and even the related functions of the entire vehicle.

[0004] However, the current technical solution for dual-system power management interaction in cockpit controllers has the following significant disadvantages, making it difficult to meet the requirements for stable operation:

[0005] 1. The communication link between the QNX system and the Android system has poor stability.

[0006] In existing technologies, when the QNX system and the Android system perform sleep / wake operations, they typically rely on only one communication link as the interaction link, which is built on the Ethernet protocol layer. Since the Ethernet protocol layer itself also needs to perform sleep / wake actions synchronously during the sleep / wake process, if there is a communication delay or abnormality in the Ethernet protocol layer during this process, it will directly cause the entire SOC (System-on-a-Chip) sleep / wake process to fail, triggering an anomaly in the cockpit controller system.

[0007] Meanwhile, even if some solutions include backup communication links, they are still essentially software-level communication methods (such as HAB communication provided by Qualcomm platforms, i.e., shared memory communication). In the sleep-wake process, which has extremely high requirements for real-time performance and reliability, the interaction between the two systems relies entirely on the software communication mechanism. Once a software-level failure occurs (such as communication process blocking or data transmission errors), it will directly block the entire sleep-wake process, posing a significant functional risk.

[0008] 2. The QNX system and the Android system are out of sync.

[0009] In the cockpit controller SOC's sleep / wake architecture, the system's default sleep sequence is "first sleep the Android system, then sleep the QNX system," while the wake-up process is the reverse (first wake up the QNX system, then wake up the Android system). The smooth progress of the entire sleep / wake process is highly dependent on the real-time state of the Android system: on one hand, the QNX system's sleep action must be based on the Android system's state, and the state on the QNX side must perfectly match the state on the Android side. If the two states do not match, an anomaly will be triggered at some point in the process, causing sleep to fail. On the other hand, if the sleep action needs to be interrupted externally during the sleep process (e.g., the user triggers a wake-up command), the QNX system must execute the corresponding interruption operation based on the current state of the Android system. If the states of QNX and Android are inconsistent, both the sleep process and the interruption action will malfunction, further affecting the cockpit controller's functionality. Summary of the Invention

[0010] The purpose of this invention is to provide a dual-system interaction method for cockpit controller power management, a dual-system interaction system for cockpit controller power management, an electronic device, a storage medium, and a vehicle cockpit, thereby solving at least one of a number of technical problems.

[0011] 1. Insufficient reliability of dual-system communication links: QNX and Android systems rely on a single Ethernet software link (or a pure software backup link) for interaction. The sleep and wake-up actions of the Ethernet protocol layer are prone to causing communication delays / abnormalities. Furthermore, there is a lack of clear logic for link establishment, abnormality detection, switching, and simultaneous abnormality handling of both links, which makes the sleep and wake-up process prone to interruption and system abnormalities.

[0012] 2. Problem of dual system state synchronization failure: The order of sleep (Android first, then QNX) and wake-up (QNX first, then Android) of QNX and Android systems is clear, but the original state machine of QNX (only ON, SHUTDOWNPREPARE, STR, OFF states) lacks transition states adapted to Android wake-up delay and sleep termination time, resulting in a mismatch between the two system states, causing sleep failure and abnormal interruption actions.

[0013] This invention provides the following solution:

[0014] According to a first aspect of the present invention, a dual-system interaction method for cockpit controller power management is provided, applied to an electric vehicle cockpit controller. The cockpit controller has a dual-system architecture, with the underlying layer being a QNX operating system. A virtual machine is created within the QNX operating system, and an Android system runs within the virtual machine. The dual-system interaction method for cockpit controller power management includes:

[0015] Step S1: Establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O (virtio) provided by the Qualcomm SOC platform used by the cockpit controller.

[0016] In step S2, when the cockpit controller executes the sleep-wake process, the QNX system and the Android system are first interacted through the software communication link; if the software communication link experiences communication delay or abnormality, the interaction is switched to the virtual I / O backup communication link.

[0017] Step S3: Optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR sleep state, and OFF state, add STR_RESUME state and REQ_POWERUP state to make the state of the QNX system synchronize with the state of the Android system in real time.

[0018] Step S4: If both the software communication link and the virtual I / O backup communication link malfunction simultaneously, the hibernation wake-up process is interrupted, and the cockpit controller is directly reset to reset the system.

[0019] Furthermore, it also includes:

[0020] The process of establishing a software communication link relying on the Ethernet protocol in step S1 includes:

[0021] After the cockpit controller's SOC is running normally, the QNX system's power management service starts and establishes a connection with the Android system through the socket interface;

[0022] The software communication link relies on the QNX system's hypervisor system, which is an existing function of the cockpit controller.

[0023] Furthermore, it also includes:

[0024] The process of establishing the virtual I / O backup communication link in step S1 includes:

[0025] By using the configuration methods provided by the Qualcomm SOC platform, a virtual I / O device is generated on the Android system side. The QNX system side accesses the virtual I / O device through standard read and write methods, enabling the virtual I / O backup communication link to have the ability to receive and send data during the sleep-wake process.

[0026] Furthermore, it also includes:

[0027] Step S2 has conditions for determining whether there is a communication delay or abnormality in the software communication link, specifically including:

[0028] The QNX system's power management service checks the communication status of the software communication link every 1 second. If a single communication failure is detected, it is determined to be a communication delay or an anomaly, and the anomaly information is recorded.

[0029] Furthermore, it also includes:

[0030] After switching to the virtual I / O backup communication link in step S2, the method further includes: checking the communication status of the virtual I / O backup communication link at a period of 1 second; if successful communication is detected, maintaining the link for interaction; if communication failure is detected, recording the abnormal information.

[0031] Furthermore, it also includes:

[0032] In step S4, the direct reset system of the cockpit controller is triggered under the following conditions: the power management service of the QNX system simultaneously detects abnormal records of the software communication link and the virtual I / O backup communication link, and continues to detect for a preset number of cycles without restoring communication of either link.

[0033] Furthermore, it also includes:

[0034] The STR_RESUME state in step S3 includes: after the QNX system receives the wake-up command and exits the STR state, it enters the STR_RESUME state;

[0035] In this state, the QNX system waits for the Android system to switch out of the STR state and send a wake-up success status message, without processing other instructions;

[0036] If the QNX system does not receive a successful wake-up message from the Android system within a preset time threshold while in the STR_RESUME state, the cockpit controller will reset the system.

[0037] Furthermore, it also includes:

[0038] In step S3, the REQ_POWERUP state includes: when the cockpit controller is executing a hibernation process, including when the QNX system is in the SHUTDOWNPREPARE or STR state, if an external interruption command is received, the QNX system enters the REQ_POWERUP state.

[0039] In this state, the QNX system waits for the Android system to complete the hibernation abort action and send a status message indicating successful abort.

[0040] Once the state of the QNX system is synchronized with that of the Android system, the QNX system notifies the Android system to switch to the ON state, and then it also switches to the ON state.

[0041] Furthermore, it also includes:

[0042] The hibernation process involves the QNX system first sending a command to notify the Android system to enter hibernation mode;

[0043] Once the Android system's state synchronization is detected as complete (sleep is complete), the QNX system switches from the SHUTDOWNPREPARE state to the STR state or the OFF state.

[0044] Furthermore, it also includes:

[0045] The wake-up process includes the following sequence: first, wake up the QNX system, and then switch the QNX system from the STR state to the STR_RESUME state;

[0046] Once the Android system's state is detected as successfully woken up, the QNX system switches from the STR_RESUME state to the ON state, completing the wake-up process.

[0047] According to a second aspect of the present invention, a dual-system interaction system for cockpit controller power management is provided, the dual-system interaction system for cockpit controller power management includes:

[0048] The dual communication establishment module is used to establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O (virtio) provided by the Qualcomm SOC platform used by the cockpit controller.

[0049] The dual communication backup module is used to prioritize the interaction between the QNX system and the Android system via the software communication link when the cockpit controller is executing the sleep-wake process; if the software communication link experiences communication delays or abnormalities, it switches to the virtual I / O backup communication link for interaction.

[0050] The dual-system synchronization module is used to optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR (sleep) state, and OFF state, it adds STR_RESUME state and REQ_POWERUP state to enable the state of the QNX system to be synchronized with the state of the Android system in real time.

[0051] The dual communication reset module is used to interrupt the hibernation wake-up process and control the cockpit controller to directly reset the system if both the software communication link and the virtual I / O backup communication link fail simultaneously.

[0052] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0053] The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of the cockpit controller power management dual-system interaction method.

[0054] According to a fourth aspect of the present invention, a computer-readable storage medium is provided storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the cockpit controller power management dual-system interaction method.

[0055] According to a fifth aspect of the present invention, a vehicle cockpit is provided, comprising: electronic equipment for implementing the steps of a cockpit controller power management dual-system interaction method;

[0056] The processor runs a program that, when running, executes the steps of the cockpit controller power management dual-system interaction method based on data output from electronic devices.

[0057] Storage medium for storing programs that, when running, execute steps of the cockpit controller power management dual-system interaction method in response to data output from electronic devices.

[0058] The above solution achieves the following beneficial technical effects:

[0059] This application establishes dual redundancy through an "Ethernet software link + Qualcomm SOC virtual I / O hardware-level backup link," clearly defining the link establishment logic, periodic detection / switching rules, and dual-link abnormal reset mechanism. This avoids interactive interruptions caused by single-link or common software faults, ensures the continuous stability of the sleep-wake process, and significantly improves the reliability of the communication link.

[0060] This application optimizes the QNX state machine, such as adding STR_RESUME and REQ_POWERUP transition states, clarifying the logic that "QNX state switching is based on Android state synchronization" in the sleep / wake process, solving the state difference problem in wake-up delay and sleep interruption scenarios, ensuring that the process proceeds in the preset order, reducing the probability of sleep wake-up failure, and ensuring accurate realization of dual system state synchronization. Attached Figure Description

[0061] Figure 1 This is a flowchart of a dual-system interaction method for cockpit controller power management provided by one or more embodiments of the present invention.

[0062] Figure 2This is a structural diagram of a dual-system interactive system for cockpit controller power management provided by one or more embodiments of the present invention.

[0063] Figure 3 This is a schematic diagram of a dual communication link between QNX and Android provided in a specific embodiment of the present invention.

[0064] Figure 4 This is a schematic diagram of a dual communication link process provided in a specific embodiment of the present invention.

[0065] Figure 5 This is a schematic diagram of the QNX system sleep / wake-up state machine provided in a specific embodiment of the present invention.

[0066] Figure 6 This is an electronic device structural block diagram of a dual-system interaction method for cockpit controller power management provided in one or more embodiments of the present invention. Detailed Implementation

[0067] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0068] Figure 1 This is a flowchart of a dual-system interaction method for cockpit controller power management provided by one or more embodiments of the present invention.

[0069] like Figure 1 The cockpit controller power management dual-system interaction method shown is applied to an electric vehicle cockpit controller. The cockpit controller has a dual-system architecture, with the underlying layer being the QNX operating system. A virtual machine is created within the QNX operating system, and the Android system runs within the virtual machine. The cockpit controller power management dual-system interaction method includes:

[0070] Step S1: Establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O (virtio) provided by the Qualcomm SOC platform used by the cockpit controller.

[0071] In step S2, when the cockpit controller executes the sleep-wake process, the QNX system and the Android system are first interacted through the software communication link; if the software communication link experiences communication delay or abnormality, the interaction is switched to the virtual I / O backup communication link.

[0072] Step S3: Optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR sleep state, and OFF state, add STR_RESUME state and REQ_POWERUP state to make the state of the QNX system synchronize with the state of the Android system in real time.

[0073] Step S4: If both the software communication link and the virtual I / O backup communication link malfunction simultaneously, the hibernation wake-up process is interrupted, and the cockpit controller is directly reset to reset the system.

[0074] Specifically, the technical feature of this application, "Application scenario: electric vehicle cockpit controller, adopting a dual-system architecture (the underlying layer is the QNX operating system, a virtual machine is created in the QNX system, and the Android system runs in the virtual machine)," solves the problem that the existing technology does not clearly define the dual-system architecture, which leads to the lack of adaptation prerequisites for subsequent interaction schemes and the easy occurrence of architecture incompatibility. The resulting technical effect is to clarify the core components of the dual-system architecture, provide an adaptation basis for subsequent communication link establishment and state machine optimization, and ensure that the solution is fully matched with the cockpit controller hardware architecture.

[0075] The technical feature of this application is "establishing a dual communication link between the QNX system and the Android system, including a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O (virtio) provided by the Qualcomm SOC platform used by the cockpit controller". This feature solves the problems of poor communication stability and easy interruption of interaction due to common software failures caused by existing technologies that rely on only a single Ethernet software link or whose backup link is still in software mode (such as Qualcomm HAB shared memory). The resulting technical effect is to form a dual link redundancy of "software link + underlying hardware level link", avoiding the interruption of interaction caused by single link abnormality or common software failure (such as communication process freezing), and significantly improving the stability of dual system interaction in the sleep-wake process.

[0076] The technical feature of this application, "when the cockpit controller executes the hibernation-wake-up process, the QNX system and the Android system are preferentially interacted through the software communication link; if the software communication link experiences communication delay or abnormality, the interaction is switched to the virtual I / O backup communication link," solves the problem that the existing technology lacks clear link switching logic and has no reliable redundant link to take over after a single link fails, causing the hibernation-wake-up process to fail directly. The resulting technical effect is to clarify the link priority and switching trigger conditions, ensure that the software link can utilize its existing functional advantages when it is normal, and that the backup link can take over in time when the software link is abnormal, ensuring that the hibernation-wake-up interaction is not interrupted.

[0077] The technical feature of this application is "optimizing the sleep / wake-up state machine of the QNX system by adding the STR_RESUME and REQ_POWERUP states to the existing ON, SHUTDOWNPREPARE, STR (sleep) and OFF states, so that the state of the QNX system is synchronized with the state of the Android system in real time." This feature solves the problem in the prior art where the states of the QNX system and the Android system are not synchronized (the sleep order is "Android first, then QNX", the wake-up order is reversed, and the state on the QNX side does not match the state on the Android side), which leads to sleep failure or abnormal interruption actions. The technical effect is that by adding new states to fill the logical gaps in the original state machine, it ensures that the QNX system can wait for the Android system state to synchronize in scenarios such as wake-up and sleep interruption, so that the states of the two systems are always consistent and the sleep / wake-up process proceeds according to the preset logic.

[0078] The technical feature of this application, "if the software communication link and the virtual I / O backup communication link both fail, the hibernation wake-up process is interrupted, and the cockpit controller is directly reset," solves the problem that existing technologies lack a mechanism for handling simultaneous failures of two links and that the system is prone to being stuck in an abnormal state for a long time, leading to the complete failure of the cockpit controller. The resulting technical effect is to avoid the system being in an abnormal blocking state for a long time, and to quickly restore the basic functions of the cockpit controller through a reset operation, thereby reducing the impact of abnormalities on the availability of the vehicle's cockpit functions.

[0079] In this embodiment, it also includes:

[0080] The process of establishing a software communication link relying on the Ethernet protocol in step S1 includes:

[0081] After the cockpit controller's SOC is running normally, the QNX system's power management service starts and establishes a connection with the Android system through the socket interface;

[0082] The software communication link relies on the QNX system's hypervisor system, which is an existing function of the cockpit controller.

[0083] Specifically, the technical feature of this application is that "the process of establishing the software communication link relying on the Ethernet protocol in step S1 is as follows: after the SOC of the cockpit controller is running normally, the power management service of the QNX system starts and establishes a connection with the Android system through the socket interface. The software communication link relies on the hypervisor system of the QNX system to implement, which is an existing function of the cockpit controller." This feature solves the problem that the existing technology does not clearly define the specific establishment logic of the Ethernet software link and is prone to communication startup failure due to non-standard link initialization process. The resulting technical effect is to clarify the establishment triggering conditions (normal operation of SOC, startup of power management service) and technical dependencies (socket interface, hypervisor system) of the software communication link, reduce development complexity by utilizing the existing functions of the system, and at the same time ensure the reliability of software link initialization, providing a stable initial communication channel for basic interaction between the two systems.

[0084] In this embodiment, it also includes:

[0085] The process of establishing the virtual I / O backup communication link in step S1 includes:

[0086] By using the configuration methods provided by the Qualcomm SOC platform, a virtual I / O device is generated on the Android system side. The QNX system side accesses the virtual I / O device through standard read and write methods, enabling the virtual I / O backup communication link to have the ability to receive and send data during the sleep-wake process.

[0087] Specifically, the technical feature of this application is that "the establishment process of the virtual I / O backup communication link in step S1 is as follows: through the configuration method provided by the Qualcomm SOC platform, a virtual virtual-io device is generated on the Android system side, and the QNX system side accesses the virtual-io device through the standard read and write method, so that the virtual I / O backup communication link has the data reception and transmission capabilities in the sleep-wake process." This feature solves the problem that the establishment process of the underlying hardware-level backup link in the prior art is unclear and cannot provide reliable redundancy when the software link fails. The resulting technical effect is to clarify the establishment steps of the virtual I / O link, ensure that the backup link can be adapted to the Qualcomm SOC platform, and has the data reception and transmission capabilities in the sleep-wake scenario, provide hardware-level redundancy for the software link, and avoid the simultaneous failure of the two links due to common software-level faults.

[0088] In this embodiment, it also includes:

[0089] Step S2 has conditions for determining whether there is a communication delay or abnormality in the software communication link, specifically including:

[0090] The QNX system's power management service checks the communication status of the software communication link every 1 second. If a single communication failure is detected, it is determined to be a communication delay or an anomaly, and the anomaly information is recorded.

[0091] Specifically, the technical feature of this application is that "the specific method of 'judging whether there is a communication delay or anomaly in the software communication link in step S2' is as follows: the power management service of the QNX system detects the communication status of the software communication link at a cycle of 1 second. If a single communication failure is detected, it is determined to be a communication delay or anomaly, and the anomaly information is recorded at the same time." This feature solves the problem that the existing technology does not have a clear anomaly detection standard (detection cycle, judgment threshold) for the software communication link, which leads to untimely detection or misjudgment of anomalies. The resulting technical effect is that the 1-second cycle detection ensures that anomalies are detected in a timely manner, avoiding the hibernation and wake-up process from being stuck due to delayed detection; the single failure judgment standard simplifies the anomaly identification logic, and at the same time, the anomaly record provides a basis for subsequent fault investigation, balancing detection sensitivity and the risk of misjudgment.

[0092] In this embodiment, it also includes:

[0093] After switching to the virtual I / O backup communication link in step S2, the method further includes: checking the communication status of the virtual I / O backup communication link at a period of 1 second; if successful communication is detected, maintaining the link for interaction; if communication failure is detected, recording the abnormal information.

[0094] Specifically, the technical feature of this application, "after switching to the virtual I / O backup communication link in step S2, further includes: detecting the communication status of the virtual I / O backup communication link at a 1-second interval; if successful communication is detected, maintaining the link for interaction; if communication failure is detected, recording the abnormal information," solves the problem that existing technologies only focus on link switching actions, do not clearly define the continuous monitoring mechanism of the backup link after switching, and may fail to detect communication interruptions caused by subsequent abnormalities of the backup link in a timely manner. The resulting technical effect is that continuous 1-second interval detection ensures the backup link remains reliable throughout the entire hibernation and wake-up process, avoiding process blockage caused by "link failure after successful switching"; the abnormality recording function provides data support for judging the simultaneous abnormality of both links, ensuring that the subsequent reset mechanism is accurately triggered.

[0095] In this embodiment, it also includes:

[0096] In step S4, the direct reset system of the cockpit controller is triggered under the following conditions: the power management service of the QNX system simultaneously detects abnormal records of the software communication link and the virtual I / O backup communication link, and continues to detect for a preset number of cycles without restoring communication of either link.

[0097] Specifically, the technical feature of this application, "the triggering condition for 'directly resetting the system by controlling the cockpit controller' in step S4 is: the power management service of the QNX system simultaneously detects abnormal records of the software communication link and the virtual I / O backup communication link," solves the problem that the prior art lacks a definition of the triggering condition for simultaneous dual-link anomalies, and that the reset mechanism is easily abused or not triggered due to ambiguity in the triggering logic. The resulting technical effect is to clarify the core judgment basis for simultaneous dual-link anomalies, ensuring that the reset mechanism is triggered only when there is a true dual-link failure, and avoiding false resets or long-term blockage of abnormal states.

[0098] In this embodiment, it also includes:

[0099] The STR_RESUME state in step S3 includes: after the QNX system receives the wake-up command and exits the STR state, it enters the STR_RESUME state;

[0100] In this state, the QNX system waits for the Android system to switch out of the STR state and send a wake-up success status message, without processing other instructions;

[0101] If the QNX system does not receive a successful wake-up message from the Android system within a preset time threshold while in the STR_RESUME state, the cockpit controller will reset the system.

[0102] Specifically, the technical feature of this application is that "the role of the STR_RESUME state in step S3 includes: after the QNX system receives the wake-up command and exits from the STR state, it enters the STR_RESUME state; in this state, the QNX system only waits for the Android system to switch out of the STR state and send the 'wake-up successful' status information, without processing any other external commands; if the QNX system does not receive the 'wake-up successful' status information from the Android system within the timeout period in the STR_RESUME state, it controls the cockpit controller to reset the system." This feature solves the problem in the prior art where the QNX system directly switches to the ON state after wake-up without waiting for the Android system to wake up (there is a delay), resulting in the asynchrony of the two system states, which in turn causes subsequent process abnormalities. The resulting technical effect is that the STR_RESUME state provides a waiting window for the Android system to wake up, shielding it from external command interference, ensuring that the QNX system only proceeds the process after the Android system wakes up successfully; the timeout reset mechanism avoids the QNX from being stuck in the waiting state for a long time due to the Android system's wake-up failure, ensuring that the system function is restored in a timely manner.

[0103] In this embodiment, it also includes:

[0104] In step S3, the REQ_POWERUP state includes: when the cockpit controller is executing a hibernation process, including when the QNX system is in the SHUTDOWNPREPARE or STR state, if an external interruption command is received, the QNX system enters the REQ_POWERUP state.

[0105] In this state, the QNX system waits for the Android system to complete the hibernation abort action and send a status message indicating successful abort.

[0106] After the state of the QNX system is synchronized with the state of the Android system, the next wake-up or sleep process is executed, including the QNX system notifying the Android system to switch to the ON state, and then the QNX system also switching to the ON state.

[0107] Specifically, the technical feature of this application is that "the role of the REQ_POWERUP state in step S3 includes: when the cockpit controller is executing the hibernation process (the QNX system is in the SHUTDOWNPREPARE state or STR state), if an interruption command is received from the outside, the QNX system immediately enters the REQ_POWERUP state; in this state, the QNX system waits for the Android system to complete the hibernation abort action and send a 'successful abort' status message. After the state is synchronized, the next wake-up or process switching action is executed." This feature solves the problem in the prior art where the QNX system responds quickly when hibernation is interrupted, but the Android system's abort action is slow, leading to a lack of synchronization between the two systems and causing abnormal interruption actions. The resulting technical effect is that by waiting for the Android system to complete the hibernation abort in the REQ_POWERUP state, the state of the two systems is synchronized in the interruption scenario, avoiding process conflicts caused by inconsistent states and improving the reliability of the hibernation interruption function.

[0108] In this application, "the QNX system notifies the Android system to switch to the ON state, and then it also switches to the ON state." This is because as soon as a "sleep interruption" begins, it returns to the ON state and then proceeds with other processes. Even if the hibernation process is to resume during a "sleep interruption," it must first return to the ON state before continuing the hibernation process. In other words, once a hibernation interruption occurs, the entire hibernation interruption process must be completed to simplify the interruption process; otherwise, it might fall into a loop of "interrupting hibernation," then hibernating again to interrupt the so-called interruption process.

[0109] In this embodiment, it also includes:

[0110] The hibernation process involves the QNX system first sending a command to notify the Android system to enter hibernation mode;

[0111] Once the Android system's state synchronization is detected as complete (sleep is complete), the QNX system switches from the SHUTDOWNPREPARE state to the STR state or the OFF state.

[0112] Specifically, the technical feature of this application is that "the specific sequence of the hibernation process is as follows: the QNX system first sends a command to notify the Android system to enter hibernation state. After detecting that the Android system's state is synchronized to 'hibernation complete', the QNX system then switches from the SHUTDOWN PREPARE state to the STR state or the OFF state." This feature solves the problem that although the prior art specifies the hibernation order of "Android first, then QNX", it does not specify the triggering condition for the QNX system state switching (which depends on the Android state). This can easily lead to a mismatch between the two systems' states due to the QNX switching state in advance. The resulting technical effect is that it strictly follows the hibernation logic of "Android first, then QNX", takes the Android system's "hibernation complete" as the premise for the QNX state switching, avoids hibernation failure caused by the QNX going to hibernation in advance, and ensures that the hibernation process is completed in an orderly manner.

[0113] In this embodiment, it also includes:

[0114] The wake-up process includes the following sequence: first, wake up the QNX system, and then switch the QNX system from the STR state to the STR_RESUME state;

[0115] Once the Android system's state is detected as successfully woken up, the QNX system switches from the STR_RESUME state to the ON state, completing the wake-up process.

[0116] Specifically, the technical feature of this application is that "the specific sequence of the wake-up process is as follows: first, the QNX system is woken up, and the QNX system switches from the STR state to the STR_RESUME state; after detecting that the Android system's state is synchronized as 'wake-up successful', the QNX system then switches from the STR_RESUME state to the ON state, completing the entire wake-up process." This feature solves the problem in the prior art that the state switching path of the QNX system after wake-up is not clearly defined in conjunction with the newly added STR_RESUME state, resulting in chaotic state logic in the wake-up process. The resulting technical effect is to clarify the state switching path of the QNX system after wake-up (STR→STR_RESUME→ON), with the Android system's "wake-up successful" as the premise for QNX to switch to the ON state, ensuring that the states of the two systems are synchronized throughout the wake-up process, and avoiding cockpit function abnormalities (such as application startup failure and interaction lag) caused by inconsistent states after wake-up.

[0117] Figure 2This is a structural diagram of a dual-system interactive system for cockpit controller power management provided by one or more embodiments of the present invention.

[0118] like Figure 2 The cockpit controller power management dual-system interactive system shown includes: a dual communication establishment module, a dual communication backup module, a dual system synchronization module, and a dual communication reset module;

[0119] The dual communication establishment module is used to establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O (virtio) provided by the Qualcomm SOC platform used by the cockpit controller.

[0120] The dual communication backup module is used to prioritize the interaction between the QNX system and the Android system via the software communication link when the cockpit controller is executing the sleep-wake process; if the software communication link experiences communication delays or abnormalities, it switches to the virtual I / O backup communication link for interaction.

[0121] The dual-system synchronization module is used to optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR (sleep) state, and OFF state, it adds STR_RESUME state and REQ_POWERUP state to enable the state of the QNX system to be synchronized with the state of the Android system in real time.

[0122] The dual communication reset module is used to interrupt the hibernation wake-up process and control the cockpit controller to directly reset the system if both the software communication link and the virtual I / O backup communication link fail simultaneously.

[0123] It is worth noting that although this system / device only discloses the aforementioned dual communication establishment module, dual communication backup module, dual system synchronization module, and dual communication reset module, it does not mean that this system / device is limited to the aforementioned basic functional modules. Rather, what this invention intends to express is that, based on the aforementioned basic functional modules, those skilled in the art can arbitrarily add one or more functional modules in combination with existing technology to form an infinite number of embodiments or technical solutions. In other words, this system is open rather than closed. The fact that this embodiment only discloses a few basic functional modules should not lead to the conclusion that the scope of protection of the claims of this invention is limited to the aforementioned disclosed basic functional modules.

[0124] In one specific embodiment, a dual-system interaction method for cockpit controller power management is disclosed, which involves two aspects: one is the communication link between the two systems, and the other is optimizing the state machine of the QNX side system to ensure that the states of the QNX system and the Android system are consistent.

[0125] like Figure 3 The QNX and Android dual communication links shown establish two communication links simultaneously: one is a software link that relies on the Ethernet protocol, and the other is a virtual I / O communication link provided by Qualcomm (the Qualcomm SOC used in the cockpit controller). The virtual I / O communication link serves as a backup. When the software communication link is delayed or malfunctions, the virtual I / O communication link is used for backup communication to ensure the normal operation of the sleep / wake function.

[0126] The state machine of the QNX side system was optimized to ensure that the states of the QNX system and the Android system are consistent. The state machine of the QNX side was redesigned according to the entire sleep-wake process, and two state stages that were not designed in the sleep-wake process were added to make the entire process state clearer and more robust.

[0127] like Figure 4 The dual communication link process shown, and as follows Figure 5 The QNX system sleep / wake state machine shown is part of the cockpit controller's SOC. The QNX system is the base system, and the Android system runs as a virtual machine within the QNX system. After the SOC is running normally, the QNX system and the Android system can communicate using existing Ethernet protocols. This Ethernet communication between the two systems is an existing function (through the QNX system's hypervisor). After the power management service starts, it establishes Ethernet communication with the Android system via a socket interface. Simultaneously, the Qualcomm (SOC vendor) platform provides another lower-level communication interface: a virtual device. Through Qualcomm's configuration methods, a virtual I / O device can be generated on the Android system side. This virtual device can be read and written on the QNX system side using standard methods. During the sleep / wake process, receiving and sending operations can also be performed using this method.

[0128] like Figure 4 As shown:

[0129] 1. After the vehicle system is powered on and the power management service is started, it establishes Ethernet communication with the Android system through the socket interface;

[0130] 2. After establishing Ethernet communication, establish virtio communication using the method provided by Qualcomm. Once these two communication methods are established, normal communication with the Android system can be achieved.

[0131] 3. During the sleep-wake process, when the two systems communicate, they first communicate via an Ethernet link. If the Ethernet link communication fails, the system records the failure and switches to the virtio communication link for communication.

[0132] 4. If both the Ethernet link and the virtio link fail simultaneously, the sleep / wake-up process will be interrupted, and the system will be directly reset to ensure normal function.

[0133] like Figure 5 As shown:

[0134] In a normal power management process, the power management service has only four state machines: ON, shutdown_prepare, STR, and OFF. However, in practice, the states of the QNX system and the Android system cannot be perfectly synchronized in real time. The Android system's state lags behind the QNX system's. For example, in the wake-up process, when an external wake-up signal is received, QNX is woken up first and exits the STR state. Android is woken up approximately 5 seconds later. If the QNX system, after being woken up and exiting the STR state, immediately switches to the ON state, then for the next 5 seconds, the QNX system will be in the ON state while the Android system is in the STR state, resulting in a state inconsistency. If the QNX system then receives a command to enter the shutdown_prepare state, but Android is still in the STR state, it cannot process the notification from the QNX side that Android has entered the shutdown_prepare state. Consequently, the subsequent process cannot continue, causing the cockpit to fail to enter the STR state.

[0135] After the QNX system is woken up, a state STR_RESUME is added. In this state, the QNX system waits for the Android system to switch out of the STR state. At the same time, QNX does not process any external states in the STR_RESUME state until it receives a successful wake-up from Android or the state times out and resets the system. This ensures that the state of the Android system can be completely synchronized with the QNX system when the QNX system switches states.

[0136] Similarly, the REQ_POWERUP state serves the same purpose. When the hibernation process is in progress, if an external request is made to interrupt the hibernation process, the QNX system can quickly interrupt it. However, the Android system's interruption action is slower. In this case, the QNX system needs to wait for the Android system's state to synchronize before it can take the next step.

[0137] As can be seen from the above embodiments, in the interaction process between the two systems, the power management service adds the above two states, which helps to ensure the power state synchronization between the QNX system and the Android system, and the division of states is clearer and the boundaries are more distinct.

[0138] Through the above embodiments, the cockpit controller's sleep / wake-up function in the cockpit system affects the overall vehicle functionality and user experience. Adding a lower-level communication link improves communication stability and reliability. Furthermore, these two links—the Ethernet link (a purely software link) and the virtual link (a hardware-oriented link)—further enhance communication reliability through their different characteristics.

[0139] Through the above embodiments

[0140] 1. Dual communication links ensure the stability and reliability of communication between the two systems in the cockpit controller during the hibernation-wake-up process;

[0141] 2. Two additional state machine states were added, resolving the asynchrony issue between the QNX system and the Android system;

[0142] 3. Two additional state machine states are added to divide the entire sleep-wake process into clearer segments according to time, making the boundaries between each state clearer.

[0143] Figure 6 This is an electronic device structural block diagram of a dual-system interaction method for cockpit controller power management provided in one or more embodiments of the present invention.

[0144] like Figure 6 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0145] The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of a dual-system interaction method for cockpit controller power management.

[0146] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of a cockpit controller power management dual-system interaction method.

[0147] This application also provides a vehicle cabin, including:

[0148] Electronic devices for implementing a dual-system interaction method for cockpit controller power management;

[0149] The processor runs a program that, when running, executes the steps of the cockpit controller power management dual-system interaction method based on data output from electronic devices.

[0150] Storage medium for storing programs that, when running, execute steps of the cockpit controller power management dual-system interaction method in response to data output from electronic devices.

[0151] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0152] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0153] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0154] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0155] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0156] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0157] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0158] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0159] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0160] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A dual-system interaction method for cockpit controller power management, applied to an electric vehicle cockpit controller, wherein the cockpit controller has a dual-system architecture, with the underlying layer being a QNX operating system, a virtual machine created within the QNX operating system, and an Android system running within the virtual machine, characterized in that... The cockpit controller power management dual-system interaction method includes: Step S1: Establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a virtual I / O backup communication link that relies on the Qualcomm SOC platform used by the cockpit controller. Step S2: When the cockpit controller executes the sleep-wake process, the QNX system and the Android system are first interacted through the software communication link; if the software communication link experiences communication delay or abnormality, the interaction is switched to the virtual I / O backup communication link. Step S3: Optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR sleep state, and OFF state, add STR_RESUME state and REQ_POWERUP state to make the state of the QNX system synchronize with the state of the Android system in real time. Step S4: If the software communication link and the virtual I / O backup communication link both malfunction, the hibernation wake-up process is interrupted, and the cockpit controller is directly reset to reset the system.

2. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The process of establishing a software communication link relying on the Ethernet protocol in step S1 includes: After the cockpit controller's SOC is running normally, the QNX system's power management service starts and establishes a connection with the Android system through the socket interface; The software communication link relies on the QNX system's hypervisor system, which is an existing function of the cockpit controller.

3. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The process of establishing the virtual I / O backup communication link in step S1 includes: By using the configuration method provided by the Qualcomm SOC platform, a virtual I / O device is generated on the Android system side. The QNX system side accesses the virtual I / O device through standard read and write methods, enabling the virtual I / O backup communication link to have the data reception and transmission capabilities in the sleep-wake process.

4. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: Step S2 has conditions for determining whether there is a communication delay or abnormality in the software communication link, specifically including: The QNX system's power management service checks the communication status of the software communication link every 1 second. If a single communication failure is detected, it is determined to be a communication delay or an anomaly, and the anomaly information is recorded.

5. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: In step S4, the direct reset system of the cockpit controller is triggered under the following conditions: the power management service of the QNX system simultaneously detects abnormal records of the software communication link and the virtual I / O backup communication link, and continues to detect for a preset number of cycles without restoring communication of either link.

6. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The STR_RESUME state mentioned in step S3 includes: after the QNX system receives the wake-up command and exits the STR state, it enters the STR_RESUME state; In this state, the QNX system waits for the Android system to switch out of the STR state and send a wake-up success status message, without processing other instructions; If the QNX system does not receive a successful wake-up message from the Android system within a preset time threshold while in the STR_RESUME state, the cockpit controller will reset the system.

7. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The REQ_POWERUP state mentioned in step S3 includes: when the cockpit controller is executing, including when the QNX system is in the SHUTDOWNPREPARE state or STR state hibernation process, if an external interruption command is received, the QNX system enters the REQ_POWERUP state. In this state, the QNX system waits for the Android system to complete the hibernation abort action and send a status message indicating successful abort. Once the state of the QNX system is synchronized with that of the Android system, the QNX system notifies the Android system to switch to the ON state, and then it also switches to the ON state.

8. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The hibernation process includes the following sequence: the QNX system first sends a command to notify the Android system to enter hibernation mode; Once the Android system's state synchronization is detected as complete (sleep is complete), the QNX system switches from the SHUTDOWNPREPARE state to the STR state or the OFF state.

9. The cockpit controller power management dual-system interaction method according to claim 1, characterized in that, Also includes: The wake-up process includes the following sequence: first, wake up the QNX system, and then switch the QNX system from the STR state to the STR_RESUME state; Once the Android system's state is detected as successfully woken up, the QNX system switches from the STR_RESUME state to the ON state, completing the wake-up process.

10. A dual-system interactive system for cockpit controller power management, characterized in that, The cockpit controller power management dual-system interaction system includes: The dual communication establishment module is used to establish a dual communication link between the QNX system and the Android system. The dual communication link includes a software communication link that relies on the Ethernet protocol and a backup communication link that relies on the virtual I / O provided by the Qualcomm SOC platform used by the cockpit controller. The dual communication backup module is used to prioritize the interaction between the QNX system and the Android system through the software communication link when the cockpit controller performs the sleep-wake process; if the software communication link experiences communication delay or abnormality, it switches to the virtual I / O backup communication link for interaction. The dual-system synchronization module is used to optimize the sleep and wake-up state machine of the QNX system. In addition to the original ON state, SHUTDOWNPREPARE state, STR (sleep) state, and OFF state, it adds STR_RESUME state and REQ_POWERUP state to enable the state of the QNX system to be synchronized with the state of the Android system in real time. The dual communication reset module is used to interrupt the hibernation wake-up process and control the cockpit controller to directly reset the system if both the software communication link and the virtual I / O backup communication link fail simultaneously.

Images